Re: IRIP version 4 (Part 1) c

[Doug Royer <Doug.Royer@xxxxxxx>]

> From: Bruce_Kahn@iris.com
> Date: Wed, 24 Mar 1999 19:10:04 GMT
> 
> Steve asked:
> >>Bruce_Kahn@iris.com 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
-------------------------------------------------------------------
Doug.Royer@Sun.COM		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL