- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Tue, 04 Feb 1997 17:01:05 -0800
- To: Chris Newman <Chris.Newman@innosoft.com>
- Cc: IETF URI list <uri@bunyip.com>
A new URI scheme namespace should be designed as a mapping from the generic URI syntax/semantics to the resolution protocol defined by the scheme [note: resolution protocol is not equivalent to network protocol, and this statement is just as applicable to URNs as it is to URLs]. 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. > Specific example: IMAP URLs. > > Folder names in IMAP are hierarchical. In addition, IMAP has the ability > to fetch messages and MIME parts of messages in a folder. The basic > syntax for a section of a message is currently: > > imap://<hostport>/<folder-path>;UID=<message uid>;SECTION=1.2 > > Now if I take a relative URL of ";SECTION=1.3" to refer to a different > MIME section of the same message, the only reasonable resolution is: > > imap://<hostport>/<folder-path>;UID=<message uid>;SECTION=1.3 > > Note that having a "SECTION" without a "UID" is meaningless. UID can't be > included in the folder-path because that would make it ambiguous since > folder-path can include "/". 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, 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. Likewise, for your other IMAP examples: imap://<hostport>/;TYPE=<list_type>?<folder>+<folder>+<folder> 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; as a bonus, restricting the search to a particular UID becomes an obvious extension. > Because IMAP support needs to be deployed before this URL scheme is > implemented anyway, I simply wrote this in as an exception to the > current rules. I don't like exceptions, but applying the current rules > results in nonsense. Now if the rules were updated, the exception > wouldn't be necessary. 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. Cheers, ...Roy T. Fielding Department of Information & Computer Science (fielding@ics.uci.edu) University of California, Irvine, CA 92697-3425 fax:+1(714)824-4056 http://www.ics.uci.edu/~fielding/
Received on Tuesday, 4 February 1997 20:06:24 UTC