Re: CAP - BEEP Profile
Doug Royer <[email protected]>
| Newsgroups | gmane.ietf.calendar |
|---|---|
| Organization | http://INET-Consulting.com |
| Message-ID | <[email protected]> |
Nathaniel Borenstein wrote:
> I'm not any more of a BEEP expert than I am a CAP expert, but I
> consulted Mr. BEEP himself, Marshall Rose, and got a few comments from
> him that look potentially useful. Most of them are just
> clarifications, although the last one seems to go a bit deeper. --
> Nathaniel
>
> Messages starting one-to-one exchanges:
>
> The initial message each direction MUST BE single "text/calendar"
> object containing a CAP "CAPABILITY" CMD and must not be part
> of a
> MIME multipart message.
>
>
> not a sentence. this would read better if it actually mentioned the term
> "MIME media type".
I don't follow. Do you mean say "MIME media type of text/calendar"?
> After the initial message then a BEEP "MSG" may contain one or
> more
> MIME objects at least one of which MUST be "text/calendar" and
> each
> "text/calendar" MIME object MUST contain a CAP "CMD" property.
>
> The BEEP "MSG" messages can only contain MIME "multipart" MIME
> objects if the other endpoint has received a CAP "CAPABILITY"
> indicating the other endpoint supports multipart MIME objects.
> This
> does not prevent the endpoint from sending multiple
> "text/calendar"
> MIME objects in a single BEEP "MSG" so long as all of the "text/
> calendar" CAP objects have the same "TARGET" property value.
>
>
> eh? how can you send multiple objects in the same MSG if you aren't
> using multipart as the outerwrapper. the spec says that each MSG, RPY,
> etc., contains a MIME object. it doesn't say that the each MSG, RPY,
> etc., contains one or more MIME objects concatenated together...
It (they all) should say [iCAL], as in:
The BEEP "MSG" messages can only contain MIME "multipart" MIME
objects if the other endpoint has received a CAP "CAPABILITY"
indicating the other endpoint supports multipart MIME objects. This
does not prevent the endpoint from sending multiple [iCAL] objects
in a single BEEP "MSG" so long as all of the [iCAL] objects have
the same "TARGET" property value.
> Messages in negative replies:
>
>
> Any valid "text/calendar" MIME object that contains CAP
> "REQUEST-STATUS" property and a CAP "CMD" property with a
> property
> value of "REPLY". And where the CS has determined the requested
> operation to be a fatal error. And when the CS has performed NO
> operation that effected the contents of any part of the CS or any
> calendar controlled by the CS.
>
>
> this is very hard to understand and could be clarified.
Anyone have suggestions?
>
> Messages in one-to-many exchanges:
>
> After the initial message then a BEEP "MSG" may contain one or
> more
> MIME objects at least one of which MUST be "text/calendar" and
> each
> "text/calendar" MIME object MUST contain a CAP "CMD" property.
>
> The BEEP "MSG" messages can only contain MIME "multipart" MIME
> objects if the other endpoint has received a CAP "CAPABILITY"
> indicating the other endpoint supports multipart MIME objects.
> This
> does not prevent the endpoint from sending multiple
> "text/calendar"
> MIME objects in a single BEEP "MSG" so long as all of the "text/
> calendar" CAP objects have the same "TARGET" property value.
>
> The BEEP "RPY" messages can only contain MIME "multipart" MIME
> objects if the other endpoint has received a CAP "CAPABILITY"
> indicating the other endpoint supports multipart MIME objects.
> This
> does not prevent the endpoint from sending multiple
> "text/calendar"
> MIME objects in a single BEEP "ANS" so long as all of the "text/
> calendar" CAP objects in EACH BEEP "ANS" message have the same
> "TARGET" property value. Each unique "TARGET" property value per
> BEEP
> "ANS" message.
>
>
> this is so wrong, i don't know where to start. i guess that the idea
> is this:
>
> 1. a BEEP message (the contents of a MSG, a RPY, an ANS, or an ERR)
> must contain one or more text/calendar objects, each of which having the
> same TARGET property.
>
> 2. if the TARGET properties contained in the response are identical,
> then a one-to-many exchange should occur, and each ANS should contain
> one or more text/calendar objects, all having the same TARGET
> property.
No, the WG wanted the the opposite. If they are different TARGETs then they
go in to multiple ANS messages. (not something I wanted so I do not
understand why).
>
> 3. if the TARGET properties contained in the response are identical,
> then a one-to-one exchange should occur, and that RPY should contain
> one or more text/calendar entries.
No and this sounds the same as (2) to me. And they can be combined only
when they are the same TARGET.
There are two ways to combine.
If the recipient does not support multipart and all of the replies are
for the same TARGET, they still can send one [iCAL] object with
multiple replies (BEGIN/END VCALENDAR blobs) in the ONE RPY.
>
> the bug here is that to do the "or more" part of "one or more", you must
> use a multipart, because each BEEP message contains either zero or one
> MIME objects.
Not all CUA's support multipart. So no that will not work.
>
> my guess is that these rules could be written much more concisely and
> unambiguously once the multipart thing is resolved (e.g., if a response
> requires a multipart and the CS doesn't support multipart, then the CS
> returns an ERR response).
(1) Not all CUAs or CSs support multipart.
(2) The WG wanted all "text/calendar" objects in the same reply to be be
of the
same TARGET.
(3) For those CUAs and CSs that do support multipart they can also have
non-text/calendar
objects (attached for example).
>
> /mtr
>
--
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
[email protected] | Office: (208)612-INET
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044
We Do Standards - You Need Standards