Received: from cnri by ietf.org id aa03120; 1 Sep 97 6:13 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid GAA21656; Mon, 1 Sep 1997 06:16:45 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id GAA11499 for uri-out; Mon, 1 Sep 1997 06:01:26 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id GAA11494 for ; Mon, 1 Sep 1997 06:01:23 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id FAA14397 for uri@services; Mon, 1 Sep 1997 05:59:26 -0400 (EDT) Received: from ester.dsv.su.se (ester.dsv.su.se [130.237.161.10]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id FAA14394 for ; Mon, 1 Sep 1997 05:59:19 -0400 (EDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by ester.dsv.su.se (8.7.1/8.7.1) with ESMTP id MAA01919; Mon, 1 Sep 1997 12:01:07 +0200 (MET DST) Message-Id: In-Reply-To: <199708301305.JAA28944@access2.digex.net> References: from Jacob Palme at "Aug 29, 97 09:34:58 pm" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 1 Sep 1997 10:26:01 +0200 To: Al Gilman , mhtml@segate.sunet.se From: Jacob Palme Subject: Re: Recursive look up of base in outer headers Cc: uri@bunyip.com Sender: owner-uri@bunyip.com Precedence: bulk At 09.05 -0400 97-08-30, Al Gilman wrote: > Some reading I have done recently in the HTML 4 draft suggests > that webmasters are interested in managing metadata such as > locators for "house styles" on a directory (file tree) basis and > not always at the atomic file level. This is probably reflective > of archive management practices more generally. This suggests > that bringing the MHTML base-finding rules in line with RFC 1808 > would be more consistent with the way that many of the files to > be transmitted as MIME parts are managed at their originating > sites, and you are more likely to get header usage in practice > that matches the published rules. Does your statement answer the question on which has highest priority in deriving the base, an inner Content-Location or an outer Content-Base? Does this mean that people are mapping directory structure to MIME multiparts? For example, if you have a directory structure: dir1 file1.1 dir1.2 file1.2.1 file1.3 then this is sent via e-mail as Content-Type: Multipart/mixed Content-Disposition: attachment; filename=dir1 ... Content-Type: text/plain Content-Disposition: attachment; filename=file1.1 ... Content-Type: Multipart/mixed Content-Disposition: attachment; filename=dir1.2 ... Content-Type: text/plain Content-Disposition: Attachment; filename=file1.2.1 ... Content-Type: text/plain Content-Disposition: attachment; filename=file1.3 ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme   Received: from cnri by ietf.org id aa06764; 1 Sep 97 11:02 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA21930; Mon, 1 Sep 1997 11:05:12 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA17309 for uri-out; Mon, 1 Sep 1997 10:47:03 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id KAA17301 for ; Mon, 1 Sep 1997 10:47:00 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id KAA15373 for uri@services; Mon, 1 Sep 1997 10:44:59 -0400 (EDT) Received: from access2.digex.net (access2.digex.net [205.197.245.193]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id KAA15370 for ; Mon, 1 Sep 1997 10:44:57 -0400 (EDT) Received: (from asgilman@localhost) by access2.digex.net (8.8.4/8.8.4) id KAA01746; Mon, 1 Sep 1997 10:46:18 -0400 (EDT) From: Al Gilman Message-Id: <199709011446.KAA01746@access2.digex.net> Subject: Re: Recursive look up of base in outer headers To: Jacob Palme Date: Mon, 1 Sep 1997 10:46:17 -0400 (EDT) Cc: mhtml@segate.sunet.se, uri@bunyip.com In-Reply-To: from Jacob Palme at "Sep 1, 97 10:26:01 am" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-uri@bunyip.com Precedence: bulk to follow up on what Jacob Palme said: > > Does your statement answer the question on which has highest > priority in deriving the base, an inner Content-Location or > an outer Content-Base? > On the one hand, no, my previous message said nothing on this question. On the other hand, I don't think that there is a problem in this area. The remarks that follow are based on a broad concept of how things should work which I believe is consistent with RFC 1808. They are not based on a close, lawyerly reading of 1808. As I understand it, the statement that The BASE implied by attributes asserted on an inner scope [e.g. in MIME multipart hierarchies] takes precedence over a BASE derived from such attributes attached to an outer scope. is, for RFC purposes, equivalent to saying Search outward to successively wider horizons until you can establish a BASE. If the MHTML RFC were to assert the "inner scope takes priority" rule I do not expect this to conflict with the provisions of RFC 1808 and its successor language in the generic specification for URLs. As for the specific example you quote, yes, an inner Content-Location would take precedence over an outer Content-Base. Content-Location and Content-Base attributes are equivalent in this rule application; they both imply a BASE in the context of HTML documents within the associated MIME part hierarchy scopes. Neither attribute has priority by reason of whether it is a base or location indication. However, within the class of attributes establishing a BASE, the assertion raised most locally takes precedence. SECOND PART > Does this mean that people are mapping directory structure to MIME > multiparts? For example, if you have a directory structure: > No, as I think about it, you could argue either way from what is happening in HTTP because attributes are beign migrated from enclosing scopes in the archive to the atomic HTML file for transmission. But that is because only one file is being sent. I should probably confess that my support for the "accept BASE inheritance from up the tree" notion is more of a general philosophy. That philosophy is, roughly, that since the transmitted multipart tree has a reliable hierarchical structure, and people are generally used to hierarchical archives, that we should make the received multipart hierarchy work like a slice of archive mounted locally, so far as we reasonably can. Maybe a more direct, and compelling argument is that the BASE notion comes out of the part of URL structure which is consciously hierarchical. BASE is a starting node in a tree context. As such, it is natural for the default assumption to be that the part-tree in the message can be BASEd once at the root, or explicitly re-BASEd piecewise if one BASE will not do. -- Al Gilman   Received: from cnri by ietf.org id aa21184; 2 Sep 97 15:43 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA25137; Tue, 2 Sep 1997 15:46:27 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id PAA27754 for uri-out; Tue, 2 Sep 1997 15:24:49 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id PAA27749 for ; Tue, 2 Sep 1997 15:24:46 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id PAA19381 for uri@services; Tue, 2 Sep 1997 15:22:26 -0400 (EDT) Received: from ester.dsv.su.se (ester.dsv.su.se [130.237.161.10]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id PAA19378 for ; Tue, 2 Sep 1997 15:22:23 -0400 (EDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by ester.dsv.su.se (8.7.1/8.7.1) with ESMTP id VAA09301; Tue, 2 Sep 1997 21:24:31 +0200 (MET DST) Message-Id: In-Reply-To: <199709011446.KAA01746@access2.digex.net> References: from Jacob Palme at "Sep 1, 97 10:26:01 am" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 Sep 1997 17:58:53 +0200 To: Al Gilman From: Jacob Palme Subject: Re: Recursive look up of base in outer headers Cc: mhtml@segate.sunet.se, uri@bunyip.com Sender: owner-uri@bunyip.com Precedence: bulk At 10.46 -0400 97-09-01, Al Gilman wrote: > Content-Location and Content-Base attributes are > equivalent in this rule application; they both imply a BASE in > the context of HTML documents within the associated MIME part > hierarchy scopes. Neither attribute has priority by reason of > whether it is a base or location indication. However, within the > class of attributes establishing a BASE, the assertion raised > most locally takes precedence. The MHTML standard says that if there is both a Content-Base and a Content-Location header in the same content heading, the Content-Base has precedence over the Content-Location. Is there any problem with this? Clearly, the standard must specify which has precedence, good standard should not leave things like this undefined. "undefined" in my opinion is an ugly word in standards documents. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme   Received: from cnri by ietf.org id aa23400; 2 Sep 97 17:14 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA25456; Tue, 2 Sep 1997 17:17:26 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id RAA29070 for uri-out; Tue, 2 Sep 1997 17:00:30 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id RAA29064 for ; Tue, 2 Sep 1997 17:00:27 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id QAA19871 for uri@services; Tue, 2 Sep 1997 16:58:07 -0400 (EDT) Received: from access4.digex.net (access4.digex.net [205.197.245.195]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id QAA19868 for ; Tue, 2 Sep 1997 16:58:04 -0400 (EDT) Received: (from asgilman@localhost) by access4.digex.net (8.8.4/8.8.4) id RAA03064; Tue, 2 Sep 1997 17:00:20 -0400 (EDT) From: Al Gilman Message-Id: <199709022100.RAA03064@access4.digex.net> Subject: Re: Recursive look up of base in outer headers To: Jacob Palme Date: Tue, 2 Sep 1997 17:00:20 -0400 (EDT) Cc: mhtml@segate.sunet.se, uri@bunyip.com In-Reply-To: from Jacob Palme at "Sep 2, 97 05:58:53 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-uri@bunyip.com Precedence: bulk to follow up on what Jacob Palme said: > > The MHTML standard says that if there is both a Content-Base > and a Content-Location header in the same content heading, the > Content-Base has precedence over the Content-Location. Is there > any problem with this? Clearly, the standard must specify which > has precedence, good standard should not leave things like > this undefined. "undefined" in my opinion is an ugly word > in standards documents. > Some more loose talk from this end -- I haven't done the homework implied: I suspect that HTTP is willing to trust that header fields are received in the order sent, and give precedence to the textually last header field within a [single message header, or by extension the headers of a single MIME part]. Since in the email context you may not wish to trust that header fields are received in the order that they were sent, you may have a good reason not use that as the basis for resolving conflicts. Personally, I see some virtue to a policy which would make the presence of both a Content-Base and Content-Location header field within the same header block an error [leaving BASE undefined] if they do not agree as to the implied BASE. But I do see the choice whether to fix this quietly, fix it with a warning, or not fix it as a judgement call without an iron-clad case for any one choice. Particularly, if the same Content-Base + Content-Location value pair are at risk of being interpreted one way when transmitted in MIME and another way when transmitted via HTTP I see this as a likely source of trouble and too arcane for prime time. -- Al Gilman   Received: from cnri by ietf.org id aa25037; 2 Sep 97 18:58 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA25727; Tue, 2 Sep 1997 19:01:25 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id SAA01444 for uri-out; Tue, 2 Sep 1997 18:47:49 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id SAA01439 for ; Tue, 2 Sep 1997 18:47:44 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id SAA20458 for uri@services; Tue, 2 Sep 1997 18:45:23 -0400 (EDT) Received: from xochi.tezcat.com (xochi.tezcat.com [204.128.247.12]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id SAA20455 for ; Tue, 2 Sep 1997 18:45:16 -0400 (EDT) Received: from localhost (kweide@localhost) by xochi.tezcat.com (8.8.5/8.8.5/tezcat-96091001) with SMTP id RAA16932; Tue, 2 Sep 1997 17:47:25 -0500 (CDT) Date: Tue, 2 Sep 1997 17:47:23 -0500 (CDT) From: Klaus Weide To: Al Gilman cc: mhtml@segate.sunet.se, uri@bunyip.com Subject: Re: Recursive look up of base in outer headers In-Reply-To: <199709022100.RAA03064@access4.digex.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-uri@bunyip.com Precedence: bulk On Tue, 2 Sep 1997, Al Gilman wrote: > to follow up on what Jacob Palme said: > > > > > The MHTML standard says that if there is both a Content-Base > > and a Content-Location header in the same content heading, the > > Content-Base has precedence over the Content-Location. Is there > > any problem with this? Clearly, the standard must specify which > > has precedence, good standard should not leave things like > > this undefined. "undefined" in my opinion is an ugly word > > in standards documents. > > > > Some more loose talk from this end -- I haven't done the homework > implied: > > I suspect that HTTP is willing to trust that header fields are > received in the order sent, and give precedence to the textually > last header field within a [single message header, or by > extension the headers of a single MIME part]. Since in the email > context you may not wish to trust that header fields are received > in the order that they were sent, you may have a good reason not > use that as the basis for resolving conflicts. Your suspicion is based on speculation, which could have been avoided by "doing your homework"... > Personally, I see some virtue to a policy which would make the > presence of both a Content-Base and Content-Location header field > within the same header block an error [leaving BASE undefined] if > they do not agree as to the implied BASE. But I do see the > choice whether to fix this quietly, fix it with a warning, or not > fix it as a judgement call without an iron-clad case for any one > choice. Since the first paragraph is wrong in what it says about HTTP, there is no basis for this suggestion. > Particularly, if the same Content-Base + Content-Location value > pair are at risk of being interpreted one way when transmitted > in MIME and another way when transmitted via HTTP I see this as > a likely source of trouble and too arcane for prime time. I agree with this, though. But I don't think anybody disagrees. Klaus   Received: from cnri by ietf.org id aa08747; 3 Sep 97 2:13 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid CAA27705; Wed, 3 Sep 1997 02:16:24 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id BAA07986 for uri-out; Wed, 3 Sep 1997 01:59:07 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id BAA07978 for ; Wed, 3 Sep 1997 01:58:58 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id BAA21883 for uri@services; Wed, 3 Sep 1997 01:56:31 -0400 (EDT) Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id BAA21880 for ; Wed, 3 Sep 1997 01:56:17 -0400 (EDT) Received: from nma.com by paris.ics.uci.edu id aj00993; 2 Sep 97 22:51 PDT Received: from paris.ics.uci.edu by norn.nma.com id aa08276; 2 Sep 97 22:48 PDT To: Klaus Weide cc: Al Gilman , mhtml@segate.sunet.se, uri@bunyip.com Subject: Re: Recursive look up of base in outer headers In-reply-to: Your message of "Tue, 02 Sep 1997 17:47:23 CDT." Reply-to: mhtml@segate.sunet.se From: Einar Stefferud MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8271.873265722.1@nma.com> Date: Tue, 02 Sep 1997 22:48:43 -0700 Message-ID: <8273.873265723@nma.com> Sender: owner-uri@bunyip.com Precedence: bulk Cutting to the "Chase Scene";-)... And avoiding the need for everyone to do a lot of homework. This would be shorter if I were smarter. One clear aspect of MIME, as it was designed to Tag and Bag application Information Objects for transport via EMail, which is the most hazzardous transport and most likely-to-damage-its-freight. It is widely recognized that many EMAIL GATEWAYS like to rearrange things to suit somone other than the sender's concept of what is the right order of RFC822 (and MIME) headers, etc. The basic problem is that they tend to take messages apart, and then put them back together in other contexts, whcih may not allow the original order to be maintained. Or in handling, they just gets stuff out of order. So, in RFC822, order was delcared to not be meaningful. Thus, all assumptions that might be made about the order of headers being meaningful is totaly false in the EMail World. This is a fact of life in the massive Internet EMail Installed Base, and wishing this was not so is quite pointless. Lets not bother with such wishes. So, I think it is important for MHTML to specify that no meaning is to ever be implied by the order of apperance in received MIME HEADERS (i.e., Content-*) in any MIME HEADER SET (i.e., that set of MIME HEADERS that are found together without separation by a "DOUBLE NEWLINE" (CRLFCRLF) or "A BLANK LINE". This definition comes out of RFC822 and the basic MIME RFCs. Thus we (MHTML) must precisely define which of Content-Location or Content-Base has precedence when they ar both found together in a single MIME HEADER SET. It must always be either Content-Base or Content-Location, and the implementors should know from our standard that when both are present, whcih one will govern, so as to avoid putting the recipient into an impossible ambiguity. It woudl be very helpful if other related standards for such as HTTP would ageree with this principal so that all implementing parties will always have been informed of the facts. Perhaps we also need to somewhere carefully define what we mean by a "MIME HAEDER SET". Cheers...\Stef From Klaus Weide's message Tue, 2 Sep 1997 17:47:23 -0500 (CDT): } }On Tue, 2 Sep 1997, Al Gilman wrote: } [SNIP]...[SNIP]...[SNIP]...[SNIP]...[SNIP]...[SNIP]...[SNIP]... } }Since the first paragraph is wrong in what it says about HTTP, }there is no basis for this suggestion. } }> Particularly, if the same Content-Base + Content-Location value }> pair are at risk of being interpreted one way when transmitted }> in MIME and another way when transmitted via HTTP I see this as }> a likely source of trouble and too arcane for prime time. } }I agree with this, though. But I don't think anybody disagrees. } } Klaus   Received: from cnri by ietf.org id aa09259; 3 Sep 97 2:54 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid CAA27744; Wed, 3 Sep 1997 02:57:08 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id CAA08671 for uri-out; Wed, 3 Sep 1997 02:44:42 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id CAA08666 for ; Wed, 3 Sep 1997 02:44:39 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id CAA22013 for uri@services; Wed, 3 Sep 1997 02:42:12 -0400 (EDT) Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id CAA22010 for ; Wed, 3 Sep 1997 02:42:09 -0400 (EDT) Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa06037; 2 Sep 97 23:43 PDT To: mhtml@segate.sunet.se cc: uri@bunyip.com Subject: Re: Recursive look up of base in outer headers In-reply-to: Your message of "Tue, 02 Sep 1997 22:48:43 PDT." <8273.873265723@nma.com> Date: Tue, 02 Sep 1997 23:37:41 -0700 From: "Roy T. Fielding" Message-ID: <9709022343.aa06037@paris.ics.uci.edu> Sender: owner-uri@bunyip.com Precedence: bulk >Thus, all assumptions that might be made about the order of headers >being meaningful is totaly false in the EMail World. This is a fact >of life in the massive Internet EMail Installed Base, and wishing this >was not so is quite pointless. Lets not bother with such wishes. Yep. The same is true of HTTP, at least to the extent that header fields with different names could be rearranged in transit. This is necessary to support implementations where the header fields are stored for caching/proxying as a hash table. >So, I think it is important for MHTML to specify that no meaning is to >ever be implied by the order of apperance in received MIME HEADERS >(i.e., Content-*) in any MIME HEADER SET (i.e., that set of MIME >HEADERS that are found together without separation by a "DOUBLE >NEWLINE" (CRLFCRLF) or "A BLANK LINE". This definition comes out of >RFC822 and the basic MIME RFCs. > >Thus we (MHTML) must precisely define which of Content-Location or >Content-Base has precedence when they ar both found together in a >single MIME HEADER SET. It must always be either Content-Base or >Content-Location, and the implementors should know from our standard >that when both are present, whcih one will govern, so as to avoid >putting the recipient into an impossible ambiguity. Exactly. Right now all the RFCs say Content-Base has precedence over Content-Location when they are both found together in a single MIME HEADER SET, though nowhere near as concisely and lacking the formality of a definition for MIME HEADER SET. Such a definition is an excellent idea. ....Roy   Received: from cnri by ietf.org id aa04423; 3 Sep 97 7:13 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid HAA28055; Wed, 3 Sep 1997 07:16:28 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id GAA12751 for uri-out; Wed, 3 Sep 1997 06:54:29 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id GAA12744 for ; Wed, 3 Sep 1997 06:54:25 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id GAA22541 for uri@services; Wed, 3 Sep 1997 06:51:56 -0400 (EDT) Received: from ester.dsv.su.se (ester.dsv.su.se [130.237.161.10]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id GAA22538 for ; Wed, 3 Sep 1997 06:51:52 -0400 (EDT) Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by ester.dsv.su.se (8.7.1/8.7.1) with ESMTP id MAA12427; Wed, 3 Sep 1997 12:54:10 +0200 (MET DST) Message-Id: In-Reply-To: References: <199709022100.RAA03064@access4.digex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 3 Sep 1997 03:15:33 +0200 To: Klaus Weide , Al Gilman From: Jacob Palme Subject: Re: Recursive look up of base in outer headers Cc: mhtml@segate.sunet.se, uri@bunyip.com Sender: owner-uri@bunyip.com Precedence: bulk At 17.47 -0500 97-09-02, Klaus Weide wrote: > On Tue, 2 Sep 1997, Al Gilman wrote: > > Particularly, if the same Content-Base + Content-Location value > > pair are at risk of being interpreted one way when transmitted > > in MIME and another way when transmitted via HTTP I see this as > > a likely source of trouble and too arcane for prime time. > > I agree with this, though. But I don't think anybody disagrees. The MHTML standard says that the order of headers within the same Content- Heading has no effect on the interpretation of the headers (in the case of the headers Content-Base and Content-Location). From what you say, there does not seem to be any reason to change this. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme   Received: from cnri by ietf.org id aa17616; 3 Sep 97 15:25 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA00186; Wed, 3 Sep 1997 15:28:31 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id PAA28401 for uri-out; Wed, 3 Sep 1997 15:11:15 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id PAA28396 for ; Wed, 3 Sep 1997 15:11:12 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id PAA25143 for uri@services; Wed, 3 Sep 1997 15:08:37 -0400 (EDT) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id PAA25140 for ; Wed, 3 Sep 1997 15:08:33 -0400 (EDT) Received: by DOGGATE with Internet Mail Service (5.5.1664.3) id ; Wed, 3 Sep 1997 12:11:05 -0700 Message-ID: <2FBF98FC7852CF11912A000000000001050F6D86@DINO> From: "Andy Jacobs (Exchange)" To: 'Jacob Palme' , Al Gilman Cc: mhtml@segate.sunet.se, uri@bunyip.com Subject: RE: Recursive look up of base in outer headers Date: Wed, 3 Sep 1997 12:11:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1664.3) Content-Type: text/plain Sender: owner-uri@bunyip.com Precedence: bulk > The MHTML standard says that if there is both a Content-Base > and a Content-Location header in the same content heading, the > Content-Base has precedence over the Content-Location. Why not specify that if both headers exist (which is the only case where precedence matters) then the Base and Location headers will be combined according to the [RELURL] rules. This would be consistent with the body part matching that already has to be done by MHTML readers. Another way of saying the same thing would be to say that Location has precedence if it is an absolute URL, and if it is a relative URL then it is combined with the Base. ---- - Andy Jacobs andyj@microsoft.com   Received: from cnri by ietf.org id aa17690; 3 Sep 97 15:28 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA00192; Wed, 3 Sep 1997 15:31:41 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id PAA28467 for uri-out; Wed, 3 Sep 1997 15:15:01 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id PAA28456 for ; Wed, 3 Sep 1997 15:14:58 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id PAA25163 for uri@services; Wed, 3 Sep 1997 15:12:23 -0400 (EDT) Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id PAA25160 for ; Wed, 3 Sep 1997 15:12:21 -0400 (EDT) Received: from nma.com by paris.ics.uci.edu id aa17639; 3 Sep 97 12:01 PDT Received: from paris.ics.uci.edu by norn.nma.com id aa09397; 3 Sep 97 10:11 PDT To: mhtml@segate.sunet.se, uri@bunyip.com Subject: Re: Recursive look up of base in outer headers In-reply-to: Your message of "Wed, 03 Sep 1997 03:15:33 +0200." Reply-to: mhtml@segate.sunet.se From: Einar Stefferud MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9393.873306693.1@nma.com> Date: Wed, 03 Sep 1997 10:11:33 -0700 Message-ID: <9395.873306693@nma.com> Sender: owner-uri@bunyip.com Precedence: bulk Hi All -- I think that it might b e a good idea to clarify the language a bit more to be very explicit about what is a MIME header, per my introduction of a concept called a "MIME HEADER SET" Or, perhaps the thrase "same Content-Heading" has been difined somewhere to mean this same thing. But, I doubt this. It seems to me that there is some ambiguity about what to call a collection of MIME (Contnet-*) Headers that are found grouped together without a separator between them. I will leave it to the various editors of our various standards RFCs to figure out how to clarify this, but it seems to me that much of our current discussion among experts stems from this exact confusion. I think we should take advantage of having just now sorted this out, and apply the lesson to our documents. Cheers...\Stef From Jacob Palme's message Wed, 3 Sep 1997 03:15:33 +0200: } }The MHTML standard says that the order of headers within the same Content- }Heading has no effect on the interpretation of the headers (in the case }of the headers Content-Base and Content-Location). From what you say, }there does not seem to be any reason to change this. }   Received: from cnri by ietf.org id aa22624; 3 Sep 97 18:33 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA00777; Wed, 3 Sep 1997 18:36:54 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id QAA00479 for uri-out; Wed, 3 Sep 1997 16:35:44 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id QAA00437 for ; Wed, 3 Sep 1997 16:33:53 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id QAA25679 for uri@services; Wed, 3 Sep 1997 16:31:17 -0400 (EDT) Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id QAA25665 for ; Wed, 3 Sep 1997 16:30:21 -0400 (EDT) Received: from nma.com by paris.ics.uci.edu id aa25767; 3 Sep 97 13:28 PDT Received: from paris.ics.uci.edu by norn.nma.com id aa09903; 3 Sep 97 13:19 PDT To: mhtml@segate.sunet.se, uri@bunyip.com Subject: Re: Recursive look up of base in outer headers In-reply-to: Your message of "Wed, 03 Sep 1997 12:11:01 PDT." <2FBF98FC7852CF11912A000000000001050F6D86@DINO> Reply-to: mhtml@segate.sunet.se From: Einar Stefferud MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9899.873317995.1@nma.com> Date: Wed, 03 Sep 1997 13:19:55 -0700 Message-ID: <9901.873317995@nma.com> Sender: owner-uri@bunyip.com Precedence: bulk Perhaps clarity is simply obtained by noting that whenever Content-Base and Content-Location are found to have equal predence, the tie should be broken by giving precedence to Content-Location. This eliminates all the concern about explaining about header sets, et al. It also is independent of how the tie was discovered, whether found in the local MIME part, or by searching outward for scope. This looks very nice and tidy to me;-)...\Stef From Andy Jacobs's message Wed, 3 Sep 1997 12:11:01 -0700: } }> The MHTML standard says that if there is both a Content-Base }> and a Content-Location header in the same content heading, the }> Content-Base has precedence over the Content-Location. } }Why not specify that if both headers exist (which is the only case where }precedence matters) then the Base and Location headers will be combined }according to the [RELURL] rules. This would be consistent with the body }part matching that already has to be done by MHTML readers. } }Another way of saying the same thing would be to say that Location has }precedence if it is an absolute URL, and if it is a relative URL then it }is combined with the Base. }---- } - Andy Jacobs } andyj@microsoft.com   Received: from cnri by ietf.org id aa06265; 4 Sep 97 1:22 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid BAA01430; Thu, 4 Sep 1997 01:25:24 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id BAA10598 for uri-out; Thu, 4 Sep 1997 01:09:18 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id BAA10592 for ; Thu, 4 Sep 1997 01:09:11 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id BAA27390 for uri@services; Thu, 4 Sep 1997 01:06:30 -0400 (EDT) Received: from resnick1.qualcomm.com (resnick1.qualcomm.com [206.139.85.98]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id BAA27387 for ; Thu, 4 Sep 1997 01:06:26 -0400 (EDT) Received: from resnick2.qualcomm.com (206.139.85.99) by resnick1.qualcomm.com with ESMTP (Eudora Internet Mail Server 2.0a9); Thu, 4 Sep 1997 00:08:55 -0500 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <9901.873317995@nma.com> References: Your message of "Wed, 03 Sep 1997 12:11:01 PDT." <2FBF98FC7852CF11912A000000000001050F6D86@DINO> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0a19-9.97] Date: Thu, 4 Sep 1997 00:08:46 -0500 To: mhtml@segate.sunet.se From: Pete Resnick Subject: Re: Recursive look up of base in outer headers Cc: uri@bunyip.com Sender: owner-uri@bunyip.com Precedence: bulk On 9/3/97 at 3:19 PM -0500, Einar Stefferud wrote: >From Andy Jacobs's message Wed, 3 Sep 1997 12:11:01 -0700: >} >}> The MHTML standard says that if there is both a Content-Base >}> and a Content-Location header in the same content heading, the >}> Content-Base has precedence over the Content-Location. Which makes sense. We all know of documents who specify a base that is vastly different from their location. You're not supposed to do that, but people do all of the time. >}Why not specify that if both headers exist (which is the only case where >}precedence matters) then the Base and Location headers will be combined >}according to the [RELURL] rules. This would be consistent with the body >}part matching that already has to be done by MHTML readers. >} >}Another way of saying the same thing would be to say that Location has >}precedence if it is an absolute URL, and if it is a relative URL then it >}is combined with the Base. This sounds even more confusing than either of the other choices. Now you're saying I have to take a relative Content-Location and add it to the Content-Base in order to figure out the base of the document. What if the Content-Location has ".." in it? I think this path is wrong-headed. >Perhaps clarity is simply obtained by noting that whenever >Content-Base and Content-Location are found to have equal predence, >the tie should be broken by giving precedence to Content-Location. > >This eliminates all the concern about explaining about header sets, et >al. > >It also is independent of how the tie was discovered, whether found in >the local MIME part, or by searching outward for scope. > >This looks very nice and tidy to me;-)...\Stef Except again, we can all think of common practice where Content-Location is really quite different from what the document expects for base resolution. I think this demonstrates, in part, why there was so much worry in the WG about allowing recursion of these things: Base can be specified, but if it's not specified, it's taken from the location, and if that's not specified you take it from the base of the parent. Which, BTW, brings up an interesting question: Let's say I have the following: Content-Type: multipart/related Content-Base: foo://bar/biff/ Content-Type: multipart/mixed Content-Location: blah://blee/blue.bar Content-Type: text/html What is the base for the text/html, which has neither Content-Location nor Content-Base? Is it (the base we use for its parent since it has not Content-Base) or is it (the specific base of its parent's parent)? I'm not saying these questions can't be answered, but it's certainly not clear from any of the current documents. Allowing recursion just makes the rules complicated and increases the chances for broken implementations. Personally, I don't want to have to go through the same garbage I'm now going through with HTML to implement workarounds for different bugs for each implementation of this thing. I won't object to recursion being allowed, but that definition better be *really* tight. None of the current options impress me yet. pr -- Pete Resnick QUALCOMM Incorporated Work: (217)337-6377 or (619)651-4478 / Fax: (217)337-1980   Received: from cnri by ietf.org id aa01159; 4 Sep 97 3:36 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid DAA01553; Thu, 4 Sep 1997 03:39:41 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id DAA13130 for uri-out; Thu, 4 Sep 1997 03:24:34 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id DAA13125 for ; Thu, 4 Sep 1997 03:24:30 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id DAA27617 for uri@services; Thu, 4 Sep 1997 03:21:47 -0400 (EDT) Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id DAA27614 for ; Thu, 4 Sep 1997 03:21:42 -0400 (EDT) Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa08127; 4 Sep 97 0:21 PDT To: mhtml@segate.sunet.se, uri@bunyip.com Subject: Re: Recursive look up of base in outer headers In-reply-to: Your message of "Thu, 04 Sep 1997 00:08:46 CDT." Date: Thu, 04 Sep 1997 00:14:51 -0700 From: "Roy T. Fielding" Message-ID: <9709040021.aa08127@paris.ics.uci.edu> Sender: owner-uri@bunyip.com Precedence: bulk I must say that this whole discussion is a bit weird to me. Content-Base takes precedence over Content-Location within the same header field set because that is the only reason why Content-Base exists --- to provide a way to say that the embedded links are relative to something other than the document location. Unfortunately, I can't see the confusion because I wrote the words. Given the choice of removing the recursive definition or removing Content-Base, I would remove Content-Base without a second thought. The recursive definition enables efficient handling of encapsulated content without any "searching" whatsoever; it is simply a matter of peeling through layers of context, and that occurs during the handling of any message. If that is not how your software works now, then I guarantee you that making it work that way will improve the extensibility and robustness of your software. The original Base header field was invented before Content-Location, which is probably why the new wording is confusing. Since it is reasonable to expect the base URL to be different from the location only within the innermost layer (the embedded content), it would be reasonable to eliminate the Content-Base header field from MHTML and HTTP and simply stick with the less confusing Content-Location. >I think this demonstrates, in part, why there was so much worry in the WG >about allowing recursion of these things: Base can be specified, but if >it's not specified, it's taken from the location, and if that's not >specified you take it from the base of the parent. Which, BTW, brings up an >interesting question: Let's say I have the following: > >Content-Type: multipart/related >Content-Base: foo://bar/biff/ > > Content-Type: multipart/mixed > Content-Location: blah://blee/blue.bar > > Content-Type: text/html > >What is the base for the text/html, which has neither Content-Location nor >Content-Base? Is it (the base we use for its parent since it >has not Content-Base) or is it (the specific base of its >parent's parent)? It is . I'm sorry I can't think of a better way of explaining it, but it really is a simple definition. In order for any software to read a message, it must start from the outermost layer and work its way in, just like any encapsulated data type. At each layer you have a current base URL, and at each layer that base URL may be set to something different. That resetting could be done by a Content-Base or a Content-Location, but only the first if both are present at that level. Please note that there is no way to implement a MIME content-type handler without parsing message and multipart types from the outside-in. Likewise, a valid handler for text/html must be passed a single URL to be used as the base for relative URL parsing. My specification simply matches the most reliable implementation of those handlers within user agents, and does so in a way that is independent of the innermost media type. ....Roy   Received: from cnri by ietf.org id aa06583; 4 Sep 97 8:41 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid IAA01937; Thu, 4 Sep 1997 08:44:43 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id IAA18632 for uri-out; Thu, 4 Sep 1997 08:16:55 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id IAA18627 for ; Thu, 4 Sep 1997 08:16:52 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id IAA28299 for uri@services; Thu, 4 Sep 1997 08:14:06 -0400 (EDT) Received: from ester.dsv.su.se (ester.dsv.su.se [130.237.161.10]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id IAA28296 for ; Thu, 4 Sep 1997 08:14:03 -0400 (EDT) Received: from [130.237.158.12] (gear.dsv.su.se [130.237.158.12]) by ester.dsv.su.se (8.7.1/8.7.1) with ESMTP id OAA17527; Thu, 4 Sep 1997 14:16:47 +0200 (MET DST) Message-Id: In-Reply-To: References: <9901.873317995@nma.com> Your message of "Wed, 03 Sep 1997 12:11:01 PDT." <2FBF98FC7852CF11912A000000000001050F6D86@DINO> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Sep 1997 14:19:14 +0100 To: mhtml@segate.sunet.se From: Jacob Palme Subject: Re: Recursive look up of base in outer headers Cc: uri@bunyip.com Sender: owner-uri@bunyip.com Precedence: bulk At 00.08 -0500 97-09-04, Pete Resnick wrote: > Content-Type: multipart/related > Content-Base: foo://bar/biff/ > > Content-Type: multipart/mixed > Content-Location: blah://blee/blue.bar > > Content-Type: text/html > > What is the base for the text/html, which has neither Content-Location nor > Content-Base? Is it (the base we use for its parent since it > has not Content-Base) or is it (the specific base of its > parent's parent)? The latest draft says that a base in an absolute Content-Location in an inner heading has precedence over a Content-Base in a heading further out. Below is the text in the draft I sent in a few days ago (ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-rev-01.txt, see also http://www.dsv.su.se/~jpalme/ietf/mhtml.html): --- --- 5. Base URIs for resolution of relative URIs Relative URIs inside contents of MIME body parts are resolved relative to a base URI using the methods for resolving relative URIs described in [RELURL]. In order to determine this base URI, the first-applicable method in the following list applies. (a) There is a base specification inside the MIME body part containing the link which resolves relative URIs into absolute URIs. For example, HTML provides the BASE element for this. (b) There is a Content-Base header (as defined in section 4.2), in the immediately surrounding content heading, specifying the base to be used. (c) There is a Content-Location header in the immediately surrounding heading of the body part which contains an absolute URI and can then serve as the base in the same way as the requested URI can serve as a base for relative URIs within a file retrieved via HTTP [HTTP]. (d) Step (b) and (c) can be repeated recursively on Content-Base and Content-Location headers in surrounding multi-part headings. However, a base from an absolute Content-Location in an inner heading takes precedence over a base from a Content-Base or a Content-Location in a surrounding heading. When the methods above do not yield an absolute URI matching of two relative URIs against each other can still be done for matches within a multipart/related. This matching is done as if they had been given as base an imaginary URL "This_message:/", which exists for the sole purpose of resolving relative references within a multipart entitity. ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme   Received: from cnri by ietf.org id aa06650; 4 Sep 97 8:45 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid IAA01951; Thu, 4 Sep 1997 08:48:30 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id IAA18625 for uri-out; Thu, 4 Sep 1997 08:16:52 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id IAA18620 for ; Thu, 4 Sep 1997 08:16:49 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id IAA28292 for uri@services; Thu, 4 Sep 1997 08:14:03 -0400 (EDT) Received: from ester.dsv.su.se (ester.dsv.su.se [130.237.161.10]) by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id IAA28289 for ; Thu, 4 Sep 1997 08:14:00 -0400 (EDT) Received: from [130.237.158.12] (gear.dsv.su.se [130.237.158.12]) by ester.dsv.su.se (8.7.1/8.7.1) with ESMTP id OAA17520; Thu, 4 Sep 1997 14:16:43 +0200 (MET DST) Message-Id: In-Reply-To: <9395.873306693@nma.com> References: Your message of "Wed, 03 Sep 1997 03:15:33 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 Sep 1997 14:10:51 +0100 To: mhtml@segate.sunet.se, uri@bunyip.com From: Jacob Palme Subject: Re: Recursive look up of base in outer headers Sender: owner-uri@bunyip.com Precedence: bulk At 10.11 -0700 97-09-03, Einar Stefferud wrote: > I think that it might b e a good idea to clarify the language a bit > more to be very explicit about what is a MIME header, per my > introduction of a concept called a "MIME HEADER SET" I think the text is already rather explicit about this in many places. However, in the next version I will add the following text in one of the examples: --boundary-example-1 Content-Location: ietflogo.gif Content-Base: http://www.ietf.cnri.reston.va.us/images/ ; Note that the fact that the Content-Base comes after the ; Content-Location within the same Content-Heading will not ; influence their interpretation ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme   Received: from cnri by ietf.org id aa12994; 4 Sep 97 13:22 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA02845; Thu, 4 Sep 1997 13:25:30 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id NAA28104 for uri-out; Thu, 4 Sep 1997 13:05:44 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id NAA28099 for ; Thu, 4 Sep 1997 13:05:41 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id NAA29472 for uri@services; Thu, 4 Sep 1997 13:02:52 -0400 (EDT) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id NAA29469 for ; Thu, 4 Sep 1997 13:02:49 -0400 (EDT) Received: by DOGGATE with Internet Mail Service (5.5.1664.3) id ; Thu, 4 Sep 1997 10:05:45 -0700 Message-ID: <2FBF98FC7852CF11912A000000000001050F6D89@DINO> From: "Andy Jacobs (Exchange)" To: "'Roy T. Fielding'" , mhtml@segate.sunet.se, uri@bunyip.com Subject: RE: Recursive look up of base in outer headers Date: Thu, 4 Sep 1997 10:05:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1664.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-uri@bunyip.com Precedence: bulk > Content-Base takes precedence over Content-Location within the same > header field set because that is the only reason why Content-Base > exists --- to provide a way to say that the embedded links are > relative to something other than the document location. Content-Base is also used to modify the meaning of Content-Location (when Location is relative). This is a conclusion from the spec which indicates that Base is not needed if Location is an absolute URL, and later when resolving links from an HTML body part to other body parts (if the referenced body part has a relative Location and a Base, they are combined). When I first read the spec, I had thought that modifying the Location was the only purpose of a Base (for the above reasons, and because I read the spec from top to bottom and this purpose was mentioned first). ---- - Andy Jacobs andyj@microsoft.com -----Original Message----- From: Roy T. Fielding [SMTP:fielding@kiwi.ics.uci.edu] Sent: Thursday, September 04, 1997 12:15 AM To: mhtml@segate.sunet.se; uri@bunyip.com Subject: Re: Recursive look up of base in outer headers I must say that this whole discussion is a bit weird to me. Content-Base takes precedence over Content-Location within the same header field set because that is the only reason why Content-Base exists --- to provide a way to say that the embedded links are relative to something other than the document location. Unfortunately, I can't see the confusion because I wrote the words. Given the choice of removing the recursive definition or removing Content-Base, I would remove Content-Base without a second thought. The recursive definition enables efficient handling of encapsulated content without any "searching" whatsoever; it is simply a matter of peeling through layers of context, and that occurs during the handling of any message. If that is not how your software works now, then I guarantee you that making it work that way will improve the extensibility and robustness of your software. The original Base header field was invented before Content-Location, which is probably why the new wording is confusing. Since it is reasonable to expect the base URL to be different from the location only within the innermost layer (the embedded content), it would be reasonable to eliminate the Content-Base header field from MHTML and HTTP and simply stick with the less confusing Content-Location. >I think this demonstrates, in part, why there was so much worry in the WG >about allowing recursion of these things: Base can be specified, but if >it's not specified, it's taken from the location, and if that's not >specified you take it from the base of the parent. Which, BTW, brings up an >interesting question: Let's say I have the following: > >Content-Type: multipart/related >Content-Base: foo://bar/biff/ > > Content-Type: multipart/mixed > Content-Location: blah://blee/blue.bar > > Content-Type: text/html > >What is the base for the text/html, which has neither Content-Location nor >Content-Base? Is it (the base we use for its parent since it >has not Content-Base) or is it (the specific base of its >parent's parent)? It is . I'm sorry I can't think of a better way of explaining it, but it really is a simple definition. In order for any software to read a message, it must start from the outermost layer and work its way in, just like any encapsulated data type. At each layer you have a current base URL, and at each layer that base URL may be set to something different. That resetting could be done by a Content-Base or a Content-Location, but only the first if both are present at that level. Please note that there is no way to implement a MIME content-type handler without parsing message and multipart types from the outside-in. Likewise, a valid handler for text/html must be passed a single URL to be used as the base for relative URL parsing. My specification simply matches the most reliable implementation of those handlers within user agents, and does so in a way that is independent of the innermost media type. ....Roy   Received: from cnri by ietf.org id aa13263; 4 Sep 97 13:33 EDT Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid NAA02874; Thu, 4 Sep 1997 13:36:25 -0400 (EDT) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id NAA28266 for uri-out; Thu, 4 Sep 1997 13:16:09 -0400 (EDT) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id NAA28259 for ; Thu, 4 Sep 1997 13:16:05 -0400 (EDT) Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id NAA29511 for uri@services; Thu, 4 Sep 1997 13:13:01 -0400 (EDT) Received: from doggate.exchange.microsoft.com (doggate.microsoft.com [131.107.2.63]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id NAA29508 for ; Thu, 4 Sep 1997 13:12:45 -0400 (EDT) Received: by DOGGATE with Internet Mail Service (5.5.1664.3) id ; Thu, 4 Sep 1997 10:15:27 -0700 Message-ID: <2FBF98FC7852CF11912A000000000001050F6D8A@DINO> From: "Andy Jacobs (Exchange)" To: 'Pete Resnick' , mhtml@segate.sunet.se Cc: uri@bunyip.com Subject: RE: Recursive look up of base in outer headers Date: Thu, 4 Sep 1997 10:15:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1664.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-uri@bunyip.com Precedence: bulk >>}Why not specify that if both headers exist (which is the only case where >>}precedence matters) then the Base and Location headers will be combined >>}according to the [RELURL] rules. This would be consistent with the body >>}part matching that already has to be done by MHTML readers. > This sounds even more confusing than either of the other choices. Now > you're saying I have to take a relative Content-Location and add it to the > Content-Base in order to figure out the base of the document. What if the > Content-Location has ".." in it? I think this path is wrong-headed. An MHTML reader must be able to do this anyway, when resolving links to other body parts. If the referenced body part has both a Base and a relative Location, they must be combined, taking into account "..", etc. My suggestion was to be more consistent in always interpreting the Base and Location as pairs. Otherwise an inexperienced MHTML writer may want to use a Base header for one purpose (to modify Location or to serve as a base for embedded relative URL's) and not mean to have it used for the other purpose. Since I'm new to the standards process, I don't know whether this should be a concern of the spec, and thus this might be a moot argument. ---- - Andy Jacobs andyj@microsoft.com   Received: from ietf.org by ietf.org id aa08082; 10 Sep 97 10:04 EDT Received: from ietf.ietf.org by ietf.org id aa07504; 10 Sep 97 9:59 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: mhtml@segate.sunet.se Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mhtml-rel-v2-00.txt Date: Wed, 10 Sep 1997 09:59:11 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9709100959.aa07504@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : The MIME Multipart/Related Content-type Author(s) : E. Levinson Filename : draft-ietf-mhtml-rel-v2-00.txt Pages : 9 Date : 09-Sep-97 The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. This document defines the Multipart/Related content-type and provides examples of its use. Internet-Drafts are available by anonymous FTP. Login wih the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-rel-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-rel-v2-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-rel-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970909141244.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-rel-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-rel-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970909141244.I-D@ietf.org> --OtherAccess-- --NextPart--  From daemon Tue Nov 4 09:49:54 1997 Delivery-Date: Tue, 04 Nov 1997 10:00:18 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA06522 for ietf-123-outbound.10@ietf.org; Tue, 4 Nov 1997 09:49:26 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA06503; Tue, 4 Nov 1997 09:49:17 -0500 (EST) Message-Id: <199711041449.JAA06503@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: mhtml@segate.sunet.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mhtml-info-07.txt Date: Tue, 04 Nov 1997 09:49:16 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate HTML Documents (MHTML) Author(s) : J. Palme Filename : draft-ietf-mhtml-info-07.txt Pages : 10 Date : 03-Nov-97 The memo ''MIME Encapsulation of Aggregate HTML Documents (MHTML)'' (draft-ietf-mhtml-rev-02.txt) specifies how to send packaged aggregate HTML objects in MIME format. This memo is an accompanying informational document, intended to be an aid to developers. This document is not an Internet standard. Issues discussed are implementation methods, caching strategies, problems with rewriting of URIs, making messages suitable both for mailers which can and which cannot handle Multipart/related and handling recipients which do not have full Internet connectivity. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-info-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-info-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-info-07.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971103145010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-info-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-info-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971103145010.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Nov 7 10:02:02 1997 Delivery-Date: Fri, 07 Nov 1997 10:08:11 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA06320 for ietf-123-outbound.10@ietf.org; Fri, 7 Nov 1997 09:59:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA06298; Fri, 7 Nov 1997 09:59:16 -0500 (EST) Message-Id: <199711071459.JAA06298@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: mhtml@segate.sunet.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mhtml-info-08.txt Date: Fri, 07 Nov 1997 09:59:15 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate HTML Documents (MHTML) Author(s) : J. Palme Filename : draft-ietf-mhtml-info-08.txt Pages : 10 Date : 06-Nov-97 The memo ''MIME Encapsulation of Aggregate HTML Documents (MHTML)'' (draft-ietf-mhtml-rev-02.txt) specifies how to send packaged aggregate HTML objects in MIME format. This memo is an accompanying informational document, intended to be an aid to developers. This document is not an Internet standard. Issues discussed are implementation methods, caching strategies, problems with rewriting of URIs, making messages suitable both for mailers which can and which cannot handle Multipart/related and handling recipients which do not have full Internet connectivity. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-info-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-info-08.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-info-08.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971106163355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-info-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-info-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971106163355.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Nov 7 09:55:10 1997 Delivery-Date: Fri, 07 Nov 1997 10:08:31 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA06215 for ietf-123-outbound.10@ietf.org; Fri, 7 Nov 1997 09:55:00 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA06196; Fri, 7 Nov 1997 09:54:51 -0500 (EST) Message-Id: <199711071454.JAA06196@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: mhtml@segate.sunet.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mhtml-rev-03.txt Date: Fri, 07 Nov 1997 09:54:50 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) Author(s) : A. Hopmann, J. Palme Filename : draft-ietf-mhtml-rev-03.txt Pages : 19 Date : 06-Nov-97 Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate using HTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type ''multipart/related'' and specifies the MIME content-headers ''Content-Location'' and ''Content-Base''. The guidelines in this document can also be used when sending aggregate HTML objects in other forms than e-mail, such as through HTTP or FTP. Differences compared to the previous version of this proposed standard, published in RFC 2110, are summarized in chapter 13. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-rev-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-rev-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-rev-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971106163024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-rev-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-rev-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971106163024.I-D@ietf.org> --OtherAccess-- --NextPart-- From daemon Fri Dec 5 13:27:37 1997 Delivery-Date: Fri, 05 Dec 1997 13:34:33 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA19595 for ietf-123-outbound.10@ietf.org; Fri, 5 Dec 1997 13:27:26 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA19561; Fri, 5 Dec 1997 13:27:21 -0500 (EST) Message-Id: <199712051827.NAA19561@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: mhtml@segate.sunet.se From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-mhtml-rev-04.txt Date: Fri, 05 Dec 1997 13:27:20 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) Author(s) : A. Hopmann, J. Palme Filename : draft-ietf-mhtml-rev-04.txt Pages : 19 Date : 04-Dec-97 HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object)and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI. In order to transfer a complete HTML multimedia document in a single e- mail message, it is necessary to:- a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure. This document does both. It a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies two MIME content-headers (Content-Base and Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. While initially designed to support e-mail transfer of complete multi- resource HTML multimedia documents, these conventions can also be employed by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents. Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 13. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-rev-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-mhtml-rev-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-rev-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971204170809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-rev-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-rev-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971204170809.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Feb 17 07:57:26 1998 Delivery-Date: Tue, 17 Feb 1998 08:01:04 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id HAA27954 for ietf-123-outbound.10@ietf.org; Tue, 17 Feb 1998 07:57:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA26139; Tue, 17 Feb 1998 07:24:50 -0500 (EST) Message-Id: <199802171224.HAA26139@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mhtml@segate.sunet.se From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-mhtml-rev-05.txt Date: Tue, 17 Feb 1998 07:24:49 -0500 Sender: scoya@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) Author(s) : N. Shelness, A. Hopmann, J. Palme Filename : draft-ietf-mhtml-rev-05.txt Pages : 27 Date : 16-Feb-98 HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object)and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI. In order to transfer a complete HTML multimedia document in a single e- mail message, it is necessary to:- a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure. This document does both. It a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies two MIME content-headers (Content-Base and Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. While initially designed to support e-mail transfer of complete multi- resource HTML multimedia documents, these conventions can also be employed by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents. Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 13. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-rev-05.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mhtml-rev-05.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-rev-05.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980216143516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-rev-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-rev-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980216143516.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Feb 17 08:02:20 1998 Delivery-Date: Tue, 17 Feb 1998 08:04:08 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id IAA28203 for ietf-123-outbound.10@ietf.org; Tue, 17 Feb 1998 08:02:04 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA26157; Tue, 17 Feb 1998 07:24:56 -0500 (EST) Message-Id: <199802171224.HAA26157@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mhtml@segate.sunet.se From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-mhtml-info-09.txt Date: Tue, 17 Feb 1998 07:24:56 -0500 Sender: scoya@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate HTML Documents (MHTML) Author(s) : J. Palme Filename : draft-ietf-mhtml-info-09.txt Pages : 20 Date : 16-Feb-98 The memo ''MIME Encapsulation of Aggregate HTML Documents (MHTML)'' (draft-ietf-mhtml-rev-02.txt) specifies how to send packaged aggregate HTML objects in MIME format. This memo is an accompanying informational document, intended to be an aid to developers. This document is not an Internet standard. Issues discussed are implementation methods, caching strategies, problems with rewriting of URIs, making messages suitable both for mailers which can and which cannot handle Multipart/related and handling recipients which do not have full Internet connectivity. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-info-09.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mhtml-info-09.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-info-09.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980216143530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-info-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-info-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980216143530.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Mar 12 11:26:28 1998 Delivery-Date: Thu, 12 Mar 1998 11:29:40 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA19868 for ietf-123-outbound.10@ietf.org; Thu, 12 Mar 1998 11:25:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA15570; Thu, 12 Mar 1998 09:47:05 -0500 (EST) Message-Id: <199803121447.JAA15570@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mhtml@segate.sunet.se From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-mhtml-rev-06.txt Date: Thu, 12 Mar 1998 09:47:05 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) Author(s) : N. Shelness, A. Hopmann, J. Palme Filename : draft-ietf-mhtml-rev-06.txt Pages : 21 Date : 11-Mar-98 HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object) and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI. In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure. This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies one MIME content-headers (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. While initially designed to support e-mail transfer of complete multi-resource HTML multimedia documents, these conventions can also be employed by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents. Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 12. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-rev-06.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mhtml-rev-06.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-rev-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980311113903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-rev-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-rev-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980311113903.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Mar 17 07:27:51 1998 Delivery-Date: Tue, 17 Mar 1998 07:30:42 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id HAA27195 for ietf-123-outbound.10@ietf.org; Tue, 17 Mar 1998 07:25:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA27021; Tue, 17 Mar 1998 07:16:52 -0500 (EST) Message-Id: <199803171216.HAA27021@ns.ietf.org> To: IETF-Announce: ; Cc: mhtml@segate.sunet.se From: The IESG SUBJECT: Last Call: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Tue, 17 Mar 1998 07:16:51 -0500 Sender: scoya@cnri.reston.va.us The IESG has received a request from the MIME Encapsulation of Aggregate HTML Documents Working Group to consider MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) as a Proposed Standard. This document is intended to replace RFC 2110, currently a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by April 9, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-mhtml-rev-06.txt From adm Mon May 11 10:31:01 1998 Delivery-Date: Mon, 11 May 1998 10:44:34 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id KAA21268 for ietf-123-outbound.10@ietf.org; Mon, 11 May 1998 10:25:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA21105; Mon, 11 May 1998 10:16:14 -0400 (EDT) Message-Id: <199805111416.KAA21105@ietf.org> To: IETF-Announce: ; Cc: mhtml@segate.sunet.se From: The IESG SUBJECT: Last Call: Content-ID and Message-ID Uniform Resource Locators to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 11 May 1998 10:16:13 -0400 Sender: scoya@CNRI.RESTON.VA.US The IESG has received a request from the MIME Encapsulation of Aggregate HTML Documents Working Group to consider Content-ID and Message-ID Uniform Resource Locators as a Proposed Standard. This is a recyle-in-grade, replacing RFC2111. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 25, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-mhtml-cid-v2-00.txt From adm Mon May 11 10:58:01 1998 Delivery-Date: Mon, 11 May 1998 11:07:22 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id KAA21875 for ietf-123-outbound.10@ietf.org; Mon, 11 May 1998 10:55:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA21760; Mon, 11 May 1998 10:50:09 -0400 (EDT) Message-Id: <199805111450.KAA21760@ietf.org> To: IETF-Announce: ; Cc: mhtml@segate.sunet.se From: The IESG SUBJECT: Last Call: The MIME Multipart/Related Content-type to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 11 May 1998 10:50:09 -0400 Sender: scoya@CNRI.RESTON.VA.US The IESG has received a request from the MIME Encapsulation of Aggregate HTML Documents Working Group to consider The MIME Multipart/Related Content-type as a Proposed Standard. This is a recycle-in-grade, replacing RFC 2112. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by May 25, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-mhtml-rel-v2-00.txt From adm Thu Jun 18 12:06:30 1998 Delivery-Date: Thu, 18 Jun 1998 12:18:52 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id MAA18837 for ietf-123-outbound.10@ietf.org; Thu, 18 Jun 1998 12:05:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA18104; Thu, 18 Jun 1998 11:22:24 -0400 (EDT) Message-Id: <199806181522.LAA18104@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mhtml@segate.sunet.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mhtml-info-10.txt Date: Thu, 18 Jun 1998 11:22:23 -0400 Sender: cclark@CNRI.RESTON.VA.US --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the MIME Encapsulation of Aggregate HTML Documents Working Group of the IETF. Title : Sending HTML in MIME, an informational supplement to the RFC: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) Author(s) : J. Palme Filename : draft-ietf-mhtml-info-10.txt Pages : 16 Date : 17-Jun-98 The memo 'MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)' (draft-ietf-mhtml-rev-05.txt) specifies how to send packaged aggregate HTML objects in MIME format. This memo is an accompanying informational document, intended to be an aid to developers. This document is not an Internet standard. Issues discussed are implementation methods, caching strategies, problems with rewriting of URIs, making messages suitable both for mailers which can and which cannot handle Multipart/related and handling recipients which do not have full Internet connectivity. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mhtml-info-10.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mhtml-info-10.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mhtml-info-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980617161012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mhtml-info-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mhtml-info-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980617161012.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Jul 28 06:36:30 1998 Delivery-Date: Tue, 28 Jul 1998 06:45:51 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id GAA08598 for ietf-123-outbound.10@ietf.org; Tue, 28 Jul 1998 06:35:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA08420; Tue, 28 Jul 1998 06:24:30 -0400 (EDT) Message-Id: <199807281024.GAA08420@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: mhtml@segate.sunet.se From: The IESG Subject: Protocol Action: The MIME Multipart/Related Content-type to Proposed Standard Date: Tue, 28 Jul 1998 06:24:30 -0400 Sender: scoya@ns.cnri.reston.va.us The IESG has approved the Internet-Draft 'The MIME Multipart/Related Content-type' as a Proposed Standard. This document is the product of the MIME Encapsulation of Aggregate HTML Documents Working Group. This document replaces RFC 2112, currently a Proposed Standard. The IESG contact persons are Keith Moore and Patrik Faltstrom. Technical Summary The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts. Working Group Summary This is a very minor update to RFC 2112. The only change was to correct typographical errors in some examples. The working group agreed that the RFC needed to be re-issued with this change. Protocol Quality Keith Moore reviewed the spec for IESG. There are several implementations of multipart/related, at least in the MHTML context. Note to RFC Editor: The IESG requests that the change log section of the document be moved to an appendix. From adm Tue Jul 28 06:46:36 1998 Delivery-Date: Tue, 28 Jul 1998 06:57:17 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id GAA08881 for ietf-123-outbound.10@ietf.org; Tue, 28 Jul 1998 06:45:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA08524; Tue, 28 Jul 1998 06:29:04 -0400 (EDT) Message-Id: <199807281029.GAA08524@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: mhtml@segate.sunet.se From: The IESG Subject: Protocol Action: Content-ID and Message-ID Uniform Resource Locators to Proposed Standard Date: Tue, 28 Jul 1998 06:29:04 -0400 Sender: scoya@ns.cnri.reston.va.us The IESG has approved the Internet-Draft 'Content-ID and Message-ID Uniform Resource Locators' as a Proposed Standard. This document is the product of the MIME Encapsulation of Aggregate HTML Documents Working Group. This document replaces RFC2111, currently a Proposed Standard. The IESG contact persons are Keith Moore and Patrik Faltstrom. Technical Summary This protocol defines Uniform Resource Locators for Message-Id and Content-Id. It is used by MHTML to allow one bodypart of a multipart/related content to make references to other bodyparts; for instance, an HTML body part referencing embedded images. Working Group Summary This is a minor modification of RFC 2111, correcting errors in a couple of examples. The working group agreed that the revised document needed to be published. Protocol Quality Keith Moore reviewed the spec for IESG. There are multiple implementations in the context of MHTML.