Subject: Re: CAP -12 and LAST CALL (hopefully)

From: [email-masked]
Date: Mon, 11 Aug 2003 15:47:01 -0400

Doug:
1.  The chairs make the Last Call statement - not the editors.
2.  I think there are a lot more issues on the list that are not addressed
in what you have put in CAP 12.
3.  Saying that no one responding to a comment by Bruce stops the issue is
the chairs call, not the editors.
4.  I am not comfortable that CAP is ready for last call - I think a lot of
issues were raised that are still outstandingl

I know that sounds a bit harsh - but, I've seen a lot of activity but not a
lot of clear decisions.  If the list agrees that Doug's draft is ok as is,
then I'll say last call  But I don't think it's ready.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

                      Doug Royer                                                                                                           
                      <[email-masked]>             To:       "[email-masked]" <[email-masked]>                               
                      Sent by:                     cc:                                                                                     
                      owner-ietf-calendar@m        Subject:  CAP -12 and LAST CALL (hopefully)                                             
                      ail.imc.org                                                                                                          

                      08/11/2003 03:34 PM                                                                                                  
                      Please respond to                                                                                                    
                      "[email-masked]                                                                                                
                      g"                                                                                                                   

With the addition to the typo's that people have filed using bugzilla
and the ones on this list it looks as if CAP is almost ready
to release.

The only non-typo issue seems to be the BEEP profile. Bruce
has declared twice that it has not been discusses and proposed
no solution. So that responce is a dead end. If anyone
(including Bruce) has a proposal or objection to the BEEP
profile below - please speak up.

There has been a discussion on the 1:1 and 1:many replies
and the first time I sent the BEEP proposal below (apx JUL-7)
there have been no responces. I do not really have any choice
but to assume it is acceptable.

I'll fix the typos submitted, add the BEEP profile below.
This weekend (if I have time) I'll submit -12 and hopefully
it will be the last WG call. There have been posts asking
for issues, so obviously those asking for the issues do
not have any at this time.

Proposed Beep profile:

As there have been no replies to my comments to the BEEP profile
and after re-reading the WG archives, I will put the following
into -12 (still not too late to comment on my proposal).

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: specify the datatypes that
       may be 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: specify the datatypes that
       may be present when an exchange starts.

         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 at least one "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: specify the datatypes that may be
       present in a positive reply.

         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 at least one "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" 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: specify the datatypes that may be
       present in a negative reply.

         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: specify the datatypes that may be
       present in a one-to-many exchange.

         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 at least one "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: specify the syntax of the datatypes exchanged by the
       profile.

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

    Message Semantics: specify the semantics of the datatypes exchanged
       by the profile.

         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: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 14:34:47 -0600

> 1.  The chairs make the Last Call statement - not the editors.

Good thing I put 'hopefully' on the subject line :-)

> in what you have put in CAP 12.

Such as?

> the chairs call, not the editors.

I did not say no one responded to Bruce (and I did and I was
the only one that did), I said:

    Bruce has declared twice that it has not been discusses
    and proposed no solution.

> issues were raised that are still outstanding.

Such as?

> then I'll say last call  But I don't think it's ready.

There has been a lot of 'iCal-version-next'. And for CAP
a lot of questions and answers, and updated text to clarify,
but there have not been any 'I think that is broke' or like
emails on CAP for a while.

The VFREEBUSY text is in -11 and there have been NO counter
proposals.

--