[NNTP] Future-proofing for including capabilities in responses

[Clive D.W. Feather]

Russ Allbery said:
> Okay, we're going down the path of arguing about the best solution, which
> is exactly what I was trying to avoid.  My understanding is that you feel
> there's already enough leeway for someone to add capability responses
> after STARTTLS or AUTHINFO in the existing draft provided that we add that
> final response to STARTTLS?

Correct.

> Do we have a consensus to add that final response to STARTTLS to enable
> work in this area in the future?  Ken, are you uncomfortable doing that
> given the existence of earlier implementations that don't return a final
> response?

Actually, thinking further, we don't need a final response to allow us to
provide capabilities update as part of an extension - whatever mechanism is
used to provide the update can be used anyway, with a dummy response code
if necessary. We *only* need the final response if you want to piggy-back
on the free text.

[It's still neater, in my opinion, to have a final response.]

> If we don't have consensus on reserving characters in free-form text for
> future extensions in this area, we don't have consensus, and we should
> move on.

I've been thinking a bit more over the weekend. I've had several objections
to the use of free text, but one of them has been that you can't reliably
tell free text from any new usage. RFC 977 stated that NNTP was 7 bit, and
the extension to UTF-8 is only just starting with our document. So I could
live with the approach I mentioned before, that if the "free text" begins
with a specific non-ASCII escape code, it is instead some other form of
data, reserved for future expansion. Could others live with that?

[I still think this is the wrong way to do capability updates, but I can
see other potential uses for it.]

Something like this:

    The server MAY add any text after the
    response code or last argument as appropriate, and the client MUST
    NOT make decisions based on this text.  Such text MUST be separated
    from the numeric status indicator or the last argument by at least
|   one space. The text MUST NOT begin with the three octets %xE2.81.A3
+   (the UTF-8 encoding for U+2063 "Invisible Separator"); this code is
+   reserved for future versions of this specification.

or

|   one space. Future versions of this specification may allow a server
+   to provide additional data instead of this text; any such data will
+   begin with the two octets %xC0.9B (this sequence is an invalid UTF-8
+   encoding of U+001B "Escape" and so cannot appear in a response).

and syntax change:

-   simple-response =
-       simple-response-content [SP trailing-comment] CRLF
+   simple-response = simple-response-content
+       [SP (trailing-comment/additional-response-data)] CRLF
+   additional-response-data = additional-response-flag additional-response
+   additional-response-flag = %xC0.9B
+   additional-response = X-additional-response
+   X-additional-response = *U-CHAR

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