This list of issues can be found at URL:
HTTP://dsv.su.se/jpalme/ietf/issues-960605.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 the document? |
| 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 URIs in headers might in that case be a better choice. |
| 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? |
| 3 | SPEC 5 | Are the priorities for resolving relative URLs in section 5 OK and in the right 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 should we 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 this is 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 also privately defined URIs and URLs. If so, should we require that their name begins with "X-"? |
| 7 | SPEC 8.1 |
Is it OK to SHOULD-require that all linked body parts must be inside the
Multipart/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 in
the Content-Location header? If not, we have to specify exactly what kind
of 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 |
SPEC says that 8-bit-characters can be encoded using either Quoted-Printable or the encoding methods of HTML itself, but that the HTML methods are recommended. Is this OK?
What should be the conformance requirements on this issue? Be able to understand both encoding, also when they are mixed in the same document, but need be able to generate only one of them? |
| 10b | SPEC 11.1 | By mistake, section 11.1 mentions Quoted-Printable but not Base64. Of course, both encodings are equally legal. If we want to make a recommendation, we might recommend Quoted-Printable, since HTML is mostly text and will usually be more readable for non-MIME recipients in Quoted-Printable format. |
| 10c | SPEC 11.2 | Should we require that all line breaks must be CRLF-s in Text/HTML if sent as 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.) |
| 11 | SPEC 13 | Are the conformance requirements in SPEC section 13 the right ones? Note that these require conformant system to be able to receive both Content-Location and Content-ID identified parts, but only requires systems to be able to generate 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/related Content-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 default ACTION in forms is to be the URL of the HTML file it occurs in? |
| 20 | All |
Future work plan:
|
| 21 | All | Any other issues? |