Subject: Re: CAP Consensus: relativeCALID

From: "John Stracke" <[email-masked]>
Date: Fri, 15 Feb 2002 14:18:02 -0500

>I didn't claim the 2nd and 3rd forms were useful.
>Per RFC 2396, these forms should simply be legal.

I disagree.  Remember, the syntaxes in RFC-2396 are examples, rather than 
normative.  (For example, see the Abstract, which says, "This document does not define a generative grammar for URI".) In particular, section 3 ("URI Syntactic Components"), opens with the sentence: "The URI syntax is dependent upon the scheme."  My reading of the rest of the section is that a URI such as 
cap:///relcalid would be primarily for schemes which have heirarchical 
paths, but no server component.  (The file: URL scheme is old, strange, 
and confusing--it is a terrible idea, UI-wise, for file:/foo and 
file:///foo to be equivalent.) And the distinction between scheme:/id and 
scheme:id is for schemes which have heirarchical paths; calids are not.

I say we should support only "cap://server/id" and "id".

/===============================================================\
|John Stracke                    |Principal Engineer            |
[email-masked]   |Incentive Systems, Inc.       |
|http://www.incentivesystems.com |My opinions are my own.       |
|===============================================================|
|Go not to the Vorlons for advice, for they will say both no and|
|sherbert.                                                      |
\===============================================================/

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 15 Feb 2002 17:54:18 -0500

> scheme:id is for schemes which have heirarchical paths; calids are not.

I tell you what.  I don't care.  All URL schemes that
I know of allow this, but if this WG insists in doing
things differently, so be it.

Don't worry about me. I'll manage the added complexity:

  if (!csid.empty()) {
     capurlstr << "cap://" << csid << "/" << relcalid << ends;
  } else {
     capurlstr << relcalid << ends;
  }

versus

  capurlstr << "cap://" << csid << "/" << relcalid << ends;

Sigh!

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

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 18 Feb 2002 15:38:43 -0500

[ I'm cross posting this message to ietf-urn in the hope that people
  from this working group might help us with our CAP URL definition. ]

As requested by members of ietf-calendar I've changed my proposal
(see http://www.imc.org/ietf-calendar/mail-archive/msg04439.html)
to forbid CAP URLs of the following forms:

   cap:///abcd1234QWER
   cap:/abcd1234QWER

Comments anyone?

--------------------------------------------------------------------

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

   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
      abcd1234QWER

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

--------------------------------------------------------------------

Regards,
Bernard

---

From: George Babics <[email-masked]>
Date: Thu, 21 Feb 2002 14:09:49 -0500

This is the latest proposal for the definition of CAP URLs: 

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

People agree, disagree? Please state you opinions.

George