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

[Chris Newman <[e-mail]>]

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.