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

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!?!?).

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: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked] (Steve Mansour)
Date: Wed, 24 Mar 1999 11:22:13 -0800

I think you're right. Just saying that the relcaluid is limited to 7-bit
ascii is probably not enough. I'll reread  1738.

I don't think rfc 2068 (Hypertext Transfer Protocol -- HTTP/1.1) is the
successor to 1738. If anyone knows of the successor to 1738 please
reply. Someone at the ietf meeting had mentioned the successor was 2368,
I read it, but as it only describes the mailto url I don't think it's
the successor.

-Steve

[email-masked] wrote:

> >>           on a particular calendar store. There is no implied
> structure in
> >>Good choice until that last part.  You should preclude some
> characters like
> >>'/' or <CR>, etc.
> 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!?!?).
>
> 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!!)?
>
> 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
>
> ==========================================================================
>

---

From: John Stracke <[email-masked]>
Date: Mon, 29 Mar 1999 19:42:29 +0000

Steve Mansour wrote:

> I don't think rfc 2068 (Hypertext Transfer Protocol -- HTTP/1.1) is
> the successor to 1738. If anyone knows of the successor to 1738 please
> reply. Someone at the ietf meeting had mentioned the successor was
> 2368, I read it, but as it only describes the mailto url I don't think
> it's the successor.

2396 defines URIs.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/