Subject: (#2) Byte reduction in BEEP commands.

From: Doug Royer <[email-masked]>
Date: Mon, 11 Feb 2002 18:02:03 -0700

When NOT synching calendars, the command byte overhead used
in draft 06 exceeds the size of the data.

If we switch to CDATA and eliminate what I will call a couple
of "wrapper tag"s, the byte count goes way down.

Just as an example, I'll use "3.3 Bounded Latency", followed
by brief examples of the other commands.

Put the METHOD, TARGET, and optional CMDID back into
the data. (Assume they are in these brief examples).

Change the command in the existing example:

FROM:

C: Content-Type: multipart/related; boundary="boundary-zxy123";
C:    start="[email-masked]";
C:    type="application/beep+xml"
C:
C: --boundary-zxy123
C: Content-Type: application/beep+xml
C: Content-ID: [email-masked]
C:
C: <search id="xyz12346">
C:   <max-time latency=3 action=ask/>
C:   <select>
C:     <source relcalid='opaqueid101'/>
C:     <data content="cid:[email-masked]"/>
C:   </select>
C: </search>
C: --boundary-zxy123
C: Content-Type: text/calendar
C: Content-ID: [email-masked]
C:
C: BEGIN:VCALENDAR
C: BEGIN:VQUERY
C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT
C:   WHERE DTEND >= '19990714T080000Z' AND
C:   DTSTART <= '19990715T080000Z'
C: END:VQUERY
C: END:VCALENDAR

TO:

C:Content-Type: application/...beep...
C:
C: <search latency="3" action="ask">
C: <![CDATA[
C: BEGIN:VCALENDAR
C: CMDID:unique-id
C: TARGET:opaqueid101
C: METHOD:SEARCH
C: ...
C: BEGIN:VQUERY
C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID FROM VEVENT
C:  WHERE DTEND >= '19990714T080000' AND
C:  DTSTART <= '19990715T080000'
C: END:VQUERY
C: END:VCALENDAR
C: ]]></search>

S: <reply>
C: <![CDATA[
S: ...iCalendar REQUEST-STATUS line(s)...
S: </reply>
C: ]]></search>

-----------------------------------------------------------
[ Assume all of the following examples have the MIME and
  BEEP MIME headers...]

[ And assume that when the server reply is not listed,
  it is like the above example]

-----------------------------------------------------------

6.1.1 "generate-uid" Command

[remove the <uidlist> and </uidlist> tags> in the reply.

TO:

C: <generatuid num="5"/>

S: <uidlist>
S: <uid><uid>[email-masked]</uid>
S: <uid>[email-masked]</uid>
S: <uid>[email-masked]</uid>
S: </uidlist>

--------------------------------------------------------------

And I changed the names to MATCH (case) the iCalendar objects.
As iCalendar objects are upper case, the same named objects
should be here. And I upper cased the new ones in CAP to
be consistent with iCalendar. And I changed the names
of the CAPABILITY replies to be the same as the PROPERTY
names they map to (same case).

There is a typo in 06 on the name of date max and date min.

6.1.2 "capability" Command

C: <capability/>

S:<capability>
S:<version>1.0</version>
S:<prodid>bla bla bla</prodid>
S:<query-level>...</query-level>
S:<car>CAR-FULL-1</car>
S:<date-min>00000101T000000Z</date-min>
S:<date-max>99991231T235959Z</date-max>
S:<max-component-size>0</max-component-size>
S:<itip-version>1.0</itip-version>
S:</capability>

-----------------------------------------------------------------
6.1.3 "identify" Command

There was NO example for IDENTIFY, so I propose:

C: <identify newupn="user2@realm"/>

S: ...empty BEEP RPY is success...
S: ...else CAP error message in BEEP CDATA reply...

-----------------------------------------------------------------
6.1.4 "noop" Command

C: <noop/>

[ As there is nothing to fail, an empty BEEP reply]

-------------------------------------------------------------------

6.2.4.1 "create" Command

C: <create>
C: <![CDATA[
C: BEGIN:VCALENDAR
C: CMDID:unique-id
C: TARGET:opaqueid101
C: METHOD:REFRESH		# Your can CREATE any kind of METHOD
C: ...
C: END:VCALENDAR
C: ]]></search>

-------------------------------------------------------------------

6.2.4.2 "delete" Command

C: <delete>
C: <![CDATA[
C: BEGIN:VCALENDAR
C: CMDID:unique-id
C: TARGET:opaqueid101
C: METHOD:DELETE
C: ...
C: BEGIN:VQUERY
C: ...selection criteria...
C: END:VQUERY
C: END:VCALENDAR
C: ]]></delete>

-------------------------------------------------------------------

Plus change the MODIFY iCalendar objects back to the way
they were in the 05 draft.

C: <modify>
C: <![CDATA[
C: BEGIN:VCALENDAR
C: CMDID:unique-id
C: TARGET:opaqueid101
C: METHOD:DELETE
C: ...
C: BEGIN:VQUERY
C: ...selection criteria...
C: END:VQUERY
C: BEGIN:VCALENDAR
C: ...old was data...
C: END:VCALENDAR
C: BEGIN:VCALENDAR
C: ...new going to be data...
C: END:VCALENDAR
C: END:VCALENDAR
C: ]]></modify>

-------------------------------------------------------------------
6.2.4.4 "move" Command
[MOVE OF CALENDAR HAD BEEN DELETED]

-------------------------------------------------------------------

6.2.4.5 "search" Command

C: <search/>
C: <![CDATA[
C: BEGIN:VCALENDAR
C: CMDID:unique-id
C: TARGET:opaqueid101
C: METHOD:SEARCH
C: ...
C: BEGIN:VQUERY
C: ...selection criteria...
C: END:VQUERY
C: END:VCALENDAR
C: ]]></search>

[ The REPLY contains REPLY-STATUS on failure, or the data 
  in CDATA format]

-------------------------------------------------------------------

Drop this section entirely. As the METHOD is now back in
the iCalendar objects, just deposit them with the <create/> command
into the CS.

6.3 Scheduling Commands
6.3.1 "schedule" Command
6.3.2 Processing Scheduling Components

	A CUA processes iTIP data, the CS just stores them.

	Change to description on how the CUA
	performs VQUERY to get the data that has been
	deposited.

	Drop the <schedule/> command.

-------------------------------------------------------------------

---

From: Patrice Lapierre <[email-masked]>
Date: 12 Feb 2002 10:06:56 -0500

On Mon, 2002-02-11 at 20:02, Doug Royer wrote:
...
> the data. (Assume they are in these brief examples).

As mentioned in:

  http://www.imc.org/ietf-calendar/mail-archive/msg03701.html

CMDID is used by other commands that do not include an iCalendar 
object.  

 I don't understand, your example is in lower case. Furthermore 
as mentioned by John iCalender in case insensitive.
 
see:
 http://www.imc.org/ietf-calendar/mail-archive/msg03749.html

> S:<itip-version>1.0</itip-version>

As mentioned in:

 http://www.imc.org/ietf-calendar/mail-archive/msg03704.html

  I find the empty RPY very awkward. If you send a command in
XML you should receive a response in XML. It's consistent and
easy to document in the BEEP registration template (all entries
refers to the DTD).

  I don't understand, what is the purpose of a METHOD:DELETE
in a modify command?

  That's not exactly true. When storing an iTIP object, the CS do 
perform some processing on the iTIP object. 

e.g,., The following iTIP object:
      
BEGIN:VCALENDAR
METHOD:REQUEST
BEGIN:VEVENT
...
END:VEVENT
END:VCALENDAR

is stored as:

BEGIN:VEVENT
METHOD:REQUEST
...
END:VEVENT

As such the schedule command is not identical to the create command.

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 09:27:32 -0700

> CMDID is used by other commands that do not include an iCalendar

There was also replies that indicated that the BEEP MSGNO
field served the same purpose. So I thought that meant
that people were okay with taking it out of the command.

I'll add text like:

  If the CUA wishes to perform more than one simultaneous
  command to the CS, then the 'cmdid' attribute must be
  added to any commands in order for the CUA and the CS
  to uniquely identify which command is being referred to
  in the abort and continue commands.

Plus I did forget some of the email, so I will also add:

  If it is supplied at all, it MUST be in the iCalendar
  object and also supplied in the command as an attribute.

(then I'll show what I mean in an example)

I'll also add text like:

  If a CUA wishes to abort a command in progress, the CUA
  MUST issue the <abort> command on a separate channel with
  the cmdid attribute set to the CMDID of the command to
  be aborted.

   (plus add BEEP example).

> as mentioned by John iCalender in case insensitive.

Yes - that was an old comment that and I missed removing it
from (#2). Thanks - I'll remove that comment.

> > There is a typo in 06 on the name of date max and date min.

I don't see it - where?

> easy to document in the BEEP registration template (all entries

If you re-read BEEP you will see that it allows for empty
replies to mean success. If your logic is correct, then
a BEEP reply could never be empty - clearly not what they
intended.

>   I don't understand, what is the purpose of a METHOD:DELETE

Typo, it should have been METHOD:MODIFY

> perform some processing on the iTIP object.

NO - only CUA process iTIP objects

> As such the schedule command is not identical to the create command.

The same is true for the <create> command. The METHOD is put
into the object - no difference at all.

---

From: Patrice Lapierre <[email-masked]>
Date: 12 Feb 2002 13:27:54 -0500

...
> that people were okay with taking it out of the command.

  The MSGNO doesn't serve the same purpose. It's it used to 
map the response(s) (RPY, ERR, ANS, NULL) with the request 
(MSG). 

  The id (or cmdid) provides an identifier to allow a CUA 
to abort a command (possibly from a different channel
as we already discussed).

>   in the abort and continue commands.

  I don't think that cmdid needs be a MUST when several 
commands are executed.

If not provided then we have the following problems:

  (1) The CUA cannot "abort" the command (by sending a
      message from another BEEP channel).

  (2) The CUA can't unambiguously determine which command
      is referred by a "timeout" message.

  The first doesn't mater, if the CUA wants to be able to 
cancel a command, it just have to provide an id.

  For the second, I would also leave it up the the CUA, 
since it doesn't impact the server. But if others see this 
as a problem, then we could simply add the restriction that
id MUST be provided iff action='ask'.

>   object and also supplied in the command as an attribute.

  Since mapping between commands and the associated responces 
is no longer handled by the cmdid, is there a real need to place 
it in the iCalendar object as well?

>   the cmdid attribute set to the CMDID of the command to

I agree.

> > > There is a typo in 06 on the name of date max and date min.

  If you referring to the typo, then don't ask me, you are the 
one who mentioned it in you original post.

> a BEEP reply could never be empty - clearly not what they
 
  Please! Just because we can do it, doesn't mean that 
we should.

  If it's such a good practice, then can you give me an example 
of a BEEP profile that returns an empty RPY to indicate success.

  Also in BEEP if the payload doesn't include a mime header 
the default content-type is "application/octect-stream".
Do we really want to introduce another content-type in CAP?

--
Patrice.

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 13:46:40 -0700

> of a BEEP profile that returns an empty RPY to indicate success.

Can you show me where in BEEP it defines it is bad practice?

> Do we really want to introduce another content-type in CAP?

If payload lenght == 0 -> success.
I can do that and never care what the content-type is.
It works for XML and non-XML content types.

---

From: Patrice Lapierre <[email-masked]>
Date: 12 Feb 2002 16:44:07 -0500

...
> It works for XML and non-XML content types.

  Not for XML content-types, since XML document (or data) must 
have a single root.

---

From: Marshall Rose <[email-masked]>
Date: Tue, 12 Feb 2002 14:43:42 -0800

> It works for XML and non-XML content types.

would someone be kind enough to post a succinct message illuminating the issues on this?

one can certainly send an empty RPY and have it mean something in the context of a given profile. i'm just trying to understand the motivation for doing so...

/mtr

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 15:58:43 -0700

>   Not for XML content-types, since XML document (or data) must

If the BEEP payload is ZERO length, then it does not matter
what the MSG content type was, the result is succeess.

---

From: Patrice Lapierre <[email-masked]>
Date: 12 Feb 2002 18:15:22 -0500

On Tue, 2002-02-12 at 17:43, Marshall Rose wrote:
> would someone be kind enough to post a succinct message illuminating >
the issues on this?
> 
> one can certainly send an empty RPY and have it mean something in the
context of a given profile. i'm just trying to understand the motivation
for doing so...
> /mtr

  Doug suggested sending a RPY with an empty payload for a successful 
response instead of:

   <result>
      <request-status code="2.0"/>
   </result>

The sole motivation was to reduce the number of bytes.

   For consistency, I would prefer always sending an XML response 
to a XML command (I'm not arguing that empty payload are invalid). 

--
Patrice.

---

From: Marshall Rose <[email-masked]>
Date: Tue, 12 Feb 2002 15:55:29 -0800

> to a XML command (I'm not arguing that empty payload are invalid). 

from the beep-perspective, you can pretty much define whatever rules that make sense in the context of the profile in question.

if folks are comfortable, that this isn't going to turn into one of those "obvious optimizations that end up causing problems down the road", then an empty RPY doesn't violate any rules.

in other beep profiles, typically "<ok/>" is used to indicate generic success and <error code='...'> ... </error> is used to differentiate failure.

this is pretty much the same, though slightly less verbose, than what calsch is doing, although i can't get too worked-up over the issue myself. 

certainly in the "<ok/>" case, many more octets are wasted on the content-type than anything else. the reason is that the beep wg decided (after a nice pitch from joe touch) that it was better to explicilty tag the content-type for the purpose of sniffers, etc.

/mtr

---

From: Doug Royer <[email-masked]>
Date: Tue, 12 Feb 2002 17:55:35 -0700

Marshall Rose wrote:
ks for XML and non-XML content types.
> context of a given profile. i'm just trying to understand the
> motivation for doing so...

It is in the context of reducing the byte count in the CAP
protocol for replies that have no data other than to
say success.

I just don't see the need to add a message that says if you got
me you must read me to know that there are not any problems.
When "if payload.length == 0" will work.

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Feb 2002 13:34:25 -0700

>       is referred by a "timeout" message.

Your right, how about:

   If the CUA wishes to perform more than one simultaneous
   command to the CS, then the 'cmdid' attribute MUST BE
   added to any commands if the CUA wishes to be able to
   abort any command in process. This has to be done in order
   for the CUA and the CS to uniquely identify which command
   is being referred to in the abort and continue commands.
   If no 'cmdid' attribute is supplied by the CUA in the command,
   then the CUA will not be able to abort a command.

> id MUST be provided iff action='ask'.

But only if multiple commands are in progress, because the continue
and about are issued on the same channel - agree?

> it in the iCalendar object as well?

I would rephrase that to say that there was never any consensus
to remove it from the object so that it can be uniquely defined
in a iCalendar object as define by cap requirement - old debate.
I think we compromised and said that it must be in both, I would
like to see it only in the object.

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Feb 2002 08:30:24 -0500

>    then the CUA will not be able to abort a command.

There are many ways a command can be aborted:

 (1) CUA sends an "abort" message at any moment from
     another channel.

 (2) CUA sends an "abort" RPY to a "timeout" MSG
     (when max lantency is exhausted).

 (3) Max latency is reached and action='abort'

For (2), I agree.
For (3), cmdid is not an issue, but your text seems correct
since we can say that it's not the CUA that aborts the 
commmand.
    
 For (1), I think that the cmdid must always be present, 
even if only a single command is present. The motivation 
is that there might be delay before the CS processes the 
"abort" command. Without the "cmdid" the server will not 
be able to unambiguously determine which command to cancel
(even if there is only one it could have been sent after 
the "abort").

> and about are issued on the same channel - agree?

Yes.

> like to see it only in the object.

Ok, good compromise.

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Feb 2002 09:09:03 -0700

> (even if there is only one it could have been sent after

In (1) the CUA is doing more than one command at a time.
So yes when the CUA sends more than one command at a time
and it may wish to cancel the command, it MUST supply CMDID.

But if the CUA is NEVER going to send more than one command
and is not using latency, then it NEVER is needed.

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Feb 2002 12:30:22 -0500

> and is not using latency, then it NEVER is needed.

Yes, I agree.