ietf-nntp Section 12

[Clive D.W. Feather]

I've jumped to this because it fits with section 8, which I commented on
last night. I suggested there that various bits of text be moved here; I've
made those moves in this message.

> 12.  Framework for NNTP Extensions

[Fine to:

> The IANA shall maintain a registry of NNTP service extensions.

]

> Associated with each such extension is a corresponding NNTP
> keyword value. Each service extension registered with the IANA
> MUST be defined in an RFC. Such RFCs either must be on the
> standards-track or must define an IESG-approved experimental
> protocol.  The definition must include:

Change to:

  An extension is identified by an extension-label, which is an
  string of 1 to 12 uppercase letters. The extension-label will often
  be the name of a new command that the extension adds. However this
  is not a requirement: an extension might not add any new commands
  or keywords.

  An extension is either a private extension or else it is included in
  the IANA registry and is defined in an RFC. Such RFCs either must be
  on the standards-track or must define an IESG-approved experimental
  protocol.

  The definition of an extension must include:

> . the textual name of the NNTP service extension

  . a descriptive name for the extension

> . the label that is returned by LIST EXTENSIONS that would
>   indicate to the client that the server supports this
>   particular extension

  . the extension-label (which is returned by LIST EXTENSIONS to
    indicate to the client that the server supports this
    particular extension)
  . the syntax, values, and meanings of any parameters following the
    extension-label in the output of LIST EXTENSIONS

> . any new NNTP keywords associated with the extension
> . the syntax and possible values of parameters associated with
>   the new NNTP keywords
> . any new parameters the extension associates with any other
>   pre-existing NNTP keywords
> . how support for the extension affects the behavior of a server
>   and client NNTP
> . any increase in the maximum length of commands over the value
>   specified in this memo

They're all okay.

> In addition, any NNTP keyword value that starts with an upper
> or lower case "X" refers to a local NNTP service extension,
> which is used through bilateral, rather than standardized,
> agreement. Keywords beginning with "X" MUST NOT be used in a
> registered service extension.

Change to:

  The extension-label of private extensions MUST begin with "X".
  The extension-label of registered extensions MUST NOT begin with
  "X".

> Any keyword values presented in the NNTP response that do not
> begin with "X" must correspond to a standard, standards-track,
> or IESG-approved experimental NNTP service extension
> registered with IANA.  A conforming server MUST NOT offer non
> "X" prefixed keyword values that are not described in a
> registered extension.

Strictly speaking that paragraph isn't needed, but it doesn't hurt
(except that the first "must" should be "MUST").

At this point, insert the text moved from section 8:

  Except where stated otherwise, the commands in this document
  are understood (even if not supported) by all servers and are
  not described in the list of features returned by the LIST
  EXTENSIONS command.

> Additional keywords are bound by the same rules as NNTP
> keywords; specifically, keywords beginning with "X" are local
> extensions that MUST NOT be registered or standardized and
> keywords not beginning with "X" must always be registered.

Change to:

  A server MAY provide additional keywords - either new commands or
  new parameters to existing commands - as part of a private extension.
  These new keywords MUST begin with "X".

>
> 12.1 Initial IANA Registry

[This can remain unchanged, except that "Extension Label" should be changed
to "extension-label" for consistency.]

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