[NNTP] Future-proofing for including capabilities in responses

Clive D.W. Feather clive at demon.net
Fri Mar 25 04:35:39 PST 2005


Russ Allbery said:
>>>  * Reserve (i.e., forbid) the use of the characters [ and ] (or some other
>>>    pair, if another pair looks better) in all freeform text in NNTP
>>>    responses, with a warning that those characters may be used for
>>>    protocol purposes in later standards.

> One thing that I should have mentioned is that I was aiming for enough
> leeway that would allow servers to return capabilities in the initial
> greeting as well as in response to commands.
[...]
> Sending CAPABILITIES with an additional argument or allowing multiline
> replies to AUTHINFO or STARTTLS doesn't solve the initial greeting
> problem.

Is there really a need for this? Is the initial CAPABILITIES command really
a problem? If you do it this way, you've still got the parsing problem,
in that the line has to be parsed in a totally different manner to the
normal CAPABILITIES response, and you've also got the question of what to
do if the capabilities list is too long to fit into the initial greeting.
Oh, and we haven't reserved a character that can be used to replace the
CRLF between capabilities. Finally, you're dumping a significant amount of
extra data on the client when it hasn't even asked for it.

I can see lots of mess building up and I just don't see the benefits.

> Being able to turn any arbitrary reply into a multiline reply the way that
> SMTP can do would be nice, but I think that's one of those things we're
> far too late to be able to add to NNTP.

That's not what I'm suggesting (I agree it's far too late). I'm suggesting
a "multi-line response" extension, or - if you prefer - a "response can
include capability information" extension. But it's an *extension* that
only gets invoked when the client asks for it (and so expects it).

>> Secondly, if information like this is put in the free text of responses,
>> it has to be parsed in a totally different way. We were unhappy with
>> this in the past (AUTHINFO SASL, I think) and I don't see that things
>> have changed.
> If one of the goals is to allow capabilities to be presented during the
> initial greeting, I don't see any way around this.

Circular argument - why is that a goal?

> However, the purpose is to reserve enough leeway that people can
> experiment, not hash out the best scheme on the list (since I think we've
> already established that consensus is unlikely).  Towards that end, I
> would be happy to reserve enough leeway for anyone's preferred schemes, if
> there are other provisions you can see that would make it easier to do
> something like this later.

This whole thing feels like it fits firmly in the "extensions" bucket, and
a general principle of extensions is that they don't affect anyone using
the existing protocol. Redefining the meaning of the free text just feels
absolutely and completely wrong to me.

Having said all that (yet again), let me point out that if you really do
want to put data in the free text, then using a delimiter like [] is a bad
idea for at least two reasons:
- it's not unlikely that it's been used already (having semantics in
  natural languages);
- it leads to more questions, such as whether you can have multiple []
  clauses and, if so, which ones have meaning.

A better approach is to define a character sequence WHICH IS VERY UNLIKELY
TO OCCUR IN THE WILD as an "end of free text" delimiter. Alternatively,
say that the sequence only has special meaning at the *start* of the free
text, and then indicates that the "free text" isn't.

I would suggest that suitable choices for the delimiter would be:
- %x1C (the "field separator" control character);
- %xC0.9C (which is the same thing encoded in an invalid UFT-8 way; this
  technically violates the existing syntax rules, which may or may not be
  a good idea);
- a rare control code, such as %xC2.95 (Unicode U+0095 "Message Waiting")
  or %xE2.81.A3 (U+2063 "Invisible Separator");
- %xCD.B3.CE.87 (U+0373 U+0387 "erotimatiko" followed by "ano teleia",
  which I picked because these characters are unlikely to occur in that
  order, are only two octets in UTF-8, *and* are not preserved by any of
  the four Unicode normalisation forms);
- if you really feel it has to be ASCII printable text, then something
  like "~fReE!" or something equally unreadable.

But I repeat that I feel it's a bad idea, and you've not justified the
need.

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



More information about the ietf-nntp mailing list