Subject: Byte reduction in BEEP commands.

From: Doug Royer <[email-masked]>
Date: Mon, 28 Jan 2002 16:51:20 -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.

(And I thought that XML  (or XSL, XSLT...) reserved the 'id' tag)

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

I also propose changing the REPLY from the CS to be an EMPTY
BEEP reply for success. Eliminating the the not needed 2.0
success code. If the BEEP reply contains any data, then
parse that iCalendar data.

THIS IS JUST A PROPOSAL FOR THE *IDEA*, PLEASE DO NOT PICK APART
ALL OF THE SYNTAX. IF THERE ARE NO SERIOUS PROBLEMS, I'LL SPEND
TIME TO MAKE A FULL PROPOSAL! - Thanks!

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: 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: ]]>

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

6.1.1 "generate-uid" Command

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

TO:

C: <generatuid num="5"/>

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

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

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 "get-capability" Command

C: <capability/>

S:<VERSION>1.0</VERSION>
S:<PROIDID>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>

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

There was NO example for IDENTIFY, so I propose:

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

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

6.1.4 "noop" Command

C: <noop/>

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

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

6.2.4.1 "create" Command

C: <create/>

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

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

6.2.4.2 "delete" Command

C: <delete/>

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

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

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

C: <modify>

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

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

6.2.4.4 "move" Command

C: <move oldcalid="oldid" newcalid="newid"/>

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

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

6.2.4.5 "search" Command

C: <search/>

S: ... the reply data in BEEP CDATA...

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

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: Thu, 31 Jan 2002 08:31:34 -0500

> Doug Royer wrote:
...
> (And I thought that XML  (or XSL, XSLT...) reserved the 'id' tag)

  It's not reserved in XML (and other BEEP profiles use it), 
but I have no objection to naming it cmdid, even if it takes 3
more bytes :-).

> ...

  CMDID is also used by the <abort>, <continue> and <timeout> 
messages, that don't use iCalendar objects. Therefore the id 
seems to belong in the command section (the link between the 
request and the associated reply is now handled by beep).

-- 
Patrice.

---

From: Patrice Lapierre <[email-masked]>
Date: Thu, 31 Jan 2002 08:35:23 -0500

...
> parse that iCalendar data.

  That would be awkward. I would tend to keep something in the
