[NNTP] LISTGROUP

[Charles Lindsey]

In <20050328140247.GI98698 at finch-staff-1.thus.net> "Clive D.W. Feather" <clive at demon.net> writes:

>Charles Lindsey said:

>> Now I am even more confused, because one has to define carefully when
>> "accept" applies and when "generate" applies.

>The above was my paraphrasing. The actual text reads:

>3.6:


Indeed. My problem was that the ABNF and the text with it did not fulfil
that promise. But you have now fixed it below.

>I think the text in 3.6 is approximately correct, but it mixes up roles.
>I will change it:

>-  The content of a header SHOULD be in UTF-8.  However, if a server
>+  The content of a header SHOULD be in UTF-8.  However, if an implementation
>   receives an article from elsewhere that uses octets in the range 128
>-  to 255 in some other manner, it MAY pass it to a client without
>+  to 255 in some other manner, it MAY pass it to a client or server without
>-  modification.  Therefore clients MUST be prepared to receive such
>+  modification.  Therefore implementations MUST be prepared to receive such
>   headers and also data derived from them (e.g.  in the responses from
>   the OVER (Section 8.3) command) and MUST NOT assume that they are
>-  always UTF-8.  How the client will then process those headers,
>+  always UTF-8.  Any external processing of those headers,
>   including identifying the encoding used, is outside the scope of this
>   document.

OK, so you have removed some possibly artificial distinctins between the
roles of serves and clients.

>I've added to LIST NEWSGROUPS:

>   The description SHOULD be in UTF-8.  However, servers sometimes
>   obtain the information from an external source which has used a
>   different encoding (one that uses octets in the range 128 to 255
>   in some other manner).  In this case they MAY pass it on unchanged
>   and clients MUST be prepared to receive such descriptions.

I think "sometimes obtain" is a little too strong, implying that was (or
might become) an accepted practice. (It might, but I hope it won't.)

So I would suggest rather "However, the information available to a server
might have arisen from an external source which had used a different
encoding (one that uses octets in the range 128 to 255 in some other
manner).  In this case they MAY pass it on unchanged.

And I have removed that "clients MUST", because it is not clear just what
that is requiring them to do. I think that anywhere a "MAY" occurs in a
standard there is an automatic implication that systems must cope with it
somehow (i.e. not too dis-gracefully).

In practice, it this occurs at all, it will be within cooperating subnets
where the clients will know what to do. Clients outside of the subnet will
display garbage.

>Finally, I've changed the formal syntax to:

>   Implementations MUST accept any content that meets this syntax:

>     S-CHAR   = %x21-FF
>     S-NONTAB = CTRL / SP / S-CHAR
>     S-TEXT   = (CTRL / S-CHAR) *B-CHAR

>   and MAY pass such content on unaltered.

Yes, that seems to fix the problem.

>   When generating new content or re-encoding existing content,
>   implementations SHOULD conform to this syntax:

>     S-CHAR   = P-CHAR
>     S-NONTAB = U-NONTAB
>     S-TEXT   = U-TEXT

>I could easily be convinced that that SHOULD should be a MUST.

Maybe. I think the point is that NNTP implementations never "generate" the
content we are talking about. Agreed if re-encoding ever takes place (and
when Usefor finally tackles I18N it may or may not call for re-encoding
somewhere in the protocols).

-- 
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 at clerew.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