[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IRIP version 4 (Part 1) c
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!?!?).
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!!)?
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...
Bruce
===========================================================================
Bruce Kahn INet: Bruce_Kahn@iris.com
Iris Associates Phone: 978.392.5335
Westford, MA, USA 01886 FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...