Subject: CAP - BEEP Profile

From: Doug Royer <[email-masked]>
Date: Wed, 10 Sep 2003 17:09:59 -0600

Looking through the latest CAP I noticed that I had forgot to include
the BEEP profile information that I posted on 07-July-2003.

This (unless there are objections) will be in the next release of CAP.
This will be the contents of section 12.1:

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

12.1 BEEP Profile Registration

    Beep replies will be one to one (1:1 MSG/RPY) if possible and one to
    many (1:many MSG/ANS) when the TARGET changes.

    Profile Identification: specify a URI [10] that authoritatively
    identifies this profile.

    http://iana.org/beep/cap/1.0

    Message Exchanged during Channel Creation:

    CUAs SHOULD supply the BEEP "localize" attributes in the BEEP
    "greeting" messages.

    CSs SHOULD supply the BEEP "localize" attributes in the BEEP
    "greeting" messages.

    CUAs SHOULD supply the BEEP "serverName" attribute at channel
    creation time to the CS so that if the CS is performing virtual
    hosting the CS can determine the intended virtual host. CSs that do
    not support virtual hosting may ignore the BEEP "serverName"
    attribute.

    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.

    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.

    Messages in positive replies:

    After the initial message then a BEEP "RPY" 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. All
    "text/calendar" MIME objects in a single BEEP "RPY" messages MUST
    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"

    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 "RPY" so long as all of the "text/
    calendar" CAP objects have the same "TARGET" property value.
    MIME objects in a single BEEP "RPY" so long as all of the "text/
    calendar" CAP 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.

    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.

    Message Syntax:

    They are CAP "text/calendar" MIME objects as specified in this memo.

    Message Semantics:

    As defined in this memo.

-------------------------------------------------------------------------
--
  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sun, 14 Sep 2003 18:17:12 -0400

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

From: Marshall Rose <[email-masked]>
Date: Thu Sep 11, 2003  6:02:10  PM America/Detroit
To: Nathaniel Borenstein <[email-masked]>
Subject: Re: Fwd: CAP - BEEP Profile

>>    CSs SHOULD supply the BEEP "localize" attributes in the BEEP

well, okay. the spec says:

     <t>the "localize" attribute,
     if present,
     contains one or more language tokens (defined in <xref 
target="RFC3066" />),
     each identifying a desirable language tag to be used by the remote
     BEEP peer when generating textual diagnostics for the "close" and
     "error" elements
     (the tokens are ordered from most to least desirable); and,</t>

>>    not support virtual hosting may ignore the BEEP "serverName"

well, okay. the spec says:

     <t>The "serverName" attribute for the first successful "start" 
element
     received by a BEEP peer is meaningful for the duration of the BEEP
     session.
     If present,
     the BEEP peer decides whether to operate as the indicated 
"serverName";
     if not,
     an "error" element is sent in a negative reply.</t>

so i guess that using "may" is ok, though perhaps "MAY" is more
appropriate.

in otherwords, you can lose the text about localize and serverName and
wouldn't lose anything, since this is just saying what the spec says,
albeit less precisely.

>>    object containing a CAP "CAPABILITY" CMD and must not be part of a

not a sentence. this would read better if it actually mentioned the term
"MIME media type".

actually, a state diagram of the messages exchanged might actually
explain what's trying to be conveyed.

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

>>    have the same "TARGET" property value.

cf., comment on multipart above.

>>    calendar" CAP objects have the same "TARGET" property value.

duplicate paragraph.

>>    calendar controlled by the CS.

this is very hard to understand and could be clarified.

>>    "TARGET" property value. Each unique "TARGET" property value per

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.

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.

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.

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 multiparts, then the CS
returns an ERR response).

/mtr

---

From: Doug Royer <[email-masked]>
Date: Mon, 15 Sep 2003 12:15:57 -0600

> not a sentence. this would read better if it actually mentioned the term

I don't follow. Do you mean say "MIME media type of text/calendar"?

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

> this is very hard to understand and could be clarified.

Anyone have suggestions?

> this is so wrong, i don't know where to start. i guess that the idea 
> is this:
>
> must contain one or more text/calendar objects, each of which 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).

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

> use a multipart, because each BEEP message contains either zero or one

Not all CUA's support multipart. So no that will not work.

> requires a multipart and the CS doesn't support multipart, then the CS

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

--

---

From: Marshall Rose <[email-masked]>
Date: Mon, 15 Sep 2003 13:20:48 -0700

> Not all CUA's support multipart. So no that will not work.
    
sorry, those are BEEP's rules. so, either you make support of multipart
mandatory, or you do not allow requests that would require a multipart
response if multipart isn't available.

