This list of issues can be found at URL:
HTTP://dsv.su.se/jpalme/ietf/issues-960621.html.
Here are some issues which should be discussed either in the MHTML mailing list, or during the Montreal meetings.
References:
| No. | Reference | Description |
|---|---|---|
| 1 | SPEC |
What about Alex Hopmann? He has not had time to work on the memo, but quite large segments from his previous draft are included in the current memo. Should he be kept as co-author if he has not time to check and approve thedocument?
|
| 2a | SPEC 4.3 |
Is the rather short text 4.3 "Encoding of URIs in e-mail" headers enough, or do we need something more complex. Note: A separate IETF standard on how to encode URI's in headers might in that case be a better choice.
Proposal: Reference draft-ietf-mailext-acc-url-01.txt, which has now been accepted as a proposed standard.
|
| 2b | SPEC 4.3 |
Which encoding scheme should be recommended/mandated for characters greater than 127 or less than 32 decimal in URL-s in message headers? The scheme in RFC 1522 or that in RFC 1738?
|
| 2c | SPEC 4 |
The latest version of draft-ietf-http-v11-spec-05, the HTTP 1.1 specification, now has Content-Location and Content-Base with the same usage as ours, although our specification is somewhat more detailed. Should we reference HTTP 1.1? This can only be done if this becomes a proposed standard. Or should we even abandon our own text and only use the HTTP 1.1. text instead?
|
| 3 | SPEC 5 |
Are the priorities for resolving relative URLs in section 5 OK and in theright order?
|
| 4 | SPEC 7.2, SPEC 8.4 |
What about aids to facilitate fast rendering? Should we include a catalogue,or is the "includes" parameter in section 7.2 enough, or shouldwe do nothing at all? Should we include notation for designating catalogue body parts, but not say anything about the format of such catalogues?
|
| 5 | SPEC 8.1 |
Any reason to forbid "File" URL-s in Content-Location? Since thisis only used for matching against an identical string in the HTML part,why should we disallow "File"??
|
| 6 | SPEC 8.1 |
Should we restrict Content-Location to IETF-defined URIs, or allow alsoprivately defined URIs and URLs. If so, should we require that their namebegins with "X-"?
|
| 7 | SPEC 8.1 |
Is it OK to SHOULD-require that all linked body parts must be inside theMultipart/related? Or should this even be changed to a MUST requirement? Note: This only applies to URL-s referring to body parts within the message. URL-s referring to files to be retrieved through the net are also always allowed!
|
| 8 | SPEC 8.2 |
Is it OK to require exact match between URL in the HTML document and inthe Content-Location header? If not, we have to specify exactly what kindof inexact matches we want to allow. Someone has suggested that if we require exact match, we should allow multiple Content-Location statements, or multiple values of the Content-Location statement, since there may in the HTML document be URL-s which refer to the same body parts in different ways in different places of the HTML document. Note that theoretically, several sent HTML documents may contain identical relative URL-s referring to different files, in which exact match requires that the sender must rewrite such URL-s before sending them. This can be seen as an issue of whether to make it simpler for senders or for recipients. Requiring exact match makes it more difficult for the senders, who have to ensure that the matches are equal, but makes it easier for the recipients, who do not have to resolve relative URL-s. Since probably more people will receive than send HTML-formatted text, and people with more different kinds of mailers may need to be able to receive HTML-formatted text, I recommend the choice in the draft, which makes it easier for receivers and more difficult for senders. This also better supports mailers which do not have any built in HTML reader, and which turn Text/HTML messages over to a Web browser as a helper application for display of such messages.
|
| 9 | SPEC 10. |
Is it OK to say that Multipart/Related makes Content-Disposition invalid for mailers who can handle Multipart/Related (but not for mailers who interpret Multipart/Related as Multipart/Mixed)? Or should it only make the attachment/inline attribute of Content-Disposition invalid, and not the default filename? Note that REL also says that Multipart/Related makes Content/Disposition invalid. So this is an issue both for the SPEC and REL memos. Attachment/inline: Since corresponding information is given by HTML elements. Filename: Since the Content-Location usually contains the same information (if you only look at the file name at the end of the path).
|
| 10a | SPEC 11.1 |
Proposal: Specify that non-ascii characters may be encoded using either MIME methods (QP, Base64, 8BIT) or HTML method (&-tags) or a mixture of both.
|
| 10b | SPEC 11.1 |
Proposal: Should we make any recommendation for those who have a choice?
QP is best for those who have MIME but no web browser, HTML tags is best for those who have web browsers but not MIME! Should maybe be moved to the info document, pointing out the choice but not recommending any alternative!
|
| 10c | SPEC 11.1 |
By mistake, section 11.1 mentions Quoted-Printable but not Base64 and 8BIT. Of course, all three encodings are equally legal. If we want to make a recommendation, we might recommend use of Quoted-Printable over 7BIT channels, since HTML is mostly text and will usually be more readable for non-MIME recipients in Quoted-Printable format.
|
| 10d | SPEC 11.2 |
Should we require that all line breaks must be CRLF-s in Text/HTML if sentas e-mail? (This is actually required by MIME, but it is not required by HTTP. Someone has suggested that we require CRLF in sent mail, but recommend mailers to understand incoming mail which uses LF or CR as line breaks.)
Proposal: Messages sent by MIME must always have CRLF as line breaks. But the document after MIME decoding of QP or Base64 may have either CR, LF or CRLF as line breaks.
|
| 11 | SPEC 13 |
Are the conformance requirements in SPEC section 13 the right ones? Notethat these require conformant system to be able to receive both Content-Locationand Content-ID identified parts, but only requires systems to be able togenerate one of these two methods.
|
| 12 | REL |
Should we recommend that multipart/related becomes a draft Internet standard?
|
| 13 | REL |
Any other issues on the contents of draft-ietf-mhtml-related? Note: Issue 9 and issue 17 also may require changes in Draft-ietf-mhtml-related, depending on how we resolve those issues.
|
| 14 | INFO |
Should we produce both a standard and an informational RFC?
|
| 15 | INFO 2 |
Any comments on section 2: "Implementation methods" in INFO?
|
| 16 | INFO 4 |
Any comments on section 4: "Recipients which cannot handle the Multipart/relatedContent-Type"?
|
| 17 | INFO 5 |
Any comments on section 5: "Use of the Content-Type: Multipart/alternative"?This has been controversial in earlier discussions. In particular, should the type parameter of the multipart/related in example 5 be "multipart/alternative" or "text/html". Note that if this type should be "text/html", then also REL must be modified. Perhaps there should also be an example where the multipart/related is inside a multipart/alternative, since this may be more appropriate in some circumstances.(Multipart/alternative inside multipart/related reduces the size of the document since inline images need not be duplicated, Multipart/alternative outside multipart/related may be simpler for senders who have two full versions of their document including images, coded with and without use of text/html. Multipart/alternative outside multipart/related also allows more precise positioning of the images in the non-html variant.
|
| 18 | INFO 6 |
Any comments on section 6: Recipient may not have full Internet connectivity?
|
| 19 | SPEC or INFO |
Should anything be said about the HTML 2.0 recommendation that the defaultACTION in forms is to be the URL of the HTML file it occurs in?
|
| 20 | All |
Future work plan:
|
| 21 | All |
Any other issues?
|