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: WG Last Call Comments on <draft-ietf-mhtml-rev-03.txt>
From: Jacob Palme <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Sun, 16 Nov 1997 10:21:14 +0100

text/plain (222 lines)

At 14.24 +0000 97-11-11, [log in to unmask] wrote:
> Also, I find the use of the same boundary string with the text
> "boundary-example-1" confusing. I suggest removing the enumeration, or even
> better, changing the string to "MIME-boundary".

You are right, this could be confusing tom some readers, even if it is not
incorrect. I will change "boundary-example-1" to "boundary-example" in the
version. In the draft-ietf-mhtml-info-09.txt, I will keep
"boundary-exmaple-1" and "boundary-example-2" in those examples which need
more than two different-named boundaries.
> Section 4.2 Para. 1
> " ... the URI that corresponds to the content ... "
> I'm not sure that a URI corresponds to content. Strictly speaking in the
> context of MHTML a Content-location header labels the content. Thus I would
> suggest the following:-
>  ... the URI that labels the content ...
> Section 4.2 Para. 2
> I'm not sure that this para. adds any value, and therefore, I think that it
> should be deleted in its entirety.

The paragraph reads:

  The Content-Location header can be used to indicate that the data sent
  under this heading is also retrievable, in identical format, through normal
  use of this URI. If used for this purpose, it must contain an absolute URI
  or be resolvable, through a Content-Base header, into an absolute URI. In
  this case, the information sent in the message can be seen as a cached
  version of the original data.

The same thing is said better in the next paragraph

  The URI in the Content-Location header may, but need not refer to an object
  which is actually available globally for retrieval using this URI (after
  resolution of relative URIs). However, URI-s in Content-Location headers
  (if absolute, or resolvable to absolute URIs) SHOULD still be globally

So I agree the first of these two paragraphs can be removed.
> Section 4.2 Example
> Its not clear what this is an example of.

The example is erroneous in that the content-type of the second body
part should med image/gif and not text/html. Also, since the paragraph
before talks about two equally valid representations, the example
should show this.

I suggest the example is changed to read as follows. It will then
show a mixture of two different ways in the same example, which
is useful to have shown by an example.


   Content-Type: "multipart/related"; boundary="boundary-example";


   Content-Type: text/html; charset=US-ASCII

   ... ... <IMG SRC="fiction1/fiction2"> ... ...
   ... ... <IMG SRC="cid:97116092811xyz*"> ... ...


   Content-Type: image/gif
   Content-ID: <97116092511xyz*>
   Content-Location: fiction1/fiction2


   Content-Type: image/gif
   Content-ID: <97116092811xyz*>
   Content-Location: fiction1/fiction3


> Section 5 Item (d)
> " ... in surrounding multi-part headings. ... "
> should read -
> ... in surrounding multipart and message headings. ...

Right, I will change it.
> I'm not sure that the second sentence adds any meaning beyond that
> expressed earlier, and therefore, I think that it should be deleted in its
> entirety.

This is one of many cases where the same thing is said twice in different
parts of the document. In the original text, there was much less such
repetition. However, people reading the document have many times requested
"clarifications" which meant adding repetitions of what is said at other
places. I have then done these so-called "clarifications". Now, you are
complaining that there are repetitions. This circle can go on for ever,
with some people wanting to remove repetitions, other people wanting to add
"clarifications" round and round and round. I suggest that the text is
kept. The risk with repetitions is that they might be slightly different,
and an implementor might then not know what is right. The advantage with
repetitions is that the text becomes easier to read if the necessary
information is given where it is needed. I suggest we keep the text.
> Section 5 Para. 1 following Item List
> I'm not sure the phrase following the last comma adds any meaning beyond
> that expressed earlier, and therefore, I think that it should be deleted in
> its entirety.

The sentence you are discussing is the following:

  This matching is done as if they had been given as base an imaginary URL
  "this_message:/", which exists for the sole purpose of resolving relative
  references within a multipart/related entitity.

This was something Roy Fielding wanted very much, I think he wants to write
similar text in his document. I do not feel this is terribly important, but
there is no damage, and if Roy wants it, I suggest we keep it.
> Section 7 Para 2
> I would add the phrase -
> , either in parallel or nested one within the other
> at the end of the paragraph.

Good clarification, I will change it.
>      Note, that this and other paragraphs within the draft render
>      Larry Masinter's construction -
>         1 multipart/related
>            1a message/rfc822
>               1a1 multipart/related
>                  1a1a text/html
>                  1a1b image/gif
>            1b image/gif
>      in which an URL in an inner multipart/related references
>      a body part in an outer multipart/related illegal!
>      If we want to allow these constructs then we will have
>      to alter the draft to do so.
No, not illegal, just not covered by this standard. That is an important
difference. I understand that many implementors plan to use hyperlinks
in cases not covered by the standard. This might be a problem. Suppose
implementor A sends a message with hyperlinks outside of multipart/
related, and implementor B-s software cannot handle this? The risk
in practice, however, is probably not so large. Nested multipart/
related does not sound terribly useful. Hyperlinks between messages
or parts of them, however, can be very useful and I would not be
surprised if we later change the standard to allow this, at least
by using hyperlinks of type "cid" or "mid".
> Section 7 Para 2 following the Item List
> " ... , as well as verify the documents against their WWW counterpoints. "
> I'm not sure that this phrase adds any value, and therefore, I think that
> it should be deleted in its entirety.

Why not? It seems useful to be able to verify a document you can get
two different ways if you feel the need to be very sure.
> Section 7 Para. 4 following the Item List
> " ... links to MIME body parts outside of the current "multipart/related"
> ... "
> should for consistency read -
> ... links to MIME body parts outside of, or nested within other
> multipart/related constructs within, the current "multipart/related" ...

Right! I changed your wording slightly to make the text more readable,
and wrote as follows:

  This standard does not cover the case where a "multipart/related" contains
  links to MIME body parts nested within other multipart/related constructs,
  or outside of the current "multipart/related" or in other MIME messages,
  even if methods similar to those described in this standard are used.
> Section 8.1 Para. 2
> " ... in the same MIME message. "
> should read -
> ... in the same multipart/related construct.

Good, changed!
> Section 8.2 Item (d)
> I'm not sure that the last sentence adds any value, and therefore, I think
> that it should be deleted in its entirety.

I think it makes the text clearer, suggest we keep it.
> Section 8.2 Item (e)
> The reference to item "(c)" in the first line should be to item (d).
Right, changed!

Jacob Palme <[log in to unmask]> (Stockholm University and KTH)
for more info see URL:

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



CataList Email List Search Powered by the LISTSERV Email List Manager