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: Re: Still problems in draft-ietf-mhtml-rev-00.txt
From: Einar Stefferud <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Wed, 6 Aug 1997 12:19:25 -0700

text/plain (112 lines)

Thanks Pete for providing some really serious critical review and
comment.  We need more if this if we are to avoid yet another round of
re-issue of our RFCs.

Also, here is a suggestion for all of our participants to help us
progress to completion.

It really helps to see alterantive proposed texts to replace stuff
that is stil not good enough.  We cannot and must not ask Jacob to
create every word in our RFCs.  And, we must not ask people who find
problems to be the only person to propose new text.

See you in Munich;-)...\Stef

From Pete Resnick's  message Tue, 5 Aug 1997 12:59:39 -0500:
}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