/mtr

---

From: Doug Royer <[email-masked]>
Date: Mon, 15 Sep 2003 14:31:25 -0600

>response if multipart isn't available.
Not sure how that differs from what was said.

If the capability of the endpoint does not include multipart, then you can
not send multipart to that recipient. I think we agree.

I can add text that says if you get a multipart and you said "no 
multipart", then
you get a BEEP error...  Is that what you were saying, add a BEEP error?

-- 

                We Do Standards - You Need Standards.

---

From: Marshall Rose <[email-masked]>
Date: Mon, 15 Sep 2003 13:43:25 -0700

> you get a BEEP error...  Is that what you were saying, add a BEEP error?

no. the problem is that you have text in your draft which
says/implies/whatever that you can put more than one mime objects in a
single MSG/RPY/ANS without using a multipart.
    
that is also against beeps' rules.
    
/mtr

---

From: Doug Royer <[email-masked]>
Date: Mon, 15 Sep 2003 14:57:42 -0600

>that is also against beeps' rules.
Yes I agree - I replied to that saying: 

It (they all) should say [iCAL], as in (fixed text below):

An iCAL object is a BEGIN/END VCALENDAR blob.
And a single (non multipart) iCAL MIME object may contain one or
more BEGIN/END VCALENDAR objects (per RFC 2445).

This WG wanted:

    Those to still be valid as long as they all have the same TARGET.

    When they have different TARGET values, then they have to be in separate
    MIME objects.

    When the recipient does not allow multipart, then they have to be in 
separate
    BEEP ANSs.

Does that fix the issue?

--

---

From: Marshall Rose <[email-masked]>
Date: Mon, 15 Sep 2003 19:32:56 -0700

> Does that fix the issue?

i have no idea. the text in the document is so convoluted it should be
sent to the 9th circuit court.
    
do not put more than one top-level mime object in a MSG/RPY/ANS/ERR. if
multiple mime objects must appear, then the top-level mime object must
be a multipart.
    
/mtr

---

From: Doug Royer <[email-masked]>
Date: Mon, 15 Sep 2003 20:43:25 -0600

>sent to the 9th circuit court.

Does anyone that knows iCAL and CAP understand what the issue is?

--

---

From: John Berthels <[email-masked]>
Date: Tue, 16 Sep 2003 10:05:13 +0100 (BST)

> Does anyone that knows iCAL and CAP understand what the issue is?

If I understand correctly, I think its OK. BEEP appears to require a
single mime entity per message.  This mime entity may or may not be
multipart, no matter.

iCal has the ability to encode multiple objects in two ways:

- one object per mime entity, encoded as multipart

- multiple objects per mime entity, delimited with VBEGIN/VEND in a single
text/calendar part.

Is the following wording any help?

-------------------------
Multiple iCal objects may be sent in a single BEEP message by either
representing them as seperate MIME text/calendar parts contained within a
MIME multipart/mixed part or by simple concatenation within a single
text/calendar [**] part, seperated by a single blank line.

In either case, all iCal objects transmitted together must have the same
TARGET property.

The sending of multipart MIME entities over BEEP is not permitted for CAP
unless the other endpoint has indicated its ability to accept them via the
appropriate CAPABILITY[*].
-------------------------

[* - I don't know which capability is this, it would be good to name it
explicitly]

regards,

jb

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Sep 2003 10:14:34 -0600

John Berthels wrote:

>representing them as separate MIME text/calendar parts contained within a
>text/calendar [**] part, separated by a single blank line.
>
Thanks. Much clearer.

And the 'single blank line' is not in the ABNF of 2445, so no that is 
not valid.

  icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
                      icalbody
                      "END" ":" "VCALENDAR" CRLF)

And both are valid for recipients that allow multipart. That is you 
could send
a multipart object where one or more of the parts contained one or more 
'icalobject's.

--

---

From: John Berthels <[email-masked]>
Date: Tue, 16 Sep 2003 17:51:57 +0100 (BST)

> could send a multipart object where one or more of the parts contained
> one or more 'icalobject's.

That would be because my understanding of iCal and CAP is very limited, so
take the wording with more than a pinch of salt, I'm hoping the list will
correct as necessary.

regards,

jb

---

From: Marshall Rose <[email-masked]>
Date: Tue, 16 Sep 2003 10:13:08 -0700

> Is the following wording any help?

yes! that should work fine. thanks!
    
/mtr

---

From: Doug Royer <[email-masked]>
Date: Tue, 16 Sep 2003 11:24:59 -0600

Great. With a couple of tweaks I'll use John's text in -12-d.

--