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: WG Last Call Comments on <draft-ietf-mhtml-rev-03.txt>
From: Nick Shelness <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Tue, 11 Nov 1997 14:24:05 +0000
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (128 lines)


First let me apologize to the group for not getting these comments in
earlier. Reviewing this draft or its precursors has been on my to-do list
for the last month, but I just haven't been able to get to it any sooner.
Also, I tried to read it from the standpoint of someone new to the subject.


General comments.
----------------

IMHO, the document could do with copy editing, but if this is merely my
opinion ignore it.

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


Specific comments.
-----------------


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.


Section 4.2 Example

Its not clear what this is an example of.


Section 5 Item (d)

" ... in surrounding multi-part headings. ... "

should read -

... in surrounding multipart and message headings. ...

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.


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.


Section 7 Para 2

I would add the phrase -

, either in parallel or nested one within the other

at the end of the paragraph.

     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.


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.


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


Section 8.1 Para. 2

" ... in the same MIME message. "

should read -

... in the same multipart/related construct.


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.


Section 8.2 Item (e)

The reference to item "(c)" in the first line should be to item (d).


Nick

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