To follow up on what Roy T. Fielding said ...
This discussion is getting really confusing. I agree with Larry in
that Content-IDs should be an absolute form, since they never express
a relative construct. It is not possible to use message ids in relative
forms because the message-id URL does not require "/" to represent
hierarchy (nor should it).
Consider the following demurrur: The form "message-id?content-id"
is a "well posed" search URI where pre-conditioning over the
message-id means that searching may be limited to parts
(including the root part) found in the cited message. [By "well
posed" I mean under a suitable mapping of your
relative-url-compatible "general URI syntax" to MIME contexts.]
This is a search which ranges over a set of MIME-parts, i.e.
objects which can bear a Content-ID attribute, to match the value
of content-id provided following the '?'. The set of parts are
contained within the cited message. Their hierarchical location
is not specified and the '/' punctuation is not used.
The relative URI "./?content-id" was suggested as a feasible way
to say "within the same [set] as here, find ..." This
differentiates a local search from the bare "?content-id" which
searches the World.
(...)
There are 3 cases:
1) The embedded URL is relative to the path of the first part's location
/////
to make this MIME-correct, I think we need to say root here. [No?]
2) The embedded URL is relative to some abstract BASE URL other than (1)
3) The embedded URL is absolute
4) The embedded URL is cid:....
Although 3 and 4 are really the same, I differentiate them just to point
out that there is nothing wrong with explicitly using the (proposed) cid
URL within the HTML part.
Cases 3 and 4 can be different. In that case the embedded
relative URL is the common tail of multiple absolute URLs all of
which apply to the content of the part. For example, the URL in
the body of the part is relative and fixed while the base varies
between source and destination contexts.
Case 3 is important -- just because a URL is in absolute form does not
mean that the UA should be required to retrieve it from that location.
If the entity corresponding to that location is included as another part
of the multipart message, then the UA must be able to recognize it as
such and use the local part. This requires either a catalog part (mapping
content-ids to locations, etc.) or a Content-Location on each part.
I prefer the latter.
At a minimum, the standards should support the latter. There is no
reason why the standards should not support the former.
Case 2 is necessary for those times when the location of the referrer
has nothing to do with the embedded relative URLs within the referrer.
This is the case for a table of contents which is distributed
independently of the main content. This case requires a Base
(or Content-Base) header field for each part that makes this distinction.
Yes.
Case 1 is the obvious case, but it is the only one for which
Content-Disposition has any relevance. However, disposition cannot
ensure a duplication in paths, so references like "../icons/smiley.gif"
won't work anyway. BUT, since the UA *can* determine the correct part
//////////
Not at all. The MIME agent can match disposition-location-wannabe's
in exactly the same manner as you described for Case 3 (parts marked
with absolute _source_ location). The logic is symmetrical as to whether
the parts are identified by their location at the source, or _projected_
at the recipient [Keith's file-method proposal e.g.].
by parsing the embedded URL relative to the referrer's Content-Location
and then comparing the resolved URL to the Content-Location of the
other message parts, using Content-Disposition for this purpose isn't
even necessary.
Necessary is not the question. It is sufficient and sometimes
preferable.
Do you see that indicating a Content-Disposition-Location is a
desirable capability? In the large -- never mind
cross-references between respective parts of a common part-tree?
I think that this capability will be in demand independent of
MIME or multiparts.
If this is implemented, is matching on projected
disposition-location _sufficient_? Yes. So it is a feasible
option. If people want to mark up parts with dispositions
anyway, they don't need to add YetAnotherHeader indicating
_either_ a Content-ID _or_ the source location just to support
PartFinding. They have a sufficient key in the
disposition-location. It's the cheapest solution in this case.
So, I suggest that
Content-Location: absoluteURI
and Content-Base: absoluteURI
Prefer the flexibility, if Content-Base is defined, to have
Content-Location be unrestricted URI i.e. include relative URLs.
be defined, stating explicitly that LWSP-chars inside the field value
be ignored so that the URL can be folded over several lines.
[Note: surrounding the URL with double-quotes is not necessary if it
is the only content of the field].
[Note: Stick to quotes. The FAQ archive at Utrecht has
implemented and proposed to the faq-maintainers(_at_)consensus(_dot_)com
discussion (which drives the news.answers guidelines) a header
form which I would represent as:
"URL:" URI (word | quoted-phrase) ; location-specific
; description
FAQ maintainers have a valid requirement to put more than one
location attribute on an object, so they can distinguish the
master but also mention mirrors (rougly put). (the
"Description:" header does not suffice because they need a
description per location...)
We should not set the content-location header on a course which
makes it incompatible with that sort of use.]
In fact, I can do this as a revision to RFC 1808, since this really
does impact that specification.
Would you be amenable to the addition of "location=" (relative or absolute
URI) and "base=" (absolute URI required if location is relative)
parameter definitions to the Content-Disposition header of RFC 1806 as
well?
I hope that you will agree that these long mumbles define
miniscule tweaks in the statement of what needs to be done.
Al Gilman