ietf-nntp Discussion of draft-dfncis-netnews-admin-sys-04.txt

[Robert Schuettler]

Hello everyone,

this is meant to sum up the points raised in discussion of the NAS draft
so far. Please let me know if I missed out on something vital.

o "wildmat" definition

The term "wildmat" is used on page 19 in the context of the LSTR
command. There is no explicit specification within the NAS draft but a
note that the term is used according to "wildmat(3) from libinn". If an
explicit definition is really necessary and wanted within the NAS
document, we could probably borrow it from section 5 of 
draft-ietf-nntpext-base-15.txt.

o authentication 

The GETA and GETP commands are the two commands that are intended for
server-server communication. They would trigger a NAS server to update
the data in its database if newer data is available. All other commands
are used by enduser-clients, so only GETA and GETP have a username
/ password authentication attached.

o amount of data created by GETA and GETP commands / diff option

The amount of data transmitted in a package does not really seem to be
that huge to me. It is not the actual FAQ, rule or netiquette text that
is transmitted after all but only the location where to find it. An
option to send only the things that have changed is a neat idea that
we should keep it in mind for a higher protocol level.

o timestamp

The timestamp is defined as UTC in seconds at the moment. There is no
problem in changing that to a finer grade if that is really necessary
(but that doesn't completely solve the potential problem).

The problem scenario would look like this: Server-A updates its
database twice during the same second (also tenth or hundredth of a
second) and attaches the same timestamp to the package. Server-B
retrieves a package from Server-A within that split second (i.e. it
picks up the older data) and then does not know that it is necessary to
update again because it believes that there is no newer data available.

Possible solution: The timestamp needs to be increasing, i.e. Server-A
will wait the rest of the second before it updates a package (or it
could just increment the timestamp).

I would like to keep the timestamp format the way it is and simply add
the requirement for implementations that a server must not create two
versions the same second.

o MIME type definition

We can add a IANA Considerations section to the draft to get the MIME
type registered if that is all that's needed.

o PGP keys

We'll try to revise the PGP definition(s) according to RFC 2240.

o protocol version number vs. querying the server for extensions

The current approach is to specify a NAS protocol version number to
allow for later updates and to make sure that all NAS compliant
software will be backwards compatible down to protocol version 1. 

A possible alternative would be to have clients query the server to see
which extensions it supports. The main benefit of this approach could
be that not all features of a given protocol level would need to be
implemented (or activated).

However, the existing approach does not bar the way for a
server-extensions command on a higher protocol level. :-) Both
approaches have advantages and are not mutually exclusive. One
advantage of the protocol level version is its shortness. If NAS
queries via UDP were to be implemented, shorter "cheaper" queries via
UDP are conceivable so that news clients could check if a group is
moderated/unmoderated or pick up a groups description line often.

I would like to keep the version number approach for the moment - but
also keep the extension command in mind if the need arises on a higher
protocol level.

o blank lines between individual group data for added readability

No problem. We'll add a blank line between group data blocks in GETP
and GETA.

o line breaks in key-value pairs?

It may look like there are line-breaks in the examples (i.e. bottom of
p. 28) but that is due to the text formatting constrains in the draft.
The information is intended to be on a single line - as defined by the
ABNF.

o line length

We do not state how long a line can get. Theoretically they could be
unlimited, but all real-life implementation will necessarily put a
certain limit, and it will be up to the programmers in question what
error message to produce. We can supply an error number for that within
the draft.

Hope this addresses all the main points for the moment. You can connect
to nas2.cis.fu-berlin.de on port 991 to test-drive our implementation
of an NAS server if you want.

Best regards, Robert Schuettler

-- 
Robert Schuettler                     | rober at cis.fu-berlin.de
Freie Universitaet Berlin             |
Center for Information Services (CIS) | http://www.cis.fu-berlin.de