Network Working Group Jacob Palme Internet Draft Stockholm University/KTH draft-palme-hopmann-comp-00.txt Sweden Category-to-be: Not to be published February 1996 Expires August 1996
We now have two different draft texts for the future IETF standard on sending HTML-formatted e-mail messages. One is draft-palme-text-html-02.txt and the other is draft-hopmann-html-email-packaging-00.txt. In order to simplify the work during the few hours we have during the LA meeting, I have tried to make a comparison between the two texts.
This comparison only contains the way the protocols will actually work. There are also differences in wording which will not influence how the standards will work, but may explain ideas in different ways. Such differences are not handled in this comparison - I assume that whoever will be editor of the forthcoming standard will be able to make use of the best explanatory texts from both documents.
Cases where the two proposals agree are mostly not presented in this comparison memo.
I hope I have correctly represented the two proposals. I may produce a revised version of this comparison if something is misunderstood.
This memo has not been submitted to the IETF drafts directories, because of the curfew on such submissions during the week before and during the IETF meetings.
In the text below, the following abbreviations are used:
P = draft-palme-text-html-02.txt
H = draft-hopmann-html-email-packaging-00.txt
Which method should be used to identify the URI-s in inline links in the HTML document (such as IMG tags) with linked objects in separate body parts.
Method Short description P H
Virtual file Short relative URL (looks like Section 9.2 Not included name method a file name) in HTML document and in Content-Location header of the linked body part. Content-Base header needed to resolve the relative URL-s.General- Absolute URI in HTML document Section 9.1: Section Location-Method, and in Content-Location header Allowed 1.3.3.2 and description of the linked body part. section 2: Allowed
General- Section 9.4 Section 2 Location-Method, recommendation
CID method Use of Content-ID-s and URL-s Section 9.3 Section 1.3.2 using the CID URL
Recommendation of these methods in P:
A Text/HTML content may always, in addition to the use the methods described in this chapter of this memo, contain URI-s only resolvable using the method defined for this particular URI scheme, and not referring to any data in separate body parts of the same message.
Method Body part identi- Recommendation fication method
Virtual File name in Recommended as the primary choice, to be file name Content-Location used whenever possible. method headerGeneral Content-Location Recommended if existing HTML documents Content- header are to be sent unchanged, but only if the Location referred-to document(s) are publicly method available and retrievable using the scheme used in the URI.
CID method Content-ID header For experimental use between consenting partners.
Recommendation of these methods in H:
H does not contain very explicit recommendations, except that the Virtual file name method is not described in H, and one can thus assume that H does not recommend this method. One phrase in H can however be seen as indications of which method is recommended in one particular case:
H says in section 2 about an example of use of the General Content-Location method that "This example could be a web page that was mailed to someone", which seems to indicate that H recommends this method when sending existing web pages (the same as P, see above). H does *not* however, as P, require that these web pages be retrievable using the scheme used in the URI. It might be better to explicitly say either that this is required, or that this is not required, to avoid different interpretations by different implementors.
P specifies clearly in section 10 how to indicate to the receiving mailer which of the three methods is used. H does not specify clearly how a receiving mailer can find out which of the methods is used.
Not an issue in H, since H does not include this method.
Issue 4: Use of Multipart/related
No difference between P and H.
P recommends how to use Multipart/alternative in conjunction with multipart/related, H explicitly says that this should not be covered by this standard.
H specifies that the "type" parameter of Multipart/related must be present. P does not specify this, but does refer to RFC 1872, which requires this parameter to be present.
H says that the "start" parameter of Multipart/related is mandatory. P does not specify this, but does refer to RFC 1872, which says that this parameter is optional, and, if not present, defaults to the first body part within the Multipart/related.
P discusses this briefly in section 12, H does not mention this at all.
P discusses this and makes a recommendation in section 7, H explicity says that this should not be covered in this standard.
P (section 3.2) copies the rather elaborate text on this from draft-ietf-mailext-acc-url-01.txt, H (section 1.3.3) just simply states "Since MIME header fields have a limited length and URIs can get quite long, these lines may have to be folded. When the lines are folded, no additional non-white space characters may be introduced, and since white space is not allowed in URIs it is simply ignored."
P (section 11) explicity says that this header should be ignored by mailers capable of recognising Multipart/related, but may be sent and be used by mailers which do not recognise Multipart/related and which thus treats this as Multipart/mixed.
H says (section 1.4) "Content-Disposition should only be used as described in RFC 1806 in order to distinguish between file attachments and inline message components." I assume that H by this means that Content-Disposition should be interpreted also by mailers who understand Multipart/related. This may cause problems, since information of what is inline is also given in the HTML document itself by the tag for the link. Presumably H means that these must always agree. Otherwise, H should specify how to handle contradictions between these two ways of indicating what is inline and not inline.
P specifies an optional "version" parameter for the Content-Type: Text/HTML, indicating the version of HTML used, with "2.0" as default value. This parameter is not specified in H.
P specifies explicitly that a message can cotain more than one Multipart/related body parts, nothing is said about this in H.
H specifies that if HTML is sent without linked objects, then Multipart/related need not be used, Text/HTML can be used directly. This is not specified in P, should be added to P together with an example as in H.
P is somewhat more precise (section 5) on the use of relative URL-s than H (section 1.3.3.1) but the intention is probably the same.
H says that 'Finally, a sending user agent should not make any assumptions about the method that the receiving user agent will use to display the HTML files. For example it should not use Content-Disposition and/or "file:" URLs under the assumption that the receiving UA is going to save the pieces of the HTML aggregate object as files on a disk to be displayed by a separate browser.'
This is somewhat unclear. Does it say that "FILE:" URL:s are forbidden, or that only the combination of "FILE:" URL:s and Content-Disposition filenames is forbidden?
P allows FILE URL-s, or something which looks like FILE names, for the Virtual File Name method.
P says (section 13) that if a document contains only US-ASCII characters plus 8-bit characters encoded using the HTML method of encoding 8-bit characters, then the "charset" parameter to the Text/HTML Content-Type statement should be "us-ascii" while H (section 1.2) in this situation says that the "charset" parameter should be the real character set after de-encoding the HTML encodings.
P has an informational Annex A discussing implementation methods. Should this be removed, retained as an informational annex, or moved into a separate informational RFC?