MHTML Working Group Minutes of the Munich Meeting held on Thursday, 14 August 1997 These Minutes are submitted by Einar Stefferud from excellent notes provided by Eric Berman. BRIEF SUMMARY: = MHTML met at IETF in Munich with 28 participants and resolved all issues on its agenda. = It was decided that the MHTML specifications should be recycled at Proposed to replace the faulty MHTML PROPOSED STANDARD RFCs currently in circulation. The group set Sept 30 as its date for moving the new documents to IETF Last Call. The new drafts will be posted as soon as possible for WG review and open discussion on the mailing list. = All output of the meeting is subject to review and consensus evaluation on the MHTML Mailing List. List Archives are at List archives are also available by e-mail. Send a message to LISTSERV@SEGATE.SUNET.SE with the text INDEX MHTML to get a list of the archive files, and then send a new message GET to retrieve selected archive files. To subscribe to this list, send a message to LISTSERV@SEGATE.SUNET.SE which contains the text SUB MHTML . +++++++++++++++++++++++++++++++++++++++ Agenda ITEM 0: AGENDA REVIEW: = Jacob Palme provided a detailed agenda; = Nobody had anything to add to it. = These minutes exactly follow the agenda. = AGENDA ITEM 1: Exact matching when no absolute base is known. (draft-ietf-mhtml-info-06.txt section 8.2). Editors Note: At the time of writing these minutes (9 Sept 97), a long EMail discussion has taken place and this agenda item is being resolved. Interested parties are referred to the MHTML ARCHIVES for the discussion and the resolution. ISSUE 1.A: Exact matches in section = illegal URLs -- There appear to be 4 potential solutions: = a) Keep illegal spaces, = b) convert all illegal spaces according to RFC 2017 = (in HTML as well as header), = c) convert only in the mail header, not in the HTML text, d) convert mail header according to RFC 2047. = Both IE & Netscape accept spaces in URLs, = but content-location can=92t have them. = One suggestion: Do relative to absolute conversion, and then do byte-for-byte decoding. NO conversion. Another suggestion: that (d) does not make sense. = Suggest 3 steps: a) relative to absolute url resolution, = b) remove any escaped URL chars, = c) then compare. = Doing (b) after (a) avoids the problem of confusing "/" with hierarchy character. "A/B" and "A%2EB" would match for purposes of matching, but for purposes of relative to absolute, the %2E would not be a hierarchy char. Another suggestion: We should just put in the content-location what was in the URL. I.e., just allow spaces in Content-Location; keep the illegal URLs. Content-location should be blind. Consensus emerged on choice (a) -- just use the illegal URL in the CONTENT-LOCATION header. BUT illegal MIME chars (e.g., u with umlaut in a URL) must be escaped according to RFC 2047 (e.g., space does not have to be encoded, but illegal MIME chars such as u with an umlaut must be). Some people worried about charset issues. But it was pointed out that URLs are really just octets in us-ascii, so simple encoding should be adequate. New proposal: a) remove MIME encoding, b) relative to absolute, c) octet comparison. = Some questions remained. We currently say nothing about charset encodings in the Content-Location MIME header. Should we? It was decided to go to the mailing list with this discussion to seek final resolution. ISSUE 1.B: Matches with content-base specified. Does this apply only to relative Content-Locations without any Content-Base"? Should we say something about exactness of matches when URLs are resolved using a Content-Base? Solution: 8.2.2 should change from "exact textual match" to "exact octet-for-octet match." ISSUE 1.C: Relative unresolvable URL in the header with an absolute URL in the body. (e.g., HTML has relative URL with BASE tag, and MIME has same relative URL but no base. = Answer in this case: spec is OK, no changes needed. ISSUE 1.D: No relative to absolute resolution if no content-Base is present. This regards the Content bases that apply to the parts and content base that applies to the html leaf part. = A proposal: addition to specification that says that when resolving a relative URL in content, the 1st priority is base specifier in the content (e.g., HTML BASE tag), 2nd priority is to look for base specifier in that body parts header, 3rd priority is content-location of that body part. If resolving a relative URL in the header, only look to its content base. = Consensus that this should be clarified in the spec. ISSUE 1.E: Content-Base in one part, not in another in section 8.2. Answer, they do not match in Jacob's example. No dispute. AGENDA ITEM 2: Validity of Content-Base and Content-Location in section 5 of draft-ietf-mhtml-info-06.txt. Editors Note: At the time of writing these minutes (9 Sept 97), a long EMail discussion has taken place and this agenda item is being resolved. Interested parties are referred to the MHTML ARCHIVES for the discussion and the resolution. ISSUE 2.A: Use of Content-Base and Content-Location for information? Question: Should Content-Base and Content-Location be allowed in cases where they do not influence functionality as a way of informing the reader that a body part was taken from a certain location? Consensus that this is not illegal. ISSUE 2.B: Allow Content-Base/Content-Location outside of multipart/related? Draft section 4.1 says "These two headers may occur both inside and outside of a multipart/related part"? First comment here is that "inside/outside" needs to be replaced with "member of" and "not member of". Suggestion: we don't touch the problem of referencing something outside of the multipart/related. = (e.g., Multiparts are unitary things. To do something outside of the multipart/related would require a separate draft -- we won't prevent it, but we don't address it in this spec, it's experimental. E.g., namespace mapping is scoped to the multipart. Suggestion: We should caution strongly against a Content-Location mapped URL from within one multipart/related interfering with links in another multipart/related. This would apply only to Content-Location, not Content-ID. This is something to put under security considerations. ISSUE 2.C: Allow Content-Base/Content-Location to be valid for object parts? (Draft section 4.1 says these two headers are valid... and are thus meaningless in multipart headings") There are 2 issues: a) Need to decide an unclear issue, and = b) Get URL syntax draft to remove references to Content-Location/Content-Base. Observation: Larry Masinter needs to copy our new version in his draft or else we have to change our conclusion to match his. Suggestion: Let's make it clear that our spec is authoritative on Content-Location/Content-Base. Content-Location on a multipart is not actually meaningless, because it can be a base, and multipart/related can be returned by http. Proposal: Content-Base/Content-Location on a multipart, = but with proviso that Content-Base only serves to resolve the Content-Location on the multipart, and the result had better be the location where you can retrieve the whole multipart. Avoids having to walk up and down the tree. Observation: walking up & down the tree is non-problematic. Question: if you have a relative CONTENT-LOCATION and no CONTENT-BASE, should you walk up? Consensus in the room seems to be that we should not walk the tree. Or, stated another way: if it is not on a part, it is not there -- = and you don't walk the tree. Larry Masinter joined the meeting: His URL draft is not a WG draft, he will defer to what the MHTML WG thinks. He wants to know what our WG decides and he wants proposed text. He will be happy for MHTML text to be normative. All this was eventually left to be resolved on the MHTML mailing list. See the mailing lsit archive for resolution. ISSUE 2.D: Precedence of Content-Base and Content-Location in section 5 Determined to not be an issue. ISSUE 2.E: Allow same Content-Location on two body parts in section 7. = Question: Should we allow the same Content-Location on two body parts, if they resolve to different URLs? = (Last paragraph of section 7). Answer: yes. Does Content-Base affect Content-Location adjacent to it? Answer: Yes, we should allow it. It's a bit weird, but it enables some things and was allowed anyhow, and is not actually problematic. ISSUE 2.F: Allow multiple Content-Location headers with different value in same content heading? = Question: Should this be allowed? Some say No Proposal: do not allow multiple Content-Locations so as to avoid ambiguity about base, but a Multipart MIME part can have multiple Content-ID=92s. Suggestion: Allow multiple Content-Locations if sender asserts they=92re all valid. We may need to point out that we are modifying MIME for the Content-Location header, that it applies elsewhere. = Consensus is just say NO. Full stop. ISSUE 2.G: Can Content-Location provide a Base, if no Content-Base is specified? Need language clarification, no major controversy. Consensus: Switch Content-Base and Content-Location descriptions (editorial). = AGENDA IETM 3: Robustness Principles in general: Should we explain how liberal interpretations should deal with incorrect stuff. Basic principle is to say "do the spec, for crying out loud". No robustness principles in spec. = Consensus: We should document what is changed -- and what was wrong in the 2110 examples -- = but basically, you should just do the spec. AGENDA ITEM 4: Miscellaneous technical issues. ISSUE 4.A: Need to scrub the examples. = Suggestion: Find a place to deposit examples. Jacob has the MHTML WG web site. = Consensus that we submit draft examples to ftp directory that Jacob Palme would maintain. Everyone on the list should feel encouraged to submit examples. ISSUE 4.B: Hyperlinks between messages. = There is some worry that we should not explicitly disable/discourage this. Someone expressed worries about the security implications. = Resolution is to be explicit that it is not prohibited, = but note that many agents will not be able to resolve inter-message references. We should perhaps observe in our discussion of scoping that "cid:" is not really subject to those scoping rules, since cid is supposed to be globally unique. Excellent place to note that someday you might be able to use this to reference external messages. ISSUE 4.C: Folding of URLs over multiple e-mail header lines. One approach is RFC 2017, and another is to use draft-freed-pvcsc-03.txt. It was pointed out that you are hosed if you fold at an (illegal) space. No problem here for legal URLs -- they will fold just fine according to RFC2017. So we will add a warning that if you fold an illegal URL, you should make sure you unfold back to the original octets. ISSUE 4.D: Value of start parameter to multipart/related, particularly if "type=3Dmultipart/alternative". Some people are very concerned about manifest -- being able to determine what is in the multipart related. One proposal is to be able to add, say, ";text/html" after type=3D. It was pointed out that this is part of a larger problem of manifests, which would actually suggest a topic for a future WG. Consensus: Do not change anything about type=3D in this spec. AGENDA ITEM 5: ISSUE 5.A: Charter/status of working group. We are clearly active. We have only had a pause in our work. Harald pointed out that we are also definitely not concluded. Goals & Milestones: = Consensus: Try for last call by September 30 for new draft to Proposed standard. Jacob thinks he can get the draft done in time for this. We will meet in December to review implementation progress. Publishing Informational Document: = It is now time to try to propose this simultaneously. Revisions of RFC2111 and RFC2112: Minor corrections needed Interoperability documentation: WE need to write down list of features in protocol, write down a list of implementors, and for each, list who has done what. Need two independent implementations of emitters and two independent implementations or receivers that interoperate. These do not have to be paired up for all features and functions. The feature list must come from the MHTML WG Mailing List. ------- =_aaaaaaaaaa0--