mid and cid URLs

Al Gilman (asg@severn.wash.inmet.com)
Tue, 21 Nov 1995 12:19:33 -0500 (EST)


From: asg@severn.wash.inmet.com (Al Gilman)
Message-Id: <9511211719.AA04753@severn.wash.inmet.com>
Subject: mid and cid URLs
To: elevinso@Accurate.COM (Ed Levinson)
Date: Tue, 21 Nov 1995 12:19:33 -0500 (EST)
Cc: ietf-types@cs.utk.edu, uri@bunyip.com
In-Reply-To: <9511201514.AA24375@Accurate.COM> from "Ed Levinson" at Nov 20, 95 10:14:20 am

I need another MIME lesson.

As I look at the draft proposed schemes for mid and cid URLs, a couple
of thoughts come up:

1. By construction, these two nominal schemes are one scheme and we
should only use one name for them.  MID or MIDCID are possibles.

2. A more URL-traditional syntax would be something like

	"mid:" //host-net-path/message-unique

where the RFC Message-ID object was <message-unique@host-net-path>.

3. The structure of a MIME multipart defines a well-ordered hierarchical
space where at each level there is a linear sequence of parts.  We
could index into this part tree with part numbers.  MIME message/partial
usage establishes the precedent that parts number from 1 and the 
generic Internet URL syntax sets the precedent that paths punctuate with
'/'.  If we simply extrapolate from these two boundary conditions, we
get a part URL more or less like this:

	midcidurl ::= "mid:" //host-net-path/message-unique part-number
	
	part-number ::= *( / decimal-integer )

where the interpretation of the decimal integers is as follows:

For each level of hierarchy (defined separator)
	0 refers to the unPart before the first opening-separator
	1 refers to the Part after the first opening-separator
	... 			; there are N parts and N opening-separators
	n > N refers to the unPart after the closing-separator

	opening-separator ::= "--" separator-key 
	closing-separator ::= "--" separator-key "--"

4. To retrieve an object by its Content-ID, the usage

	cidurl ::= "mid:" //host-net-path/message-unique?part-designation

	part-designation ::= part-unique [@host-path-if-different]
where
	Content-ID == <part-unique@(host-net-path | host-path-if-different)>

				; and I have not addressed encoding problems

is more consistent with general Internet URL usage than
introducing the Content-ID with '#'.  In particular, for the
general pattern of URLs, the #fragment clause makes no difference
in the object that is served, only its state as presented.

Since the retrieval of a part by Content-ID only needs to get the
content of the part, the ? syntax which supports searching and can
affect the scope of the object retrieved is more consistent.

This usage would establish, as a rule under the mid: scheme, that
searching defaults to matching part-designation as constructed
above.

Al Gilman