[NNTP] LIST EXTENSIONS (again)

[Mark Crispin]

On Fri, 5 Nov 2004, Ken Murchison wrote:
> I agree with all of Russ' points.  No surprise, since he has agreed with most 
> of my opinions on this topic  ;)

I think that I do as well, but I need to digest his message more 
thoroughly.

> Works for me.  The only question that I have is whether these capabilities 
> are advertised as arguments to NNTPv2 or as standalone extension labels?

IMHO, standalone labels are easier to deal with.  Ease of client 
implementation has priority over before syntactic sugar.

>> After Mark's messages, I've been convinced that we should mandate the
>> order of the state change commands.  The correct order as near as I can
>> tell would be:
>>     MODE READER
>>     STARTTLS
>>     AUTHINFO
> If we do this, then I can add the same language to STARTTLS and AUTHINFO that 
> I proposed for yesterday for OVER, etc.

I wish that I could sign off on this, but I don't recall precisely which 
server(s) issued a 480 to MODE READER.  I won't sign off on this unless 
that 480 is explicitly forbidden.

>> One could cut this down by one more command by adding some sort of initial
>> extension advertisement to the greeting, but this worries me for the
>> reasons stated by Clive and Andrew, just in a cleanliness sense.  It's
>> worth considering, though.
> I understand that most folks find this proposal somewhat "distasteful" (for 
> lack of a better term), but does anyone have any *technical* reasons why this 
> can't work?

IMAP status response codes and SMTP extended response codes both prove 
that it can (and does work).

>> One can also gain a round trip with a different idea, namely having
>> successful successful AUTHINFO SASL (which is a new commands, so we can do
>> whatever we want with it) include LIST EXTENSIONS output in its response.
>> I'm not sure what I think of that; I'm guessing it's a bad idea since no
>> one else does it.
> I don't think IMAP disallows it.  Mark, does your server do this?

My IMAP server used to issue an untagged CAPABILITY response to a LOGIN or 
AUTHENTICATE command, but this annoys IMAP2 clients (believe it or not, 
such things still exist in the world!).  As a result, it's now carried in 
the command response (which is completely compatible with IMAP2).

Here is a startup from a real IMAP4rev1 session:

S: * OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS STARTTLS LOGINDISABLED AUTH=CRAM-MD5 AUTH=ANONYMOUS] Ikkoku-Kan.Panda.COM IMAP4rev1 2004.355 at Fri, 5 Nov 2004 08:06:25 -0800 (PST)
C: 00000000 STARTTLS
S: 00000000 OK STARTTLS completed
C: 00000001 CAPABILITY
S: * CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND SASL-IR LOGIN-REFERRALS AUTH=CRAM-MD5 AUTH=PLAIN AUTH=LOGIN AUTH=ANONYMOUS
S: 00000001 OK CAPABILITY completed
C: 00000002 AUTHENTICATE CRAM-MD5
S: + PDQyMzguMTA5OTY3MDc5MUBJa2tva3UtS2FuLlBhbmRhLkNPTT4=
C: bXJjIDM2M2I1NzU3YjVmMDY3ODI1YjkxZGVlODM5Y2IwZmJl
S: 00000002 OK [CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User mrc authenticated

Note that this entire exchange was just 4 RTTs.  It would have been 3, 
except that the CRAM-MD5 SASL authenticator requires a server challenge.

Note also that there are many more capabilities, and a much more complex 
protocol, than in NNTP; yet the responses were still much smaller than 512 
octets.

If we had been clever with TLS, we would have designed STARTTLS so that 
there was an intermediate response (not under TLS) and a final response 
(under TLS) so the exchange looked like:

C: 001 STARTTLS
S: + TLS starting, switch now
S: 001 OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS AUTH=CRAM-MD5 AUTH=PLAIN AUTH=LOGIN AUTH=ANONYMOUS] If you see this we are talking TLS

This would have eliminated the need for the extra CAPABILITY command and 
thus reduced another RTT.

> I don't see any technical reasons why we can't.  The only issue would be that 
> if a SASL security layer is negotiated, any extensions returned in the 
> response would probably be ignored by the client anyways, since the response 
> is sent in the clear.  Only subsequent commands (e.g. LIST EXTENSION) are 
> protected by the SASL security layer.

Same comment about more cleverness applies here too.

>> (Although I'm wondering how often authenticating
>> is really going to change anything other than noting that you can no
>> longer run STARTTLS or AUTHINFO again, and if clients would really need to
>> check there.)
> I'm probably not qualified to answer this, but might there be a case where 
> "lightweight" reading is offered for free (w/o authentication), but more 
> "expensive" commands such as NEWNEWS or OVER or some future XSEARCH are only 
> allowed to (paying) customers that authenticate?

Right.

Also, servers which require authentication may decline to advertise their 
feature set to hackers who don't have an account.

>> Do we want to get into advertising whether commands are permitted for a
>> particular client?  (POST and NEWNEWS are the ones most frequently not
>> permitted.)
> Doesn't the 201 response signal that POST is disabled, or I'm I completely 
> clueless?  NEWNEWS can probably just spit back 503, correct?

Yes!!  There should be a POST and NEWNEWS capability, and less reliance 
upon magic response codes.

Done right, clients should be able to care only about the first digit of 
the response code.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.