CAP - BEEP Profile

Doug Royer <[email protected]>
Newsgroups gmane.ietf.calendar
Organization http://INET-Consulting.com
Message-ID <[email protected]>
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 protected]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards
smime.p7s (application/x-pkcs7-signature, 4.6 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.