From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed May 08 2002 - 09:32:48 CDT
In <87offsnlbp.fsf@erlenstar.demon.co.uk> Andrew Gierth <andrew@erlenstar.demon.co.uk> writes:
>a preliminary scan through the text identifies the following
>questionable uses of SHOULD or MUST:
My inclination is to leave most of these unchanged unless I hear support
from the List. So please let me hear your comments, even if it is only a
me2 to someopne else's opinion.
Item 1.
>4.5 "... Posting agents SHOULD endeavour to keep all header lines, so
> far as is possible, within 79 characters by folding them at suitable
> places... "
>4.5 "... injecting agents SHOULD fold any headers generated
> automatically by themselves ..."
>5.6.2 "... In addition, it SHOULD then add
> CRLF and WSP if it would otherwise result in a line longer than 79
> characters."
Presumably you are suggesting downgrading these to Ought. I could buy that
if others agree, but I would point out that RFC 2822 uses "SHOULD" in
similar contexts.
Item 2.
>5.5 reservation of _, +, - violates existing usage in some cases
If you mean that some existing newsgroup do not conform, then please see
other replies in the previous thread. Otherwise, please be more specific.
Item 3.
>5.5 "... Serving agents MUST NOT create new newsgroups simply because an
> unrecognized newsgroup-name occurs in a Newsgroups-header ..."
>[NOT RECOMMENDED might be more appropriate for that case]
That "MUST" comes from Son-of-1036, and reflects Best Current Practice
AIUI. To do otherwise would cause Extreme Harm IMO, especially in the case
of improperly normalized newsgroup-names expressed in UTF-8. Surely you do
not want a group to be created on thousands of servers worldwide simply
because one person mistypes the name of an existing group.
Does anyone else support this idea?
Item 4.
>6.9 "All other headers defined in this standard (excluding
> variant headers, but including specifically the Message-ID-header)
> MUST be identical in both the posted and mailed versions of the
> article, and so MUST the body."
>[existing practice with mailed copies often involves adding additional
>text to the body of the mailed copy]
That existing practice sounds like a Very Bad Thing to me (and especially
so if the mail version should ever find its way back into Netnews).
Does anyone else want to take this suggestion further?
Item 5.
>6.14 "Each mailbox contained in the Approved-content MUST be that of one of
> the person(s) or entity(ies) in question, and one of those mailboxes
> MUST be that of the actual injector of the article."
>[counterexample: news.answers]
I think the news.answers practice could usefully be changed here.
Obviously the use of the Approved header is not going to change overnight,
but I have been attempting to give some real teeth to the Approved
header, so that it can be relied on to convey useful information.
Ultimately, it needs to be included in a signature, of course.
Does anyone else want to weaken this?
Item 6.
>6.14 "If this header is not present in such postings, then
> relaying and serving agents MUST reject the article."
>[two objections here - firstly that relaying agents frequently do not
>know what groups are moderated, and secondly that accepting unapproved
>traffic is a valid policy choice, albeit one which is only rarely
>useful. This also directly conflicts with 8.3, which uses "MAY" for
>this issue as applied to relaying agents]
OK, I shall change it to "serving agents MUST (and relaying agents MAY)
reject ...".
Is that enough, or does anyone else want to imply that serving agents MAY
accept unapproved moderated articles? My view is that an agent that does
such an anti-social thing should be prepared to carry the stigma of being
non-compliant.
Item 7.
>6.15 "Whatever security or authentication checks are normally applied to a
> Control cancel message (or may be prescribed for such messages by
> some extension to this standard - see the remarks in 7.1 and 7.3)
> MUST also be applied to an article with a Supersedes-header. In the
> event of the failure of such checks, the article SHOULD be discarded,
> or at most stored as an ordinary article.
What is your problem with this?
Item 8.
>5.6.2 "The path-identity added MUST be unique to that agent"
>when combined with
>6.16 "An agent MUST use the same serving-name in Xref-headers as the path-
> identity it uses in Path-headers."
>[Xref is in the overview, and putting an FQDN in as the serving-name
>can double the average size of the header. It's not unusual for sites
>to choose a short, and quite likely non-unique, Path stamp for a spool
>server for exactly this reason (I've seen "0" used), thus conflicting
>with the uniqueness requirement]
You want SHOULD here? Or even weaker? I could be persuaded if others agree,
though I don't entirely buy the size argument.
Item 9.
>8.2.2 "It SHOULD likewise remove any NNTP-Posting-Host or other
> undocumented tracing header."
>8.7 "Any Injector-Info-header (6.19) or Complaints-To-header (6.20)
> MUST be removed."
>[retaining the original site's trace info is a valid policy decision
>for a moderator who is not otherwise constrained by their own injector.
>In fact it's often a nusiance for trace info in moderated groups to
>point to the moderator; it causes false positives in spam-filtering]
A sensible practice is to leave behind an X-Old-NNTP-Posting-Host or
X-Old-Injector-Info. Do you want a NOTE encouraging that practice?
Special exemption for moderators is an interesting idea. Anyone else want
to examine that idea further?
Item 10.
>8.2.2 "... the posting agent MUST be informed ..."
>[it may not be possible to do so]
OK, I shall change that to SHOULD.
Item 11.
>8.7 "However, he MUST NOT alter the order in which the
> newsgroups are listed in the Newsgroups-header."
>[pgpmoose's crossposting scheme alters the order of groups in the
>Newsgroups header]
That sounds to me like a Bad Thing (could break some digital signatures).
Anyone else want to take it further?
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5