Re: Use of ";" in relative URLs: procedural issue?

["Roy T. Fielding" <[e-mail]>]

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    ([e-mail])
    University of California, Irvine, CA 92697-3425    fax:[phone]
    http://www.ics.uci.edu/~fielding/