home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mhtml / mhtml-agenda-97aug.txt < prev    next >
Text File  |  1997-08-04  |  11KB  |  288 lines
  1. MIME Encapsulation of Aggregate HTML Documents WG (mhtml)
  2.  
  3. Thursday, August 14 at 0900-1130
  4. ================================
  5.  
  6. Chair: Einar Stefferud <stef@nma.com>
  7.  
  8. AGENDA:
  9.  
  10. The MHTML WG will review Implementation Experience, and will
  11. review and revise the Informational Draft which will document
  12. implementation and deployment issues in an RFC for the
  13. internet community.  The WG will also consider possible
  14. protocol actions that may be required to deal with errors
  15. uncovered by implementaton efforts.
  16.  
  17. MHTML draft agenda for the IETF meeting in Munich 1997, Version 3
  18. -----------------------------------------------------------------
  19.  
  20. This issue list is also available in neater format at URL:
  21. http://www.dsv.su.se/~jpalme/ietf/mhtml-issue-list-0797v3.html
  22. More information is also available at URL:
  23. http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html
  24.  
  25. *****  Documents to be discussed during the meeting
  26.  
  27. 2112 PS
  28. E. Levinson, "The MIME Multipart/Related Content-type", 03/12/1997.
  29. (Pages=9) (Format=.txt) (Obsoletes RFC1872)
  30.  
  31. 2111 PS
  32. E. Levinson, "Content-ID and Message-ID Uniform Resource Locators",
  33. 03/12/1997. (Pages=5) (Format=.txt)
  34.  
  35. 2110 PS
  36. J. Palme, A. Hopman, "MIME E-mail Encapsulation of Aggregate Documents,
  37. such as HTML (MHTML)",03/12/1997. (Pages=19) (Format=.txt)
  38.  
  39. draft-ietf-mhtml-rev-01.txt
  40. J. Palme, A. Hopman, "MIME E-mail Encapsulation of Aggregate Documents,
  41. such as HTML (MHTML)"
  42. ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-spec-07.txt
  43. The same document is available in Microsoft Word format at URL:
  44. ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-spec-07.doc
  45. And difference from RFC 2110 in Microsoft Word 6 format at URL:
  46. ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-spec-07dif.doc
  47. Note that the official IETF file name of the new draft is
  48. "draft-ietf-mhtml-rev-01.txt" and not "draft-ietf-mhtml-spec-07.txt".
  49.  
  50. draft-ietf-mhtml-info-06.txt
  51. J. PaLme, Sending HTML in E-mail, an informational supplement to
  52. RFC 2110: MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML),
  53. version 06.
  54. It can be retrieved by anonymous FTP from URL:
  55. ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-info-06.txt.
  56.  
  57. *****  Issue 1: Exact matches in section 8.2
  58.  
  59. 5.1 Do we by exact matches mean case sensitive matches and no
  60. resolution like "file%20name" to "file name". Note: This should not be
  61. any problem if standards are adhered to, since spaces are not legal in
  62. URLs. However, it is accepted practice for Web browsers to accept lots
  63. of kinds of illegal URLs, and the two most widely used products both
  64. accept spaces in URLs in hyperlinks in HTML documents. How should such a
  65. URL be handled in the Content-Location statement. Should the space be
  66. converted to %20 (then the words about exact matching in mhtml-spec
  67. chapter 8.2.2 most be changed) or should it be put in illegal format in
  68. the Content-Location header, too?
  69.  
  70. The MHTML proposed standard (RFC 2110) at present says that URL-s in e-
  71. mail headers are to be encoded using the encoding method of RFC 2017,
  72. and RFC 2017 refers to RFC 1738 which specifies that illegal characters
  73. in URL are to be encoded using the % method, for example a space is
  74. encoded as %20. Ed Levinson has proposed that the encoding method of RFC
  75. 2047 should be used instead in the special case where RFC 1738 encoding
  76. would make it impossible to make the exact match required by RFC 2110.
  77. The advantage with this is that when the RFC 2047 encoding is reversed,
  78. we get back the same string, and can do the exact match. If RFC 2017/RFC
  79. 1738 encoding is used, reversal may reverse too much, so that the exact
  80. match will not work.
  81.  
  82. 5.2 Does this apply only to relative Content-Locations without any
  83. Content-Base? Should we say something about exactness of matchings when
  84. URL-s are resolved using a Content-Base? If so, what?
  85.  
  86. 5.3 What about the case where the URL is relative and unresolvable in
  87. the header, but absolute in the HTML text. The present spec does not say
  88. what should be done in that case.
  89.  
  90. *****  Here is an example which explains some of the choices:
  91.  
  92. Assume you have a HTML document which contains the following element:
  93.    <IMG SRC="file name.gif">
  94. and the owner of this HTML document requests that it is sent by e-mail.
  95. How should the e-mail look like in this case?
  96.  
  97. (a)
  98.  
  99.      Content-Type: Text/HTML
  100.  
  101.      <IMG SRC="file name.gif">
  102.  
  103.      Content-Type: Image/GIF
  104.      Content-Location: "file name.gif"
  105.  
  106. (b)
  107.  
  108.      Content-Type: Text/HTML
  109.  
  110.      <IMG SRC="file%20name.gif">
  111.  
  112.      Content-Type: Image/GIF
  113.      Content-Location: "file%20name.gif"
  114.  
  115. (c)
  116.  
  117.      Content-Type: Text/HTML
  118.  
  119.      <IMG SRC="file name.gif">
  120.  
  121.      Content-Type: Image/GIF
  122.      Content-Location: "file%20name.gif"
  123.  
  124. (a) is not in agreement with RFC 2017, which RFC 2110 refers to, so if
  125. we choose (a), RFC 2110 or RFC 2017 must be changed.
  126.  
  127. (b) means you have to edit the HTML text before sending it, which is not
  128. so nice, since you are then opening a big can of worms: Which
  129. corrections of faulty HTML should you correct before sending it via e-
  130. mail?
  131.  
  132. (c) requires change in the text about "exact match" in RFC 2110.
  133.  
  134. *****  Issue 2: Precedence of Content-Base and Content-Location
  135. in section 5
  136.  
  137. If there is both a Content-Base and a Content-Location header, which of
  138. them should take precedence in resolving URL-s in the HTML content?
  139.  
  140. *****  Issue 3: Use of Content-Base and Content-Location for
  141. information
  142.  
  143. Should the Content-Base and Content-Location be allowed in cases where
  144. they do not influence functionality, as a way of informing the reader
  145. that a body part was taken from a certain web location?
  146.  
  147. *****  Issue 4: Allow Content-Base, Content-Location outside
  148. Multipart/related?
  149.  
  150. Any reason to remove this passage in RFC 2110 section 4.1:
  151.  
  152. These two headers may occur both inside and outside of a
  153. multipart/related part.
  154.  
  155. JP comment: The statement is true. The specific usage of Content-Base and
  156. Content-Location described in RFC 2110 SHOULD only occur inside
  157. Multipart/related, but these two headers can also occur as information to the
  158. reader that the body part is also available at a certain URL. And since
  159. Text/html can occur outside of Multipart/related (Multipart/related is only
  160. needed when the Text/html contains links to other body parts in the same
  161. message), Content-Base and Content-Location can also occur outside of
  162. Multipart/related, and in my opinion this text should not be removed.
  163. Possibly we could change the paragraph to the following.
  164.  
  165. These two headers may occur both inside and outside of a
  166. multipart/related part, but their usage for handling HTML links
  167. between body parts in a message SHOULD only occur inside
  168. Multipart/related.
  169.  
  170. *****  Issue 5: Allow same Content-Location on two body parts in
  171. section 7
  172.  
  173. Should we allow the same Content-Location on two body parts, if they resolve
  174. to different URLs (last paragraph of section 7 in mhtml-spec).
  175.  
  176. Suggestion: Yes.
  177.  
  178. *****  Issue 6: Content-Base in one part, not in another in section
  179. 8.2
  180.  
  181. Suppose there are two body parts in a multipart/related. One of them has a
  182. Content-Base statement, the other does not have.
  183.  
  184. Example:
  185.  
  186.      Part 1:
  187.  
  188.      Content-Type: Text/html
  189.         Content-Base: http://foo.net
  190.  
  191.         <IMG SRC="picture.gif">
  192.  
  193.      Part 2:
  194.  
  195.      Content-Type: Image/gif
  196.      Content-Location: picture.gif
  197.  
  198. In this case, should relative-to-absolute conversion take place on
  199. "picture.gif" in Part 1, so that it will not match the relative URL in Part
  200. 2?
  201.  
  202. *****  Issue 7: Robustness Principle in general
  203.  
  204. Should the standard include the new chapter 13. Robustness Principle as
  205. suggested in draft-ietf-mhtml-spec-07 or should this chapter be put into the
  206. informational draft draft-ietf-mhtml-info or not be published at all.
  207.  
  208. Note: The present work in the IETF DRUMS working group, where
  209.  
  210. this kind of information, under the title "4. Obsolete Syntax" is included in
  211. the standard-to-be draft-ietf-drums-msg-fmt.
  212.  
  213. *****  Issue 8: Robustness Principles, one by one
  214.  
  215. Every single subchapter in chapter 13. Robustness Principle is controversial
  216. and we should decide for or against having it (this applies whether this
  217. chapter goes into the standard or the informational document).
  218.  
  219. *****  Issue 8.1: Content of the type parameter (section 13.1)
  220.  
  221. Should liberal implementations accept input where the type parameter is wrong
  222. or omitted?
  223.  
  224. *****  Issue 8.2: Quoting of the type parameter (section 13.2)
  225.  
  226. Should liberal implementations accept input where the type parameter is not
  227. quoted?
  228.  
  229. *****  Issue 8.3: Quoting of the start parameter (section 13.3)
  230.  
  231. Should liberal implementations accept input where the start parameter is not
  232. quoted with angle brackets?
  233.  
  234. *****  Issue 8.4: Content-Base/Location in multipart headings
  235. (section 13.4)
  236.  
  237. Should liberal implementations accept and try to use, if necessary, Content-
  238. Base and Content-Location headers in multipart headings.
  239.  
  240. *****  Issue 9: Allow Content-Base, Content-Location to be valid
  241. for object parts?
  242.  
  243. Any reason to change this passage in RFC 2110 section 4.1:
  244.  
  245. These two headers are valid only for exactly the content heading or message
  246. heading where they occurs and its text. They are thus not valid for the parts
  247. inside multipart headings, and are thus meaningless in multipart headings.
  248.  
  249. *****  Issue 10: Examples in chapter 9
  250.  
  251. Can some of the implementors, who have executable code which can check
  252. examples, provide better examples? By better examples I mean examples with
  253. both are correct and which clarify the controversial points.
  254.  
  255. *****  Issue 11: Revised proposed standard or draft standard
  256.  
  257. Are we aiming at revising RFC 2100 into a revised proposed standard or into a
  258. draft standard?
  259.  
  260. *****  Issue 12: Publishing of the info document
  261.  
  262. Is it time now to publish draft-ietf-mhtml-info-06.txt as an informational
  263. RFC?
  264.  
  265. *****  Issue 13: Charter and status of the working group
  266.  
  267. Is there any need for a discussion about the charter of the working group,
  268. and about whether the working group should be designated as "active" or
  269. "inactive"?
  270.  
  271. *****  Issue 14: Value of start parameter to multipart/related
  272.  
  273. The present MHTML standard (RFC 2110 and RFC 2112 say that if the root
  274. body part of a multipart/related is of type multipart/alternative, then
  275. the type parameter of multipart/related should be "multipart/alternative".
  276. It has been suggested, that this be changed, so that the type parameter
  277. tells what is the main part of the multipart/alternative. One solution
  278. might be to change the syntax of the type parameter so that it can for
  279. example have the value "multipart/alternative;text/html" to indicate
  280. that the root is a multipart/alternative whose primary alternative is
  281. of type text/html.
  282. ------------------------------------------------------------------------
  283. Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
  284. for more info see URL: http://www.dsv.su.se/~jpalme
  285.  
  286.  
  287.  
  288.