LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives


MHTML Archives

MHTML Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave MHTML
Reply | Post New Message
Search Archives


Subject: MHTML WG Minutes for WG review before IETF publication...
From: Einar Stefferud <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Wed, 3 Jul 1996 15:24:14 -0700
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (115 lines)


Ned has done a nice job of recording the minutes and providing them
for mailing list reveiw prior to handing over to the IETF for
publication.  Now is your chance to correct anything that needs
correction.  I will ship this to the IETF Secretariat on Wednesday,
July 10 with whatever corrections are in hand at that time.

Best...\Stef   (Thanks Ned!...;-)


Minutes of the MHTML WG meeting held at the Montreal IETF
on Monday, 24 June, 1996.

Einar Stefferud, chair
Jacob Palme, document editor
Ned Freed, minute-taker

Jacob Palme agreed to have a new version of the document based on the
results of this meeting out by Wednesday.  A document editing
committee consisting of Alex Hopman, Lewis Geer, Mark Joseph, and Hal
Howard will meet then to do a final editing pass over the document.

The meeting then moved on to consider the various agenda items:

(a) Use of the Content-Location header.  It was decided to delete the
    text requiring an exact match of document URLs to Content-Location
    and instead require that receivers resolve relative URLs to
    absolute URLs (per RFC 1808) prior to comparison.


(b) Format of Links to Other Body Parts.  It was decided to simply say
    that if you want to make sure that a recipient has a given
    resource you should put it inside of the same multipart/related
    construct. Others means of referencing may work, or they may not.

(c) Multipart/related vs. content-disposition.  It was decided to
    remove the text in section 10 to resolve this issue.

(d) LWSP in URLs in e-mail headers. It was decided to reference the
    URL access-type RFC (not yet assigned an RFC number).

(e) Encoding of 8-bit characters in URLs. It was decided to reference
    to URL access-type RFC (again).

(f) Relation to HTTP 1.1 specification of Content-Base and
    Content-Location.  The present text is fine; it coincides with
    HTTP 1.1; the Base: header in RFC 1808 is no longer relevant.

(g) Use of relative URLs in text/html contents.  The present text is fine.

    (*) Recent RFCs have received some pushback because they do not
        define "should" and "must".  Text needs to be added to do this.

(h) Support for fast rendering.  Take out section 8.4; catalogs are
    for further study.

    (*) The includes parameter to multipart/related.  Take out section
        7.2; this is also for further study and resolution of (h) may
        eliminate this anyway.

    (*) It is noted that the IMAP community needs to be aware of any
        future work done on (h) and (i), as it may impact IMAP4.

(i) Allow file URLs.  Allow them but there may be problems.  Don't
    encourage them. Larry Masinter agreed to provide additional text.

(j) Allow non-IETF URLs.  Not specifically disallowed; not discussed.

(k) Encoding of non-ASCII characters in HTML bodies.  Jacob Palme has
    new text which seems acceptable modulo some terminology changes
    from Larry Masinter. Further work will be done during the editing
    session later this week.

(l) Recommend any encoding as better than another.  This can be
    discussed in the informational document if necessary; no absolute
    recommendation will be made.

(m) Line breaks must be CRLF.  This is discussed in MIME; no need to
    talk about it here.  It can go into the informational document.

(n) base64 should be allowed.  Of course it should be. There is
    apparently one missing reference to it that needs to be added.

(o) Conformance requirements. Statements involving the include
    parameter and catalogs will be removed.  Discussion of conformance
    on the part of senders should also be removed. The remaining
    discussion of receiver conformance will be moved from section 13 to
    section 8.  Section 13 can now be used to define "should" and"must"

(p) Multipart/related become a proposed standard.  This work depends
    on this happening; this WG has a new draft to replace the
    experimental multipart/related RFC.

(q) Multipart/related issues. None are known.

(r) Informational companion RFC?  Plan for it to appear, but let it sit
    out there as a draft until it is complete and then worry about it.

(s-w) All part of theinformational RFC. Deferred.

(x) Default action in forms.  Some words of warning about not assuming
    a default form action are needed. The rest is for further study.

(y) Keep Alex Hopmann as editor. The answer is yes.

(z) Reports on implementation status.  Deferred.

(za) Future work plan. See above. There will be an immediate working
     group last call after the editing is complete. This will be four
     week last call -- targe is the end of July.

(zb) Any other issues. Larry brought up document versioning; he now
     says that this is best turned into an offline discussion with Ed
     Levinson.

Respectfully submitted by Ned Freed...

Back to: Top of Message | Previous Page | Main MHTML Page

Permalink



LISTSRV.NORDU.NET

CataList Email List Search Powered by the LISTSERV Email List Manager