ietf-nntp draft-ietf-nntpext-base-17

[Clive D.W. Feather]

Charles Lindsey said:
> p2. OUTSTANDING ISSUE
>       Documents should be referred to everywhere they occur, unless
>       there are two references close together (e.g. in the same section).

Okay unless there are screams otherwise.

>       BTW, I don't like the RFC 1234 [3] style. I prefer the [RFC 1234]
>       style. Note, in any case the confusion between [1] meaning a
>       reference and [1] meaning a footnote.

There's no easy way to change this in xml2rfc that I know of. More
precisely, though the manual says how to do it, it doesn't work and I don't
fancy trying to debug many kloc of tcl.

> p9. OUTSTANDING ISSUE
>       Leave it as it is. It seems to be the fashion :-)

It is?

> P10. OUTSTANDING ISSUE (initial response lime)
>       No.

Why not?

> p18. '?' in wildmats
>       This is supposed to work with UTF-8 chars. Clearly any existing
>       implementation of '?' will not so work.

True, but the change to UTF-8 is known to be incompatible.

>       There was recent discussion of this in the Usefor list where it
>       was alleged that '?' did not occur in any prior standard, and
>       that it was being excluded from the new NNTP draft so as to avoid
>       confusion with existing unofficial usage.

Someone is confusing this with [...]. We agreed the wildmat text about a
year ago!

>       What was our position on this the last time we discussed it?
>       I thought we had managed to arrange that existing wildmat
>       implementations would work with UTF-8 (e.g. we removed the [...]
>       notation).

The text in draft 17 is what was agreed on this list.

> p18. It says:
>    ...  Backslash is commonly used to supress the special
>    meaning of characters and brackets to introduce sets, but there is no
>    existing standard practice for these in wildmats and so they were
>    omitted from this specification.

Already addressed.

> p25. LIST EXTENSIONS
>       Anyway, it says:
>    ...  This command MUST be
>    implemented by any server that implements any extensions defined in
>    this document.
>       It would be useful to add "or in any other standards-track
>       extension", or even in any future informational or experimental
>       extension.

I've added "or any other extension in the IANA registry".

> p26. Extension labels and parameters
>       It would be useful to say what characters are allowed in these.

In the absence of any other specification they are just non-space/TAB
sequences. I wouldn't want to restrict extensions as to what they can use,
but I'll add a bit of text.

>       The syntax at the end seems to say ASCII letters (hence uppercase
>       letters) but nowhere is the syntax of parameters given.

Um, what are you reading in the syntax that suggests just ASCII?

> p27. Message-ids

Taken up in separate thread.

> p34-19   header, -> headers,
>       for consistency with useage elsewehere.
>       Also, would it be better to say 'empty' rather than 'blank'? It
>       needs to be absolutely clear that this line has no WS in it.

Actually that's a Usefor matter: NNTP has the concept that there are two
parts to an article, and ARTICLE returns both while HEAD and BODY return
one only, but - as mentioned elsewhere - we aren't as picky.

What I think I need to do is to write a section describing basic News
concepts like this, making them fairly loose and pointing at 2822, 1036,
etc. for more specific details and uses. [Someone else suggested this
already; I've just saying that it's worth doing.] That then finesses things
like this "blank line" issue.

> p43.  "A response of 240 ... the posted article will be made available on the
>        server ..." and later on
>       "The intent is that the server just passes the incoming message
>       to be posted to the server installation's news posting software,
>       which is not defined by this document."
>       
>       I think it would be useful to indicate here, at least at the
>       "Note" level, that mailing to a moderator is an alternative action
>       in appropriate cases.

I've already added something about a moderation process further down that
section.

> p48.  "All servers MUST implement these commands."

Actually I'm going to delete this, since it's repeating something earlier.
It originally went in to deal with the "NEWNEWS is optional" brigade.

> p53.  Is it possible for the list returned by LIST ACTIVE to be empty?

Yes; it already says so.

> p54.  "Other status strings may exist.  The definition of these other
>       values and the circumstances under which they are returned is
>       covered in other specifications."
>       What "other specifications" have you in mind?

Not my text, though I note this has been addressed elsewhere.

> p55.  "If the optional wildmat parameter is specified, the list is limited to
>       only the groups whose names match the wildmat (and therefore may
>       be empty)."
> 
>       I believe an empty list is possible even when no wildmat is provided.

If the server has no groups, right? Okay.

> p67.  OUTSTANDING ISSUE
>       Should this be 502 ("not permitted") or 503 ("there is no overview
>       database")? In which case, why provide the command?
>       
>       Maybe the client did an AUTHINFO and acquired a higher privilege
>       which made the command available to him.

Hmm.

> p73.  OUTSTANDING ISSUE
>       Should this be changed to require the name to *begin* with a colon?
> 
>       Sorry! Don't understand the question.

At present the proposed rule is "contains colon = metadata item,
no colon = header". The question is whether this should be changed to
"begins with colon = metadata item, no colon = header,
colon elsewhere = error".

> p76.  "11. Augmented BNF Syntax for NNTP Commands"
>       A reference to RFC 2234 would be useful here.

Sneaked one in.

>       BTW, is this section normative?

Yes, it is. It shouldn't contradict anything else. Do we need to say that,
in case of discrepency, this section wins?

> p77.  "header-name-char = %x21-39 / %x3B-7E ; exclude SP and :"
>       This seems excessively liberal. Granted it is what RFC 2822 says,
>       but Usefor chose to restrict them to something much closer to what
>       actually occurs in the wild.

See above concerning format description.

> p77.  "message-id"
>       Something nasty seems to have happened to the formatting here.

Fixed, I hope.

> In any 
> case, it might be better to include the more limited systax for RFC 2822, or 
> even from Usefor.

Another thread.

> p77. "UTF8-1"
>       See draft-yergeau-rfc2279bis-04.txt which is currently up for IETF
>       last call. It includes a full syntax for UTF8, and you need to
>       check that you conform to that and use their notation. Note also
>       that they now exclude entirely all those cases which could give
>       rise to code points beyond U+10FFFF.

I'll note this. What's the timescales on this?

> p80.  "o replacing such sequences by a "guessed" valid sequence (based on
>       properties of the UTF-8 encoding);"
> 
>       That "guessing" is a definite MUST NOT in both RFC 2279 and RFC
>       2279bis (and also in Usefor). I suggest you take it out.

Okay. I thought I got this from the last inter-list discussion.

Are you saying that, if I receive 0xC1 0x96, I MUST NOT convert it to 0x56?

> p83.  Since the draft does not mention AUTHINFO, do we still need the
>       reference to Chris Lewis?

It's still one of the motivators.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive at davros.org>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |