Subject: Re: Transport data mixed with Application data?

From: Doug Royer <[email-masked]>
Date: Mon, 2 Aug 1999 16:38:05 -0700 (PDT)

> Date: Mon, 02 Aug 1999 15:24:04 -0700
> From: [email-masked] (Steve Mansour)
> 
> Doug,
> 
> I don't understand your reply. We currently use this form of reply:
> 
>      <replycode> ; text ;  more text
>      [<CRLF><application-level-data>]
>      <CRLF>.<CRLF>
> 
> This has no place for transport-level data. It only allows the transport to
> provide a reply code and optional human-readable comment data.
> 
> Below is an example reply from the draft. What is the transport-level data in
> this reply? The first line has the reply code and the text. The <CRLF>.<CRLF>
> is at the end. Everything in between is application-level data.  Is there any
> reply that has transport-level data?

I think we have a misunderstanding at the terminology level.

The "2.0 ; got the request OK" is the 'transport' data. As it
has nothing to do with the application data. It just happens
to be the same as what is in the application data this time?

> S: 2.0 ; got the request OK
> S: Content-type:text/calendar; Method=RESPONSE;
> S:   Optinfo=VERSION:2.1
> S: Content-Transfer-Encoding: 7bit
> S:
> S: BEGIN:VCALENDAR
> S: VERSION:2.1
> S: METHOD:RESPONSE
> S: TARGET:cap://cal.example.com/opaqueid99
> S: CMDID:xyz12345
> S: RESPONSE-STATUS:2.0
> S: BEGIN:VEVENT
> S: DTSTART:19990714T200000Z
> S: DTEND:19990714T210000Z
> S: UID:000444888929922
> S: SUMMARY:Blah bla
> S: END:VEVENT
> S: BEGIN:VEVENT
> S: UID:0034848098038888989443
> S: SUMMARY:meeting
> S: DTEND:19990714T233000Z
> S: DTSTART:19990714T223000Z
> S: END:VEVENT
> S: END:VCALENDAR
> S: .
> 
> 
> -Steve
> 
> Doug Royer wrote:
> 
> > Sure  - SENDDATA
> >
> >         CUA SENDDATA
> >         CUS <MIME-DATA>
> >         CS <TRANSPORT-PROTOCOL-REPLY>
> >         CS <iCAL-MIME-REPLY>
> >         CS ...application data...
> >         CS <CRLF>
> >         CS .
> >         CS <CRLF>

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: [email-masked] (Steve Mansour)
Date: Mon, 02 Aug 1999 17:15:26 -0700

> to be the same as what is in the application data this time?

right.  The reply code is at the transport-level  --but I was not considering that
as transport-level "data".  I was asking if there is a situation where there was
more transport data over and above the "2.0; got the request OK".  An example would
be if we considered the various AUTH types to be transport-level data and MAXDATE
to be application-level data.  When we send back capabilities, both types of data
would come back. It is clear where we put the application-level data. But where
would the transport level data (AUTH) go?  We haven't accounted for it in the
general reply shown above --or at least I'm not clear on how we would do it. We
said that the "text" after the reply code is optional and is meant to be a
human-readable message, so we can't put it there. Maybe we could fold it into the
"more text" area. That's pretty ugly. Here's another option, this is even more
horrible:

      <replycode> ; text ;  more text
      [<transport-level data><some delimiter>]
      [<CRLF><application-level-data>]
      <CRLF>.<CRLF>

I'm hoping we don't have to do either of these things. If the transport-level
"data" consists only of the reply code and the optional text, we're in good shape.
However, if there's more transport-level data to consider, we need to figure out
where to put it.

-Steve