Subject: cap-10 sections 3.-6. comments

From: [email-masked]
Date: Sat, 15 Mar 2003 15:31:00 -0800 (PST)

below are some suggested changes to and questions about
sections 3. through 6. of the cap-10 draft.

(same format as my previous msgs).

<PRE>
----------------------------------------
[23;1273]

   CAP uses beep as the transport and authentication protocol.
            ****
[
intended to be rendered as ``BEEP'' or ``[BEEP]''?
]
----------------------------------------
[25;1363]

   GET-CAPABILITY - Query the capabilities the other end point of the
                                          ^ of
      session.  (Section 10.3)
----------------------------------------
[28;1529]

   Access rights are used to grant or deny access to calendars,
   components, properties, and parameters in a CS to a CU.  CAP defines
   a new component type called a Calendar Access Right (VCAR).
   Specifically, a "VCAR" component grants, or denies, UPNs the right to
                                          X          X
   search and write components, properties, and parameters on calendars
                                          X
   within a CS.
[
not certain of the punctionation rules for or- and and-lists,
but I think at least two of those three commas should not be there.
commas in or- and and-lists seems to be inconsistent in general in the draft.
]
----------------------------------------
[29;1587]

   CARID:REQUESTONLY -  Specifies the "GRANT" and "DENY" rules to UPNs
      other than the owner of the calendar the ability to write new
      objects with the property "METHOD" property set to the "REQUEST"
                       --------calendar
      value.  This CARID allows the owner to specify which UPNs are
      allowed to make scheduling requests.  An example definition for
      this VCAR is:
----------------------------------------
[32;1753]

   capurl   = "cap://" csid [ "/" relcalid ]
   csid     = hostport   ; As defined in Section 3.2.2 of RFC 2396
   relcalid = *uric      ; As defined in Section 2 of RFC 2396
   ***************************************************************
[
this seems to only allow CSID URIs and qualified CalIDs.
should it also allow relative CalIDs?
(looks like 8.36/TARGET and possibly other places say it should)

also, are qualified and relative CalIDs suppose to be special cases of CalID?
because (going back to section 1.3 [9;490]):
   Calendar Identifier (CalID) -  A globally unique identifier
      associated with a calendar.  Calendars reside within a CS.  See
      Qualified Calendar Identifier and Relative Calendar Identifier.
      All CalIDs start with "cap:".
]
----------------------------------------
[skipping 6.1]
----------------------------------------
[51;2832]

   Description: This data type is an identifier that denotes a CU or a
   group of CU.  A UPN is a RFC 822 compliant email address, with
   exceptions listed below, and in most cases it is deliverable to the
   CU.  In some cases it is identical to the CU's well known email
   address.  A CU's UPN MUST never be an e-mail address that is
   deliverable to a different person as there is no requirement that a
   person's UPN MUST BE their e-mail address.  A UPN is formatted as a
   user name followed by "@" followed by a Realm in the form of a valid,
   and unique, DNS domain name.  The user name MUST BE unique within the
   Realm.  In  it's simplest form it looks like "[email-masked]".
              -----its
----------------------------------------
</PRE>