Subject: Re: IRIP version 4 (Part 1) c

From: Doug Royer <[email-masked]>
Date: Wed, 24 Mar 1999 14:13:32 -0800 (PST)

> From: [email-masked]
> Date: Wed, 24 Mar 1999 19:10:04 GMT
> 
> Steve asked:
> >>[email-masked] wrote:
> >>      <relativeCALID> is an identifier that uniquely identifies the 
> calendar 
> >>           on a particular calendar store. There is no implied structure 
> in 
> >>           a relativeCALID, it is an arbitrary string of charac 
> >>
> >>Good choice until that last part.  You should preclude some characters 
> like 
> >>'/' or <CR>, etc.
> >Why?  You aren't suggesting a delimiter character are you? That would 
> imply some sort of structure. :-) 
> 
> Actually I was more concerned about possibly illegal characters that a CS 
> could not use in a relCalID (ala No '\' in Windows file names, etc). While 
> I am _NOT_ advocating many rules on the relCalID, I do not think there is 
> any chance in hell that a CS is going to be able to actually parse a <CR> 
> or <LF> as part of the relCalID (or _ANY_ value in the command set, etc) 
> since that is already set aside as an EOL delimiter (combined that is). 
> So, by default you already do have some restrictions.  (Or else show me 
> how I could send a RECIPIENT command for foo<CR><LF>bar where the bar is 
> not parsed as a new command line!?!?).

Rewrite your web server :-)

It should be any VALID URL that any compliant HTTP server should accept
as defined by RFC<approiate #>. If we don't do that, we would be defining
a new URI format by saying it is kind of like one but not.

> Also, just how should a CS really decode the relCalID snippet of 
> "?iso-2022-kr....=?" (RFC 2047 encoded ISO-2022-KR text!)?  Should it 
> treat the encoded content as just a raw sequence of bytes (hence it wont 
> name the relCalID w/the Korean characters but rather the raw sequence!!)?

It can charset translate the or not, implementation detail.
Just as any other URL might have to be translated in the iCalendar objects.

> I dont think it is unreasonable to restrict the allowable characters 
> somewhat.  (Just how many folks are _realistically_ going to want a 
> relCalID of '\0x01' (the DOS smiley face??!).  In order to avoid a holy 
> war on this I suggest we check w/the URI WG folks how to best handle this 
> (or read RFC 1738 or its successor RFC ~2068) and follow their advice. 
> After all you did base the structure on the RFC 1738 design...

I think the only way to avoid a holy war is to define it
as compliant to RFC<approiate #>.

If not then we will be asking everyone to submit their list of
what can not be accepted. The list will grow. You said:

	"...(or _ANY_ value in the command set, etc)..."

That is a LARGE number of things to be excluded.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Doug Royer <[email-masked]>
Date: Mon, 29 Mar 1999 15:00:21 -0800 (PST)

> From: "Lisa Lippert (Dusseault) (Exchange)" <[email-masked]>
> Date: Mon, 29 Mar 1999 12:32:07 -0800
> 
> I haven't been at the CAP authors meetings lately, but that shouldn't matter
> -- I don't recall seeing a consensus on the list or in the WG meeting that
> the delimiters should not be defined.

True - but it was discussed at those open meeting as Steve said.

I think that you or Tony were at all of those meeting correct?
Not that that makes consensus, but we did discuss it at the ones
that you attended.

> Undefined strings are very scary for later versions of the protocol -- we
> will hamstring ourselves for CAP 2 (or later) if we can't easily enhance
> hierarchical functionality in calendaring.  Furthermore, interoperability is
> threatened if different implementations understand different things from
> different characters.  I'd like to see a character defined as a hierarchical
> delimiter, even if implementations are not required to support hierarchies.
> It will be much less painful in the long run if we define the character now.

As you and I have talked about this in the past.

The problems have nothing to do with hierarchical functionality. It has
to do with forcing hierarchy vs allowing hierarchy.

If my calendar store is in a database, and not a file system. Hierarchy
is simply information to a user about a calendar. It has no other
meaning.

The proposals would not take out hierarchy. It would however not
force implementation to have hierarchy.

> We should also be very explicit about other possibly "special" characters
> such as spaces, tildes, and whether they are meaningful, meaningless,
> reserved, must be supported, etc.

Just as with any other URL. 

In the scheme specific part of a URL, its opaque 7-bit data. I can
put a '/' in my URL:

	http://xx.yy.zz/this/means/nothing

It DOES NOT MEAN there is any hierarchy. It simply means
pass 'this/means/nothing' to the HTTP port on the xx.yy.zz server.

> From: [email-masked] [mailto:[email-masked]]

> John Stracke wrote:
> > Steve Mansour wrote:
> > >> Good choice until that last part.  You should preclude some
> > >> characters like
> > >> '/' or <CR>, etc.
> > >
> > Even if we don't have structure today, a delimiter permits us to *add*
> > structure later if it turns out to be useful.
> 
> We went through that discussion a two of the editors meetings. The general
> feeling is that it's a bad idea to put *any* sort of meaning into these
> strings. Even a delimiter character.
>