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: Allow recursive lookup of Base from surrounding headers
From: Jacob Palme <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Mon, 25 Aug 1997 12:23:48 +0200
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (74 lines)


No one has commented on my question what to do about the issue of
allowing recursive lookups of bases from surrounding headers.
The Munich IETF MHTML meeting decided not to allow this, but at
that time we were not aware that such recursive lookups are already
allowed according to RFC 1808. Because of this, I now propose
that we reverse our decision in Munich and allow recursive lookups
of bases from surrounding headers. Proposed texts are quoted below.

If anyone does not accept this, please reply and say this. If I
get no opposition to this, I will assume that there is now consensus
to **allow** recursive lookup of bases from surrounding headers.

Question: Is any IETF working group responsible for
draft-fielding-url-syntax-05? I am asking because in that case
we have to liaise with that group in resolving this issue.

---

(1) Change as appropriate "Base" to "Content-Base" and "Location" to
    "Content-Location" in draft-fielding-url-syntax-05:

(2) Change in draft-fielding-url-syntax-05:

       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.

(3) Change in draft-fielding-url-syntax-05:

      5.1.4. Default Base URL

      If none of the conditions described in Sections 5.1.1--5.1.3 apply,
      then the base URL is considered to be the empty string and all
      URL references within that document are assumed to be absolute URLs.

      It is the responsibility of the distributor(s) of a document
      containing relative URLs to ensure that the base URL for that
      document can be established.  It must be emphasized that relative
      URLs cannot be used reliably in situations where the document's base
      URL is not well-defined.

   To:

      5.1.4. Default Base URL

      If none of the conditions described in Sections 5.1.1--5.1.3 apply,
      then the base URL is considered to be the empty string and all
      URL references within that document are assumed to be absolute URLs.
      In the special case of matching references from HTML text to
      Content-Location values inside a Multipart/Related, the base
      URL can be assumed to be the string "//HTTP://" (See RFC ???.)

   (??? to be replaced by the forthcoming RFC to replace RFC 2110)

      It is the responsibility of the distributor(s) of a document
      containing relative URLs to ensure that the base URL for that
      document can be established.  It must be emphasized that relative
      URLs cannot be used reliably in situations where the document's base
      URL is not well-defined.

Corresponding changes in draft-ietf-mthml-rev-00.



------------------------------------------------------------------------
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