ietf-nntp Notes from the NNTPEXT Meeting today at IETF 46

Stan O. Barber sob at verio.net
Mon Nov 8 15:25:46 PST 1999


Thanks to John Stracke for taking the notes on which this report is based:

Stan Barber presented the current status of the NNTP base draft. It is currently
in the 13th release. Ned Freed then led the discussion on issues brought up
about the current draft:

Wildmat-- The new draft contains specific language that clarifies the use of the
exclamation point. It can only have special meaning as the first character of a
wildmat and in that context negates the meaning of the rest of the wildmat. No
one at the meeting had any objections to that usage.

Security Consideration Section -- The new draft contains a much expanded
Security Considreations Section based on RFC 2616 (HTTP 1.1 Spec). There were
two basic considerations that were discussed:

1. Should the DNS Spoofing prevention be a MUST or SHOULD implement? The
consensus of the group was to leave it as is with a SHOULD.

2. Should this specification attempt to perscribe solutions that depend on the
contents of an article? There was no interest in doing that. Stan suggested that
was best left to the security consideration in the USEFOR documents.

Response Codes -- IHAVE

The current draft contains an example where an article is presented to a server
and then the server generates a 435 error. The group decided to
change this to 437.

Response Codes -- PAT

The current draft uses 502 as a generic error code for any error response other
those covered by the 4XX error responses defined in the draft for PAT. There was
some concern about havin additional response codes for other conditions (lie
those that might occur if a PAT request
came in for a header that is unindexed by overview). It was decided that 502
would continue to be user as a generic error code for all kinds of
errors except those covered bythe 4XX error responses defined in the draft for
PAT.

UTC or not -- NEWNEWS/NEWSGROUPS

It was decided to drop this from the spec if it has no server implementations
that actually attempt to use UTC (instead of GMT). We need those on the list to
let us know if they know of servers or clients that use this.

Stan then returned to lead a discussion about the NNTP-AUTH draft.

The main concern there was the error codes. In the common practices
document, the error codes are in the X8X group. In the draft, they 
are in the X5X group. How will new servers that are coded to work with
both old and new clients be able to handle both? It was decided to alter
the draft to add a "transition considerations" section. In that section,
it would say that servers configured to provide both the legacy common
practice impmenetation and the new standard implementation would
defult to the common practice implementation until the client issues the
LIST EXTENSIONS command. At that point, the server would switch to using
the standard extension for the rest of the session. Servers that only
implement the new standard are not required to support the old one.



More information about the ietf-nntp mailing list