Date: Wed, 05 Feb 1997 10:28:04 -0800 (PST) From: Chris Newman <Chris.Newman@innosoft.com> Subject: Re: Use of ";" in relative URLs: procedural issue? In-Reply-To: <email@example.com> To: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU> Cc: IETF URI list <firstname.lastname@example.org> Message-Id: <Pine.SOL.3.95.970205100205.17170Aemail@example.com> On Tue, 4 Feb 1997, Roy T. Fielding wrote: > A new URL scheme should not be designed as a byte-encoding of the > particular network protocol in question, unless that network protocol > uses the URI directly (like HTTP). If the properties of the protocol > are known, then it is possible to define a URI-happy syntax with an > unambiguous mapping to the protocol request without using any of the > protocol-specific delimiters. On the flip side, if the model that the protocol provides doesn't map into the traditional syntatical usage of URLs, then it makes more sense to byte-encode the protocol than to invent a whole new syntax, IMHO. > I think you are letting one inappropriate use of syntax drive the rest > of your perceived needs. An IMAP server can be defined as a collection > of resources in the same way as an HTTP server structures resources -- > map all folders as a path ending with a trailing slash, In IMAP, it is legal for a folder called "foo/" to be a message folder with a completely different meaning from a folder called "foo". The big difference between IMAP and HTTP is that HTTP has a single hierarchy, and IMAP has (message) hierarchies within (folder) hierarchies. > map individual > items (UID, or simply "a message") as the next component and differentiate > it from other components using a trailing ";", and then continue the path > to define specialization upon that item. For example, > > imap://<hostport>/<folder-path>/<message uid>;/1/2 > > can, with proper definition (e.g., disallowing unescaped ";" in folder-path) > be the complete URL for a particular sub-part of the body of a message > accessible via IMAP, and completely amenable to relative addressing. I've traditionally seen the ";" used for parameters of the form ";foo=bar". Using it as a syntactic suffix in the middle of a path rather than a parameter prefix seems to be breaking the model. Yes, I could invent new syntactic uses for various symbols, but I really was trying to stick to the existing syntactic model for URLs. > Likewise, for your other IMAP examples: > > imap://<hostport>/;TYPE=<list_type>?<folder>+<folder>+<folder> This doesn't seem to fit the FTP model. The IMAP LIST command only allows one folder pattern. > will do quite well for your enc_list_mailbox format, and > > imap://<hostport>/<folder-path>/?attr1=value&attr2=value&attr3=value > > is capable of representing the enc_search_program identifier for a > particular folder; No. An IMAP search program can include parentheses, and AND/OR/NOT groupings. It doesn't map to a simple attribute/value structure. > Exceptions are not allowed, period. The relative parsing syntax is > scheme-independent, so the choices are either to work within it or not > work at all. There doesn't seem to be anything about the IMAP services > that would require a change to a different parsing algorithm, provided > that the imap syntax is chosen to correspond to the existing semantics > of hierarchical identifiers. Assuming there is a strong opinion that I must change this, an alternate syntax which would work without the exception would be: imap://<hostport>/<folder>;PART=<uid>[/<section>] This would, of course, leave no way to have a relative IMAP URL referring to a different part of the same message. I'm not sure that's an important feature given the CID URL scheme, so I wouldn't fight such a change too hard. On the other hand, the IMAP URL scheme has been on the table for a while and I'm quite reluctant to change unless necessary now it's in last call. I'll readily admit that I'm an IMAP expert and not a URL expert.