Subject: Re: Issues with CAP "transport" protocol

From: Doug Royer <[email-masked]>
Date: Thu, 13 Jan 2000 12:28:47 -0800

Chris Newman wrote:
> 
> 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.

Yes and thanks. We had been struggling to pick names.
(Issue: W-30)

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

True. With IMAP, many ISP's do not like the fact that IMAP allows clients
to keep an otherwise idle connection open with NOOP.
(Issue: W-31)

Perhaps could have a NOOP command that could be issued by a CUA
to indicate that the CUA wished the connection to stay alive subject
to CS administrative policy.
(Issue: W-32)

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

I do not understand what you are saying here. Are you suggesting a
default authentication?

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

We discussed this on the WG list (issues W-10 & W-11)

 W-10 CAP Text mandatory in all response        N
      codes
 
 W-11 CAP Text optional in response codes       Y
      (some response codes may have
       mandatory data that follows)

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

Issue: W-33

> Additional Authentication Errors
> ================================
> 
> In using SASL, I've identified a number of useful authentication error
> codes:
> .....

Thanks. We will work them into the next draft for comments.

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

I ~think~ that they are defined for an error code.

Issue: W-34

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

I don't understand the issue here.

---

From: Chris Newman <[email-masked]>
Date: Thu, 13 Jan 2000 14:56:30 -0800

--On Thursday, January 13, 2000 12:28 -0800 Doug Royer 
<[email-masked]> wrote:
>> 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.
> 

It should be possible to do:

C: <auth-command> <sasl-mech-name> <sasl-client-data>
S: <sasl-server-data>
C: <sasl-client-data>
S: <success-code> <sasl-server-data>

The profile of SASL in CAP doesn't include a way to include final 
<server-data> with the <success-code>, thus forcing and extra round trip:

C: <auth-command> <sasl-mech-name> <sasl-client-data>
S: <sasl-server-data>
C: <sasl-client-data>
S: <sasl-server-data>
C: <empty-message>
S: <success-code>

I was mentioning that DIGEST-MD5 is an example of an authentication 
protocol with this behavior.

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

The contents of the "app" layer impacts the number of responses generated 
at the "transport" layer.  This is a layering violation becuase you then 
can't write code for the transport layer without giving it specific 
knowledge of the "app" layer.  It'd be like making TCP/IP work differently 
based on whether FTP or POP was being used.

So you need to fix the layering violation.  You could have a single 
"transport" layer response code which includes app-level data with a 
response with a code for each "Target:" line in the app-level request.

		- Chris