ietf-nntp Currently outstanding issues

[Clive D.W. Feather]

Russ Allbery said:
>> 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.

Given it's been a week, I'm going to start editing these in.

> Section 3.1:
> | Should the initial response line be limited to 512 octets as well? 

Change made.

> Section 3.2:
> | 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.

I've added a Future Directions appendix.

> Section 3.2.1:

[403 v 503]

Deleted.

> | OUTSTANDING ISSUE
> | This isn't a complete solution to the 480 issue;
[...]
> | 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.

I want to think further on this but, in the meantime, does anyone use 48x
codes *with existing commands* to mean anything other than "you are missing
an authentication or privacy extension"?

> | OUTSTANDING ISSUE
> I believe 401 should just be dropped.

Okay.

> Section 3.4:
> | 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?

I'm planning to write it. In general, imperative verbs in outstanding issue
blocks are aimed at me.

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

Okay. For now, I have:

   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); there MUST still be some other octet between
   any two CRLF pairs in a header line, and some other specifications
   require there to be at least one octet other than %x09 or %x20.
   (Note that folding means that the header line occupies more than
   one line when displayed or transmitted; nevertheless it is still
   referred to as "a" header line.)

but the "other specifications" bit will go when I move all that stuff out
into an addendix.

This change simplifies the formal syntax as well.

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

   The third is plain text intended to describe the entity that created
   the newsgroup; it is often a mailbox as defined in RFC 2822.

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

I'm still thinking about this. The problem with a SHOULD is that it makes
it impractical to rely on from a client point of view.

In trying to solve this, how much can we force servers to change?

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

Okay.

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

Okay.

> Section 8.5.2.2:
[LIST OVERVIEW.FMT]
> Let's go with your proposal except without the ? suffix.

Okay.

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

I haven't completely caught up with that discussion; I'd like a chance to
do so before agreeing or objecting.

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

Of course.

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

Right.

> Section 12:
> | OUTSTANDING ISSUE
> | Why RFC 1939?
> Stan answered this somewhere back in the list archives.

I'll look.

<FX: delay>

It influenced how he laid out the original draft. On that basis, I think it
should come out.

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