ietf-nntp Currently outstanding issues

[Russ Allbery]

Clive D W Feather <clive at demon.net> writes:

> I have just sent draft 18 to the Internet-Draft repository; it should
> appear there in the next day or two.

> You can also fetch it from my web site:
>     http://www.davros.org/nntp-texts/draft18.txt
>     http://www.davros.org/nntp-texts/draft18.html

> I believe that all open issues are now covered in "OUTSTANDING ISSUE"
> blocks.

I'm going to make statements of the resolution that I think all of these
outstanding issues should have.  If anyone *disagrees*, please speak up.
Otherwise, I expect we'll go to last call with the issues resolved as
follows.

Section 3.1:

| OUTSTANDING ISSUE
| 
| Should the initial response line be limited to 512 octets as well? 
| Possible text:
| 
| The first or only line of the response MUST NOT exceed 512 octets, which
| includes the response code and the terminating CRLF pair.
| 
| The text further down about "does not place any limit on the length" would
| need equivalent edits.

Yes.  The first line of a multiline response is going to be parsed by the
same code as the single line of a regular response and the limit is useful
for the same reason.  The client code can't tell if the response is going
to be multiline until it's parsed that first line.

Section 3.2:

| OUTSTANDING ISSUE
| 
| I proposed that we assign 6xx for extensions and future commands to use
| for multiline responses, thus at least limiting (if not eliminating) the
| problem clients have of working out whether one is coming up. Nobody was
| violently against the idea, but nobody was particularly in favour
| either.

I think this is premature, as there are a lot of existing extensions we
still haven't documented that don't follow this approach.  I don't think
this would cause any real problems, but we would also need to wordsmith it
and we really need to get a last call out.  So I think this should be
omitted for the time being and revisited when we come back to this
standard again.

Section 3.2.1:

| OUTSTANDING ISSUE
| 
| Do we need to add text like:
| 
| For backwards compatibility a server MAY return the response code 503
| where this specification requires the response code 403, and a client
| SHOULD be prepared for this. This waiver may be removed in a future
| revision of this specification.

I don't think we need to add this.  Servers can update their status codes,
and clients will do the right thing with either anyway.

| OUTSTANDING ISSUE
| 
| This isn't a complete solution to the 480 issue; what about the TLS
| extension, which uses 483 to mean "you need encryption". Should 480 be
| used for other than "you need authentication"? What code should be used
| to mean "can't do AUTH until after MODE READER"?
| 
| Do we need a more generic mechanism for "you must invoke extension X to
| do Y"?
| 
| The best proposal made so far is that all 48x codes, if returned from an
| existing command, mean "unavailable unless some authentication or
| privacy extension is invoked". Does this tie in with the issue of
| permitting existing commands not listed in an extension?

I think that's the right way to go.  The issue of not permitting existing
commands not listed in an extension we need to get into also; I don't
think that this ties in.

| OUTSTANDING ISSUE
| 
| It's not clear that we need 401; it appears to have been an
| invention. If we do keep it, then text is needed to indicate what
| happens with commands that change the status (for example, if GROUP
| returns 401 what happens to the current selected newsgroup), and how to
| make those commands work.

I believe 401 should just be dropped.

Section 3.4:

| OUTSTANDING ISSUE
| 
| This section is new. If anyone has better wording, I won't complain.

Seems fine to me.

| OUTSTANDING ISSUE
| 
| Need to add an appendix that spells out how this document interacts with
| RFC 1036. That would allow us to remove some of the convoluted wording
| about "other specifications".

Yes, that would be great.  Were you planning on writing that or should we
try to get someone else to write it?

| A header may be "folded"; that is, a CRLF pair may be placed before any
| TAB or space in the line (including the space after the colon after the
| header name), except that there MUST be at least one octet other than
| %x09 or %x20 between any two CRLF pairs in a header line.

The exception isn't required for NNTP; I think we should drop it from this
specification.  (The line has to contain some character, but
whitespace-only lines don't break anything in the NNTP protocol.  If RFC
1036 or USEFOR wants to outlaw them separately, that's great.)

Section 7.6.2.2:

| OUTSTANDING ISSUE
| 
| Should the third field simply be free-form, or should it be recommended
| usage rather than mandatory? The problem with "mailbox" is that mailbox
| requires that it be fully qualified, and unqualified addresses are
| apparently very common for groups created directly by the administrator.

Yes, it should be free-form.

Section 8:

| OUTSTANDING ISSUE
| 
| As worded, this forbids commands like MODE SLAVE that servers already
| provide but that aren't part of an existing extension. We can't simply
| make these illegal.
| 
| The wording about starting keywords with an X could be reduced to a
| SHOULD, except for backwards compatibility (with a pointer to RFC
| 2980). But is that the right answer?

If anyone else has any better ideas, speak up.  Otherwise, we should go
with SHOULD plus an exception for backward compatibility.  (MODE STREAM is
the example that you want, I think.)

Section 8.4:

| OUTSTANDING ISSUE
| 
| Do we need a separate private namespace? For example, we could reserve
| :name for extensions and ::name for implementation use.

Let's reserve :x- for private extensions, to stick with the whole idea of
x as a label meaning extension (and to match headers).

Section 8.4.1:

| OUTSTANDING ISSUE
| 
| Should this be called ":octets" instead?

No.  I think we reached consensus on this, at least among those people
expressing an opinion.

Section 8.5.2.2:

| OUTSTANDING ISSUE
| 
| Should this be optional even when the OVER extension is provided? Or
| even just removed entirely? What do we want to require about the OVER
| contents being consistent with the output of this command?

Let's go with your proposal except without the ? suffix.

Section 8.6:

| OUTSTANDING ISSUE
| 
| There is ongoing discussion about whether this extension should have a
| parameter and, if so, what it means.

Let's go with Ken's proposal here, for a LIST HEADERS command plus a
parameter that says all headers are provided.

Section 9.4:

| OUTSTANDING ISSUE
| 
| When draft-yergeau-rfc2279bis-04.txt replaces 2279, need to update
| references.

Yes.  This issue doesn't have to hold up last call.

Section 11.5:

| OUTSTANDING ISSUE
| 
| Yergeau says that you MUST detect illegal sequences. He also rejects the
| first bullet point and consequent text; I'm discussing it with him now.

I'll leave that to you.  If it's unclear, we should just pick something
and move on rather than spending a lot of time discussing this particular
point, as it's something of a side matter.

Section 12:

| OUTSTANDING ISSUE
| 
| Why RFC 1939?

Stan answered this somewhere back in the list archives.  I don't recall
exactly.  I don't think we necessarily need to explain it, so if we can't
find a good explanation, I'd just leave it as-is.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>