[ietf-nntp] Re: ietf-nntp Niggles

Charles Lindsey chl at clerew.man.ac.uk
Tue Dec 9 15:09:50 PST 2003


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

This message from Clive seems to have been sitting in limbo for around
a month (I first saw my own CC of it on Nov 11th or thereabouts, and
replied to Clive directly).

Anyway, it mostly seems OK. Just a few comments.

>>    If the requested header is not present in the article or if it is
>>    present but empty, a line for that article is included in the output
>> 
>> That is not my understanding of the case when the requested header is absent
>> from the article, and it is not consistent with what is said on the previous
>> page:
>> 
>>    If the information is available, it is returned as a multi-line
>>    response following the 225 response code and contains one line for
>>    each article where the relevant header line or metadata item exists
>>    (note that unless the argument is a range including a dash, there
>>    will be at most one line but it will still be in multi-line format).
>> 
>> If my interpretation is correct, then the example in the following section
>> needs fixing also.

>I see that Russ isn't sure either.

>There's four situations to consider:
>(1) Header present and has content.
>(2) Header present but empty.
>(3) Header not present.
>(4) No article.

>(1) is easy. (4) is agreed - omit the article from the response. The
>question is over (2) and (3). I think (2) should be included in the
>response and am agnostic over (3).

>I will wait for consensus.

OK, this is still an outstanding issue which we need to decide.

>> P78.
>> 8.6.2 LIST HEADERS

>Answered by Russ.

>> P83.
>> 
>>      A-NOTGT    = %x21-3D / %x3F-7E  ; exclude ">"
>>                                                ^^^
>> 					       SP and ">"
>>
>> (for the removal of all doubt - see earlier).

>And have you looked 6 lines above? Also see earlier.

>> P94.
>> 
>>    It has been proposed that the response code range 6xx is used for
>>                                                          ^^
>> 							 be
>>    multiline responses.

>Fixed.

>> P95.
>> 
>>    NNTP is most often used for transferring articles that conform to RFC
>>    1036 [RFC1036] (such articles are called "Usenet articles" here). It
>>    is also sometimes used for transferring email messages that conform
>>    to RFC 2822 [RFC2822] (such articles are called "email articles"
>>    here). In this situation, articles must conform both to this
>>    specification and to that other one; this appendix describes some
>>    relevant issues.
>> 
>> Maybe you should be speaking of "Netnews articles" rather than "Usenet
>> articles". Opinions are often divided as to how "Usenet" is defined. Usefor
>> has taken the view that "Netnews" is the protocol, and "Usenet" is the
>> particularly large and well-known instantiation of that protocol.

>Okay, I'm happy to be consistent with this.

>One query - we have "global Usenet system" in the text. Should this
>change to "global Netnews system" or not.

>> Also, I believe it is customary to speak about "Usenet/Netnews _articles_",
>> but "Email _messages_".

>But they're "articles" in our document.

>>    Every article handled by an NNTP server MUST have a unique
>>    message-id. For the purposes of this specification, a message-id is
>>    an arbitrary opaque string that is merely needs to meet certain
>>                                              ^^^^^
>> 					     needed
>>    syntactic requirements and is just a way to refer to the article.

>No, "that merely needs to meet".

>>    This specification states that message-ids are the same if and only
>>    if they consist of the same sequence of octets. Other specifications
>>    may define two different sequences as being equal because they are
>>    putting an interpretation on particular characters. RFC 2822
>>    [RFC2822] has a concept of "quoted" and "escaped" characters. It
>>    therefore considers the three messages-ids:
>>                                  ^^^^^^^^^^^^
>> 				 message-ids

>Oops.

>> P96.
>> 
>>       <abcd at example.com>
>>       <"abcd"@example.com>
>>       <"ab\cd"@example.com>
>> 
>>    as being identical. Therefore an NNTP implementation handing email
>>    articles must ensure that only one of these three appears in the
>>    protocol and the other two are converted to it as and when necessary,
>>    such as when a client checks the results of a NEWNEWS command against
>>    an internal database of message-ids.
>> 

>> More importantly, I think you should make it clear that this nonsense is NOT
>> needed with Netnews, (whether you take the definition of Message-ID from RFC
>> 1036 or from Usefor, which has taken great care to avoid it).

>What is the current definition in Usefor? Which of those three IDs is
>legal? I'm happy to add text when I know where we are.

The current Usefor draft says:

   Msg-ids are redefined to be a "normalized" subset of those defined by
   [RFC 2822], ensuring that no string of characters is quoted unless
   strictly necessary (it must contain at least one mqspecial) and no
   single character is prefixed by a "\" in the form of a quoted-pair
   unless strictly necessary, and moreover there is no possibility for
   ">" or WSP to occur inside a msg-id, whether quoted or not. Thus,
   whereas under [RFC 2822]
      <abcd at example.com>
      <"abcd"@example.com>
      <"ab\cd"@example.com>
   would be considered semantically equivalent, only the first of them
   is syntactically permitted by this standard, and hence a simple
   comparison of octets will always suffice to determine the identity of
   two msg-ids.

There then follows some not-so-pretty syntax which achieves that effect.

-- 
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



More information about the ietf-nntp mailing list