payload (even if it's just <ok/>).  

  Draft-06 uses a distinct ANS for each target in the command.
And part of the payload was to indicate to which target the
reply correspond. If there is a need to minimize the byte count, 
then it may make sense to allow a single ANS (or RPY) to refer to
many targets with identical replies (e.g. success). But I would 
not remove the target(s) from the reply.

> S: ...empty BEEP RPY is success...

  This is slightly off topic, but for the delete, move and modify 
commands it would probably be useful to always return the number of 
selected components.

--
Patrice.

---

From: Patrice Lapierre <[email-masked]>
Date: Thu, 31 Jan 2002 08:44:58 -0500

...
...
> C:  DTSTART <= '19990715T080000'

 XML document MUST have a single root.

 And placing the iCalendar object directly in the search, 
would limit future extension to the addition of attributes 
in the search element.

 I think that an additional element is needed to allow extension
(e.g. <data> element in draft-06)

   C: <search>
   C: <!--  ROOM to add XML elementa in future version of CAP. ->
   C:   <data content='#Content'>
   C: <![CDATA[
    
   # iCalendar object goes here 
   
   C: ]]>
   C:   </data>
   C: </search>

  Such a construct also removes duplication in the XML DTD (each 
command that uses iCalendar simply refer to the "data" element).

Note: the <data> element was inspired from the apex profile which
      allows both embedded document (content='#Content') or
      reference to a mime section (content='cid:...'). I think that
      it would be a good idea to support both styles in CAP.

I would also keep the construct:

   <max-time latency='3' action='ask'/>
   
  But if it's decided otherwise, then "action" should be 
renamed to something less generic (e.g., timeout-action).
 
> S: <uid>[email-masked]</uid>

  Again XML document must have a single root. 

  And it's a good practice to group list elements in a 
container (e.g. in HTML <li> are inside <ol> or <ul>).
  
  Furthermore it may be relevent to add some information
that relates to the entire list.  
  
e.g.,

   C: <generateuid num=100000000000/>  

   S: <uidlist num=100>       <!-- Server side quota -->
   S:    <uid>[email-masked]</uid>
   S: <!-- 99 other uids -->
   S: </uidlist>

--
Patrice.

---

From: Patrice Lapierre <[email-masked]>
Date: Thu, 31 Jan 2002 08:46:59 -0500

...
> S:<ITIP-VERSION>1.0</iTIP-VERSION>

  It's a matter of taste. But we loose grouping of related elements 
and the cases are inconsistent with other XML construct in the same 
DTD. 

--
Patrice.

---

From: Gary Frederick <[email-masked]>
Date: Thu, 31 Jan 2002 08:16:33 -0600

I agree.

There was conversation a while ago about the XML version of iCalendar 
(xcs) and the consensus was that the tags be lowercase (mostly - with 
<iCalendar> an exception). I like the idea that the various related 
standards have the same XML tag names.

Gary

---

From: Doug Royer <[email-masked]>
Date: Thu, 31 Jan 2002 09:49:18 -0700

> not remove the target(s) from the reply.

CMDID used to be optional and only needed when you did 
pipelineing. I don't see any need for CMDID when there is
only one command issued at a time.  When the CUA issues
more than one command without waiting for all of replies
to outstanding commands, then CMDID is needed.

Do you agree?

---

From: Doug Royer <[email-masked]>
Date: Thu, 31 Jan 2002 09:49:48 -0700

> commands it would probably be useful to always return the number of

Why? What are you going to do with '23'?

---

From: Doug Royer <[email-masked]>
Date: Thu, 31 Jan 2002 10:02:21 -0700

>   Again XML document must have a single root.

Don't confuse an XML document with XML data.

XML data most definatly can just be tags.

> container (e.g. in HTML <li> are inside <ol> or <ul>).

That is a matter for debate.

> that relates to the entire list.

But until then - I really don't care. We can add stuff
later - and it is XML - so it will be easy to add it
WHEN there is a proposal. Just adding it because "it's nice",
is not a valid argument.

---

From: Doug Royer <[email-masked]>
Date: Thu, 31 Jan 2002 10:04:00 -0700

> and the cases are inconsistent with other XML construct in the same

We DID NOT HAVE THAT IN 05, that was added without debate
or discussion. Back to what was agreed to in 05.

And XML is secondary. The DATA is important. Reducing the
byte count is important.

---

From: Gary Frederick <[email-masked]>
Date: Thu, 31 Jan 2002 11:55:19 -0600

Don't confuse XML data with data that looks like XML because it uses tags.
XML data can only have a single root.

regarding the debate about grouping elements in a container,

6.1.1 states it returns a list and the example shows the list is inside 
a <uid-list> tag. That looks like what Patrice suggested. Is that to be 
changed?

Gary

http://calsch.org/ietf/draft-ietf-calsch-cap-06.html#generate-uid
6.1.1 "generate-uid" Command

Attributes:

num: Number of UIDs to generate (1 if omitted).

Response:

"uid-list"

The "generate-uid" command returns one or more unique identifiers which 
MUST be unique on the server's calendar store. It is recommended that 
the return values be globally unique ids.

Example:

C: MSG 1 5 . 2837 60
C: Content-Type: application/beep+xml
C:
C: <generateuid num=5/>
C: END
S: RPY 1 5 . 2897 328
S: Content-Type: application/beep+xml
S:
S: <uid-list>
S:   <uid>[email-masked]</uid>
S:   <uid>[email-masked]</uid>
S:   <uid>[email-masked]</uid>
S:   <uid>[email-masked]</uid>
S:   <uid>[email-masked]</uid>
S: </uid-list>
S: END

---

From: Patrice Lapierre <[email-masked]>
Date: Thu, 31 Jan 2002 13:11:31 -0500

Doug Royer wrote:
...
> to outstanding commands, then CMDID is needed.

  Yes I agree that it should be optional. And it is optional in 
the DTD of draft-06.

  Furthermore since pipelining is handled by BEEP, the CMDID is 
not necessarily needed for matching replies even if there is more
than one outstanding commands.

---

From: Patrice Lapierre <[email-masked]>
Date: Thu, 31 Jan 2002 14:00:12 -0500

Doug Royer wrote:
>   If the VQUERY inside these command doesn't match any

  It's up the to the CUA, it could for example update a counter 
displayed next to name of the VAGENDA in a tree view. 

  If a the VQUERY inside one of these commands doesn't match 
any components, it's not considered an error. Therefore if CUA performs
"move" of a single VEVENT (query on the UID). If the count is not 
returned, the CUA doesn't know that the component was indeed moved 
(a command from another session could have deleted the VEVENT 
just before the execution of the "move").

---

From: Doug Royer <[email-masked]>
Date: Thu, 31 Jan 2002 15:36:32 -0700

> returned, the CUA doesn't know that the component was indeed moved

Sure it does, if there is an error your get an error.
If there is no error and it is not done, your implementation is busted.

> just before the execution of the "move").

In which case you would get a 'no such event' error. And
not a success code (Or empty as I proposed).

And adding a RETURN COUNTER is a new thing - and we all
need to keep each other from inventing new things at this
point in time.

---

From: Doug Royer <[email-masked]>
Date: Thu, 31 Jan 2002 16:19:24 -0700

> would limit future extension to the addition of attributes

NO - its XML, we just add - IF we ever  choose to add.

>    # iCalendar object goes here

I still don't think that <data>stuff</data> is needed. We
can add it later if needed -  its XML.

> command that uses iCalendar simply refer to the "data" element).

It's just text, do we really want to add to the byte overhead
of the CAP protocol just so that the draft has less text in it?

>       it would be a good idea to support both styles in CAP.

I am glad they needed it. I don't see that we need it.
BEEP already supports Content-Type. I for one am going to
have a X-RAW-ITIP capability that just takes iTIP messages
directly - there really is NO need for an XML wrapper for those anyway.
Adding another layer because someone else needed it for another
application is not a valid justification.

And as you have pointed out it is XML, so we can add whatever
we need later. No need to add <data> now, especally when you
agree is exists only for some future unspecified and un-debated
things.