To follow up on what Harald(_dot_)T(_dot_)Alvestrand(_at_)uninett(_dot_)no said
...
[review of prioritized base-determining sources for the base of a
relative URL]
What we are now talking about is how to define the base URL of a
message entity. ^^^^^^^^^^^^
Not exactly. A message part has up to three locations:
1) the source location from which it could be refresed
This is the critical location for Message/External-Body
2) its location within the part hierarchy of Multipart/*
composites
3) its location after disposition to the receiving host.
In addition it has an IDentity:
4) the value of a Content-ID: header attached to this
[sub-]structure in the tree.
The latter is a member of a global (supra-message World-) flat
namespace. It also is structurally the value of an attribute
of the MIME-Part object composed of a content and all the
Content-*: attributes associated with that content, as per what
Ned and Dave have been teaching me.
I think the default base URL should be the MID, and the only meaningful
relative URLs should be in CID format; you'd have to invoke some naming
mechanism to get any other kind of relative URL to work, either by
designating the base according to (3.1) above or by another scheme
like the suggested "content-disposition:" stuff.
The MID forms a sufficient ID for the root part of the message, and
hence is a feasible way to identify the base for a Part location
in sense 2) above -- location within the message, location in transit.
What Larry has been arguing is that the CID is world-unique, and
should not be contaminated with garbage that is not necessary to
forming an unique key.
That is exactly the argument that you raised against my proposal
to decorate MIDs with Newsgroups and Location information. I think
that a URI may be allowed to contain helpful information above and
beyond the minimum necessary so long as the differences in priority
are defined in the scheme definition.
This argues strongly for a "mid:xyzy(_at_)wawa(_dot_)com/cid:wwww@ixi.org"
format
- using slashes to separate the components.
I was reserving '/' for the part hierarchy as defined by the
Multipart/* tree. That is the natural match to the structure of
a Mime part tree. The motivation for using the '?' is that we
are doing a search on part attributes. In this case, the part
found may be the root part of the message, if it has both a
Message-ID and a Content-ID, or it could be seven layers deep.
Because you are doing a match over all parts at all levels of the
tree, but matching against the value of a known attribute
(Content-ID header field), I found the use of '?' to be the most
appropriate borrowing from the "General relative-URL-supporting
syntax" defined in RFC 1808. Check this with Roy.
I used a simple '?' and not "/?" because I believe that within the
MIME rules the part found by matching the Content-ID could be the
root part of the message found by the MID part of the URL.
Again, if the content-ID value follows the '?' in the URI, it
is known to be a Content-ID value and the cid: prefix is unnecessary.
That is how I got to the examples in my message.
simple_mid = mid:bl1th3r(_at_)foo(_dot_)(_dot_)net
simple_cid = mid:?gr7ntt9g5thr(_at_)foo(_dot_)(_dot_)net