Re: CAP - BEEP Profile

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 protected]>
Date: Thu Sep 11, 2003  6:02:10  PM America/Detroit
To: Nathaniel Borenstein <[email protected]>
Subject: Re: Fwd: CAP - BEEP Profile

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

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>

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

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.


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

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


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


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

cf., comment on multipart above.

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

duplicate paragraph.


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

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

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