LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives


MHTML Archives

MHTML Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave MHTML
Reply | Post New Message
Search Archives


Subject: Recursive retrieval of Base URL from surrounding MIME elements
From: Jacob Palme <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Thu, 21 Aug 1997 10:41:39 +0200
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (123 lines)


One controversial issue in MHTML work has been whether Content-Base and
Content-Location statements in multipart content headers can be used
as a base for relative URLs in the headers and text of inner body parts.

RFC 2110 said no, but had an example which wrongly did this.

The decision in the Munich IETF meeting was that only Content-Base
and Content-Location on the immediately surrounding headers can be
used as a base. The arguments for this were

(a) The algorithm will otherwise be more complex, in particular,
it must specify which is to be used to get a base, a Content-Base
on a surrounding part or a Content-Locatin on an inner part.

(b) Some implementers had already implemented it this way or said
it was easier to implement.

However, at the Munich meeting we agreed that MHTML must agree
with the standard for relative URLs, and that we must communicate
with the authors of that standard (draft-fielding-url-syntax-05),
in particular Roy Fielding <[log in to unmask]>.

Fielding has then told us, which we failed to check in Munich,
that the text in draft-fielding-url-syntax-05, which contradicts
RFC 2110, actually is present already in RFC 1808, which says:

   3.2.  Base URL from the Encapsulating Entity

   If no base URL is embedded, the base URL of a document is defined by
   the document's retrieval context.  For a document that is enclosed
   within another entity (such as a message or another document), the
   retrieval context is that entity; thus, the default base URL of the
   document is the base URL of the entity in which the document is
   encapsulated.

   Composite media types, such as the "multipart/*" and "message/*"
   media types defined by MIME (RFC 1521, [4]), define a hierarchy of
   retrieval context for their enclosed documents.  In other words, the
   retrieval context of a component part is the base URL of the
   composite entity of which it is a part.  Thus, a composite entity can
   redefine the retrieval context of its component parts via the
   inclusion of a base-header, and this redefinition applies recursively
   for a hierarchy of composite parts.  Note that this might not change
   the base URL of the components, since each component may include an
   embedded base URL or base-header that takes precedence over the
   retrieval context.

One should also note that we did not consider, in Munich, the case
where you need a base URL to retrieve a document from the net. In
that case, unresolved relative URLs cannot be used, as in MHTML
for documents in other body parts.

How shall we go forward with this? Shall we change our minds,
and accept recursive retrieval of base URLs from surronding headers,
in order to agree with RFC 1808/draft-fielding-url-syntax-05?

If we do this, both our text and the text in draft-fielding-url-syntax-05
must be modified, to clarify what to do if there is a Content-Location
on an inner content-heading and a Content-Base on an outer content-heading.
Which of them should in that case be used.

The current thext in draft-fielding-url-syntax-05 is:

5.1.2. Base URL from the Encapsulating Entity

   If no base URL is embedded, the base URL of a document is defined by
   the document's retrieval context.  For a document that is enclosed
   within another entity (such as a message or another document), the
   retrieval context is that entity; thus, the default base URL of the
   document is the base URL of the entity in which the document is
   encapsulated.

   Composite media types, such as the "multipart/*" and "message/*"
   media types defined by MIME[RFC2046], define a hierarchy of
   retrieval context for their enclosed documents.  In other words, the
   retrieval context of a component part is the base URL of the
   composite entity of which it is a part.  Thus, a composite entity can
   redefine the retrieval context of its component parts via the
   inclusion of a Content-Base or Content-Location header, and this
   redefinition applies recursively for a hierarchy of composite parts.
   Note that this might not change the base URL of the components, since
   each component may include an embedded base URL or base-header that
   takes precedence over the retrieval context.

If we are to accept recursive retrieval of bases from outer content
headers, the text above must be changed to clarify the unclear point.
For example, the text might be changed as follows:

Change:

   Note that this might not change the base URL of the components, since
   each component may include an embedded base URL or base-header that
   takes precedence over the retrieval context.

To:

   Note that this might not change the base URL of the components,
   since each component may include an embedded base URL or a
   Content-Base-header or a Content-Location header with an absolute
   URL, that takes precedence over the retrieval context.

Questions to the MHTML group:

(1) Shall we accept that base URLs can recursively be taken from
    surrounding content-headers?

(2) If no: What arguments should we use to get Roy Fielding to accept
    what is written in RFC 2110?

(3) If yes: How should we clarify the unclear issue? Is the
    text change I propose above acceptable. Corresponding text
    must be included in the revision of RFC 2110, too, of course.








------------------------------------------------------------------------
Jacob Palme <[log in to unmask]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Back to: Top of Message | Previous Page | Main MHTML Page

Permalink



LISTSRV.NORDU.NET

CataList Email List Search Powered by the LISTSERV Email List Manager