Proposal for a standardized LIST MOTD command
Julien ÉLIE
In case you have any comments or special need on that command, do not
hesitate to speak up.
Expectations from news readers, how it can be used, implementation
on news servers, etc.
Usage
Syntax
LIST MOTD
Responses
215 Information follows (multi-line)
Description
See Section 7.6.1 of [RFC3977] for general requirements of the LIST
command.
The motd list contains a "message of the day" relevant to the news
server. It is intended to provide notification and communication
between the news administrator and the news user. For instance,
notification of upcoming downtime or information about new facilities
available on the news server can be advertised via this means of
communication.
The information is returned as a multi-line data block following the
215 response code. This text is not guaranteed to be in any
particular format although, like all multi-line data blocks, it is
"dot-stuffed".
The server need not return the same information if this command is
used more than once in a session. It MAY indeed send a different
message of the day depending on the state of the session. For
instance, on a mode-switching news server, the information can be
different between its transit mode and its reader mode, or between an
authenticated session and an unauthenticated session.
The information MUST be in UTF-8.
The motd list is not newsgroup-based, and an argument MUST NOT be
specified. Otherwise, a 501 response code MUST be returned.
The motd list MAY be empty. If the server does not maintain the
information, a 503 response code MUST be returned.
It is up to the client to decide when and how to display this message
to the user. No timestamp or date of last modification date is
provided. The client may want to keep some state if it wishes to
show the message only upon modification.
Example
Example of output:
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] LIST ACTIVE MOTD NEWSGROUPS
[S] .
[C] LIST MOTD
[S] 215 Message of the day follows
[S] Attention all users,
[S]
[S] This server will be down for scheduled upgrades on February, 1st.
[S] It should be back up by 8:00 a.m. February, 2nd.
[S] Any questions should be e-mailed to <newsm...@example.com>.
[S]
[S] Apologies for the disturbance.
[S] .
ABNF syntax
list-arguments =/ "MOTD"
list-content =/ list-motd-content
list-motd-content = *(*U-CHAR CRLF)
--
Julien ï¿œLIE
ￜ Cela n'a rien de remarquable. Il suffit d'appuyer sur la
bonne touche au bon moment et l'instrument
joue tout seul. ￜ (J.-S. Bach)
Julien ÉLIE
Just a suggestion:
> Syntax
> LIST MOTD
>
> The motd list contains a "message of the day" relevant to the news
> server. It is intended to provide notification and communication
> between the news administrator and the news user. For instance,
> notification of upcoming downtime or information about new facilities
> available on the news server can be advertised via this means of
> communication.
Is there a need to provide newsgroup-based "messages of the day"?
LIST MOTD [newsgroup]
(not a wildmat)
When a newsgroup is specified, we could return information, if any,
related to the corresponding newsgroup.
For instance its charter...
But it would imply to have a list of all charters (for public hierarchies).
Otherwise, it could be useful only for local newsgroups.
--
Julien ï¿œLIE
ￜ -- Il t'arrive une tuile ?
-- Oui, je ne peux pas payer mon ardoise. ￜ
Aioe
> LIST MOTD [newsgroup]
> (not a wildmat)
>
> When a newsgroup is specified, we could return information, if any,
> related to the corresponding newsgroup.
> For instance its charter...
imho it's a great idea
Julien ÉLIE
I will add it in the second version of the draft.
If a newsgroup is specified (or a wildmat), the command will return 503,
that is to say that the news server does not maintain the information.
It is also what a news server responds if it does not maintain the
LIST MOTD information (with no argument).
What would be interesting is to allow sub-hierarchies MOTD.
That is to say:
LIST MOTD
LIST MOTD news
LIST MOTD news.software
LIST MOTD news.software.nntp
The first one would be the generic MOTD (what is currently implemented
in news servers that understand LIST MOTD).
The last one would be the MOTD specific to the newsgroup.
The second and the third commands would be for sub-hierarchies (a general
MOTD for news.* for instance).
Note that news.software may be a newsgroup. In that case, we would have
the MOTD for that newsgroup.
Easy to specify. And also easy to implement. A news server can for instance
have a directory where MOTD files are present.
If "news", "news.software" or "news.software.nntp" are files in that directory,
then the output of the "LIST MOTD file" command would be the contents of
that file. If the file does not exist, it is 503.
Exactly like LIST MOTD (which is the file named motd.news in INN).
Any thoughts about that suggestion?
--
Julien ï¿œLIE
ￜ Qu'est-ce que je vous sers pour arroser le sanglier bouilli ?
De l'eau chaude, de la cervoise tiￜde ou du vin rouge glacￜ ? ￜ (Astￜrix)
Aioe
> Any thoughts about that suggestion?
draft should be more detailed
IMHO,
LIST MOTD (without argument)
should/must include several data about the server (ie. Tech Contact, Legal
Contact (the was requested me by the italian police: how can i find the one
who maintains an NNTP site using *only* the server itself?), Max Article
Size (and other newsfeeds flags), Web site). They should be shown in a
standardized way in order to allow people to easily understand them.
It could also be used as a standardized way show peering data (but a
standard doesn't exist at the moment)
i'm thinking about somewhat like this
------
Path: aioe.org
Primary-Host: nntp.aioe.org
Backup-Host: news.aioe.org
Accept-From: news-out.aioe.org
Send-To: news-in.aioe.org
Tech-Contact: use...@aioe.org
Abuse-Contact: ab...@aioe.org
Support-Group: news://aioe.news.helpdesk
Legal-Contact: **************** (in order to avoid spam here)
Location: Holland, EU
Documentation: http://www.aioe.org/
Max-Article-Size: 32768
Groups: All except binaries (or an uwildmat string)
------
LIST MOTD <GROUP>
should include the manifesto of each group (they'are collected so it should
be easy to find them, i suppose)
Jeffrey M. Vinocur
>Julien �LIE wrote:
>
>> Any thoughts about that suggestion?
Oy. I think we're adding a lot of solution to fix a non-problem.
>should/must include several data about the server (ie. Tech Contact, Legal
>Contact (the was requested me by the italian police: how can i find the one
>who maintains an NNTP site using *only* the server itself?), Max Article
>Size (and other newsfeeds flags), Web site). They should be shown in a
>standardized way in order to allow people to easily understand them.
>It could also be used as a standardized way show peering data (but a
>standard doesn't exist at the moment)
This would require support for nnrpd virtualhosts, FYI.
--
Jeffrey M. Vinocur
je...@litech.org
Julien ÉLIE
> LIST MOTD (without argument)
>
> It could also be used as a standardized way show peering data (but a
> standard doesn't exist at the moment)
Is there a need for that?
Anyway, it is not the objective of LIST MOTD. If there really is a need
to have such standardized information, I think it should be in another
LIST command, which should be defined in an experimental Internet-Draft...
LIST MOTD has to be standardized the way it is currently used.
Too late now for such substantial changes.
> LIST MOTD <GROUP>
>
> should include the manifesto of each group (they'are collected so it should
> be easy to find them, i suppose)
Hmm... I do not know well how it can easily be done. Sometimes, there is
a FAQ or something else, instead of a charter.
Maybe we should just drop the idea of an argument to LIST MOTD...
It should be another LIST command...
--
Julien ï¿œLIE
ￜ Rubor, tumor, dolor, calor et functio laesa. ￜ
Aioe
> Is there a need for that?
imho, it's a need.
I've about 40 peers, each one with different peering data. Sometimes, data
are subjected to changes. There's no common places where peering data can be
found and many news server don't show these data in their web sites.
A way to know which parameters are requested by each peer is useful and has
the advantage to avoid 'third party' configuration errors.
btw, i *strongly* need a standardized way to show which is my legal contact
(the email address that police *must* use for court orders and legal
requests). It can be shown inside 'HELP' or 'LIST' output but it's needed an
official paper that says to use *that* address for such requests.
Julien ÉLIE
> I've about 40 peers, each one with different peering data. Sometimes, data
> are subjected to changes. There's no common places where peering data can be
> found and many news server don't show these data in their web sites.
> A way to know which parameters are requested by each peer is useful and has
> the advantage to avoid 'third party' configuration errors.
Then, if it is to update peering data, something more automated should
be used. For instance something described in this NNTP Extension for
Dynamic Feed Adjustment:
http://www.eyrie.org/~eagle/nntp/drafts/draft-court-dynfeed-01.txt
> btw, i *strongly* need a standardized way to show which is my legal contact
> (the email address that police *must* use for court orders and legal
> requests). It can be shown inside 'HELP' or 'LIST' output but it's needed an
> official paper that says to use *that* address for such requests.
Is an RFC considered as an official paper for police?
Should ask the question to a policeman :-)
Why wouldn't the legal contact be what is set in the mail-complaints-to
attribute of the Injection-Info: header field (or X-Complaints-To:) added
to every post from your news server?
Well, maybe you need another address than the one for abuse requests...
Aioe
> Is an RFC considered as an official paper for police?
yes. I've made the same answer to them in an interview room, after three
hours wait.
> Should ask the question to a policeman :-)
it should be a great idea. Interpol said me that an official statement is
needed, policeman were convince themselves that newsgroups are 'google
groups' and so they wanted from me 'apache logs'.
> Well, maybe you need another address than the one for abuse requests...
yes, of course.
Abuse desk is a common email mailbox. Legal contact goes to my mobile phone
or laptop.