This list of issues can be found at URL:
HTTP://dsv.su.se/jpalme/ietf/issues-960507.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? |
| 2 | 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. |
| 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? |
| 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? |
| 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. |
| 9 | SPEC 10. | Is it OK to say that Multipart/Related makes Content-Disposition invalid? Or should it only make the attachement/inline attribute of Content-Disposition invalid? Note that REL also says that Multipart/Related makes Content/Disposition invalid. |
| 10 | SPEC 11.2 | Should we require that all line breaks must be CRLF-s in Text/HTML if sent as e-mail? |
| 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 draf-ietf-mhtml-related? |
| 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. |
| 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? |