Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/mhtml/mhtml-minutes-97aug.txt

Text File | 1997-10-10 | 15KB | 392 lines

          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.  <[e-mail]>

List Archives are at <ftp://segate.sunet.se/lists/mhtml/>
                     <http://segate.sunet.se/archives/mhtml.html>

List archives are also available by e-mail.  Send a message to
[e-mail] with the text INDEX MHTML to get a list of
the archive files, and then send a new message GET <file name> to
retrieve selected archive files.

To subscribe to this list, send a message to [e-mail]
which contains the text SUB MHTML <your name (not your email address)>.

               +++++++++++++++++++++++++++++++++++++++


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--