Issues with CAP "transport" protocol

[Chris Newman <chris.newman@xxxxxxxxxxxx>]

Here are the issues with the CAP "transport" protocol I raised at the IETF
meeting.  These are based on my experience with other protocols.  [I
apologize if some of these duplicate list traffic, as I'm 1200 messages
behind on this list.]

"Transport" protocol
====================
Using the OSI model, TCP/IP is the "transport protocol" and all of CAP is
layered on top of it.  So what's called the "transport" protocol in the
draft should either be called a "session-layer" protocol, a
"presentation-layer" protocol or dodge the whole protocol-stack issue and
call it a "transfer" protocol.

NOOP command
============

If there's an idle timeout, and you want the ability for the client to hold
the connection open for later use, then there should be a NOOP command.  I
was told that the list didn't want ability for client to keep connection
alive but idle.

AUTHENTICATE success data
=========================

SASL permits a SASL profile to optionally return server mutual
authentication data with a success code.  In the case of DIGEST-MD5, having
the ability to include a base64 string of SASL data with the success
response code will save a round trip.

Response-codes and text
=======================

The response codes are numeric -- this means that anyone looking at the
protocol trace will likely need to look up the numbers (especially since
debug text may or may not reflect the meaning of the specific error code).
Personally, I much prefer short mnemonic strings for machine-parsable error
codes so that debugging is easier.  I was told the list already reached
concensus on using numbers.

Also, if there's human readable text included with response codes, then
there needs to be a specified language for that text.  It can be done as:

The text is "i-default" meaning it's in English intended for international
readers, and may also include a translation of the text appropriate to the
locale.

Or the client can negotiate the language it wants text to be in.

DISCONNECT -> QUIT/LOGOUT
=========================

I requested that the "DISCONNECT" command be renamed to "QUIT" to match
other IETF protocols (and also be shorter to type).

Additional Authentication Errors
================================

In using SASL, I've identified a number of useful authentication error
codes:

* Generic Success (no data)
* Successful Authentication with mutual authentication data
* temporary authentication failure (e.g., backend auth server down)
* invalid authentication mechanism
* authentication failed (aka bad user name or password)
  - note it's important to treat "unknown user" and "bad password" the same.
* authenticaiton exchange cancelled
  - may not need to be distinguished from "authentication failed" since
client
    knows what it did.
* authentication mechanism too weak
  - the server requires a stronger authentication mechanism (usually on a 
    per-user basis).  Note that this could reveal that the username is valid
    to an attacker; however having a way to force users to a stronger
mechanism
    which clients are aware of may be well worth the additional issue.
* encryption required
  - the server refuses the requested mechanism, unless an encryption layer
(e.g.,
    STARTTLS) is negotiated first.  Note that it's better not to advertise
such
    a mechanism until after STARTTLS, but some sites may want to be able to
    control such restrictions on a per-user basis.
* expired passphrase
  - the passphrase was correct, but has expired.  The user will have to
contact a
    passphrase change server prior to authenticating successfully.
* transition needed
  - the user is valid, but the server does not have an entry in the
    authentication database for the requested mechanism (e.g., DIGEST-MD5).
If
    the user successfully authenticates using a plaintext password, then the
    backend entry will be updated.  Note that if the client chooses to fall
back
    to plaintext password authentication it should enable an encryption
layer
    or get user-confirmation that a one-time transition is acceptable.
* user account disabled
  - the user will have to contact the sysadmin to get their account
re-enabled.
    having a distinguished code prevents clients from treating it as a "bad
    password" situation.

Response code data model
========================

The spec need a clear data model for when response data is present, when it
isn't, and which data is machine parsable or human readable.  For example,
some of your error codes return URLs in the field usually reserved for
"debug text" intended for humans.  Since this is an exceptional situation,
you need a way to distinguish such handling from "normal" handling (or
eliminate the exception).

Also some examples show:
	#.#.# text CRLF
        <multiple lines of data>
        .
and others show just:
        #.#.# text CRLF

So either the <multiple lines of data> should always be present, or there
should be some way to tell if it will be present based on the error code.

Layer violation
===============
The "CREATE" method has a serious layering violation between the
"transport" protocol and app protocol.  Specifically, multiple "transport"
layer status responses are returned based on the number of "Target:" items
in the application layer request.  This indiates that the status responses
are really application layer status responses.

		- Chris