Subject: CAP Consensus: relativeCALID

From: [email-masked] (Steve Mansour)
Date: Thu, 14 Feb 2002 18:06:49 -0800

Folks,

There still some open issues on relativeCALID .

The current definition of a calendar address is:

     [[<scheme>]://<csid>[:<port>]/]<relativeCALID>

And relativeCALID is defined in CAP 2.6 as:

     <relativeCALID> is an identifier that uniquely identifies the
     calendar on a particular calendar store. There is no implied
     structure in a Relative CALID. It is an arbitrary string of
     printable 7 bit ASCII characters. It may refer to the calendar
     of a user or of a resource such as a conference room. It MUST
     be unique within the calendar store. It is recommended that
     the Relative CALID be globally unique.

There are two issues here.  First, "an arbitrary string of printable 7
bit ASCII characters" is probably not what we want.  Second, is the
recommendation to make relativeCALIDs globally unique.

For the latter issue, I propose we just remove the last sentence.

For the first issue, I'll start the recommendations with the following:

<relativeCALID> is an identifier that uniquely identifies the calendar
on a particular calendar store. There is no implied structure in a
Relative CALID. It is an arbitrary string of ASCII characters as defined
by relcalid below. It may refer to the calendar of a user or of a
resource such as a conference room. It MUST be unique within the
calendar store.

  lowalpha = ( "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i"
           /   "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r"
           /   "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" )

  upalpha  = ( "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I"
           /   "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R"
           /   "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" )

  alpha    = ( lowalpha / upalpha )

  digit    = ( "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7"
           /   "8" / "9" )

  alphanum = ( alpha / digit )

  other    = ( "-" / "_" / "." / "!" / "~" / "*" / "@" / "(" / ")"
           /   "{" / "}" / "/" / "\" / "^" / "[" / "]" )

  relcalid = *( alphanum / other )

Comments are welcome.

-Steve

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 15 Feb 2002 11:58:52 -0500

> There still some open issues on relativeCALID .

How about replacing section 2.6 by the following two sections?

It think this proposal reflects what had been previously agreed
on the list. See:

http://www.imc.org/ietf-calendar/mail-archive/msg02574.html

Let me know if you feel it should be more verbose.

2.x CAP URL

   The CAP URL scheme is used to designate calendar stores,
   and calendars accessible using the CAP protocol.

   The CAP URL scheme conform to the generic URL syntax,
   defined in RFC 2396, and follows the Guidelines for URL
   Schemes, set forth in RFC 2718.

   A CAP URL begins with the protocol prefix "cap" and is
   defined by the following grammar.

      capurl   = scheme ":" [ "//" [ csid ] ] [ "/" relcalid ]
      scheme   = "cap"
      csid     = hostport   ; As defined in Section 3.2.2 of RFC 2396
      relcalid = *uric      ; As defined in Section 2 of RFC 2396

   'relcalid' is an identifier that uniquely identifies a calendar
   on a particular calendar store. There is no implied structure in
   a Relative CALID. It may refer to the calendar of a user or of a
   resource such as a conference room. It MUST be unique within the
   calendar store.

   Examples:

      cap://cal.example.com
      cap://cal.example.com/abcd1234QWER
      cap:///abcd1234QWER
      cap:/abcd1234QWER

   Relative CAP URLs are permitted and are resolved according
   to the rules defined in Section 5 of RFC 2396.

   Example of a relative CAP URL:

      abcd1234QWER

2.x Calendar Addresses

   Calendar addresses can be described as absolute or relative
   CAP URLs.

   Examples:

      cap://cal.example.com/abcd1234QWER
      cap:///abcd1234QWER
      cap:/abcd1234QWER
      abcd1234QWER

   For a user currently authenticated to the CAP server on
   cal.example.com, all four addresses refer to the same
   calendar.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878