LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives

MHTML Archives

MHTML Archives


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


Join or Leave MHTML
Reply | Post New Message
Search Archives

Subject: Still problems in draft-ietf-mhtml-rev-00.txt
From: Pete Resnick <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Tue, 5 Aug 1997 12:59:39 -0500

text/plain (96 lines)

I figured I'd try to get this out before Munich. I'm cutting it a bit
close, but it'll give us something to talk about there, if not before.

Not much changed in the revision:

First, from 4.1:

    In order to resolve URI references to other body parts, two MIME
    content headers are defined, Content-Location and Content-Base. Both
    these headers can occur in any message or content heading, and will
    then be valid within this heading and for its immediate content.

I can't figure out what this means. What is it to be valid "within this
heading"? Does that mean that Content-Base and Content-Location somehow
modify the contents of other fields in a heading? I think what you instead
mean the second sentence to say is:

    Both of these headers can occur in any message heading or content
    heading of a MIME part and will apply to the immediate content
    of that message or MIME part.

4.1 continues:

    These two headers are valid only for exactly the content heading or
    message heading where they occur and its text. They are thus not valid
    for the parts inside multipart headings. They are allowed, but cannot
    be used for resolution, when they occur in multipart headings.

Don't use "valid" in the second sentence. "Valid" implies "valid to occur".
You mean "meaningful" or "applicable".

Now that said, this is in direct conflict with:

        <>  secti
on 5.1.2. I think at the very least these two drafts need to come into
agreement. I am inclined to allow what 5.1.2 of Fielding's draft says, but
we need to make a call one way or the other.

Section 4.1 continues:

    These two headers may occur both inside and outside of a
    Multipart/related part, but their usage for handling HTML links between
    body parts in a message SHOULD only occur inside Multipart/related.

I think this piece needs a great deal of clarification. I assume what this
is trying to get across is that Content-Location and Content-Base may occur
in other parts of the message, not necessarily in the multipart/related
that contains the HTML currently being parsed, and that in that situation
you SHOULD NOT go looking for parts elsewhere in the message. But this
isn't clear from that sentence.

The example in 4.2 is still bad. This is supposed to be the section
defining Content-Base. The HTML part shown in 4.2 has no Content-Base at
all. The main purpose of Content-Base is to provide base to HTML parts
which don't have them internally. I suggest that it would be much easier to
explain if you switched around section 4.2 and 4.3 and defined
Content-Location first. Use an example in the description of
Content-Location that didn't contain any Content-Base fields at all. Then
define Content-Base, showing how it would be used with relative URLs in an
HTML part without a BASE tag.

Also note in the example in 4.2, one of the comments says:

   ;  This Content-Location must contain an absolute URI, since no base
   ;  is valid here.

A base is *perfectly valid* here. You don't mean to say that it's not. You
mean to say "since there is no Content-Base field on this part."

In that same example, where Content-Location is on an HTML part, I have no
idea what that Content-Location could be used for. Do you intend to have it
used as a base? Or should the last component of it be stripped off and then
used as a base? Even if this were explained (and it's only mentioned in
passing in section 5), it is certainly not explained in or before section
4.2. It's very confusing as it is.

8.2.2 still has a serious problem IMO:

    If there is NO Content-Base header, and the Content-Location header
    contains a relative URI, then NO relative to absolute resolution SHOULD
    be performed.

This *cannot* be true. When parsing the HTML part, I am going to do
relative to absolute resolution *within the HTML* (using the HTML BASE
directive), and then apply the Content-Base or Content-Location (if it is
absolute) IRRELAVENT of whether subparts have Content-Base or absolute
Content-Location headers. 8.2.2 implies that the way I parse the HTML is
dependent on whether the subparts have Content-Base or absolute
Content-Location headers. That needs to change.


Pete Resnick <mailto:[log in to unmask]>
QUALCOMM Incorporated
Work: (217)337-6377 or (619)651-4478 / Fax: (217)337-1980

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



CataList Email List Search Powered by the LISTSERV Email List Manager