Content-Type: text/html Jacob, I have now had a chance to read your latest submission which I hadn't done before I replied earlier. This has resulted in a some changes to my earlier note. > Added text in section 3: > > This standard can also be used to send sets of linked documents which > are not shown simultaneously, and where the user can use links to move > between them. > > (This addition was necessary, because a change of wording made by Nick > Shelness could be interpreted to mean that the standard only applied to > linked objects which are to be shown inline. I do not believe this is our > intention? Or is it?) The new text reads:- "An aggregate document is a MIME-encoded message that contains a root resource (object) as well as other resources that are required to represent that document (inline pictures, style sheets, applets, etc.). It is important to keep in mind that aggregate documents need to satisfy the differing needs of several audiences. This standard can also be used to send sets of linked documents which are not shown simultaneously, and where the user can use links to move between them." I think that to maintain its flow to the following paragraph, it should read:- An aggregate document is a MIME-encoded message that contains a root resource (object) as well as other resources linked to it via URIs. These other resources may be required to display a multimedia document based on the root resource (inline pictures, style sheets, applets, etc.), or be the root resources of other multimedia documents. It is important to keep in mind that aggregate documents need to satisfy the differing needs of several audiences. > In section 7: > > This standard does not cover links from one multipart/related to > another multipart/related in a message containing multiple > multipart/related objects > > added text at the end: > > either in parallel or nested one within the other. The new text seems to lack your addition and still reads:- "This standard does not cover the case where a resource in a multipart/related structure contains URIs that reference MIME body parts outside of the current multipart/related structure or in other MIME messages, even if methods similar to those described in this standard are used. Implementors who employ such URIs are warned that receiving agents implementing this standard may not be able to process them." As I suggested in my earlier note, it should read:- This standard does not cover the case where a resource in a multipart/related structure contains URIs that reference MIME body parts in another parallel or nested multipart/related structure, or in another MIME messages, even if methods similar to those described in this standard are used. Implementors who employ such URIs are warned that receiving agents implementing this standard may not be able to process them. > I am a little wondering about one change which Nick Shelness made: > > He changed > > 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 > Content-Type: IMAGE/GIF > Content-Transfer-Encoding: BASE64 > > to > > Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo.gif > Content-Type: IMAGE/GIF > Content-Transfer-Encoding: BASE64 > > I have made the change, but is not sure why Nick wanted this change. > There is too little time left before the ietf draft submission > deadline for me to ask him why he made this change. At the time of my earlier rely, I couldn't quite remember why I made the change which was done quickly while coming to the end of a flight. In thinking about it further, it was because it provides an example of a complex construct, without its corresponding simpler equivalent. I think that the example would be better if it depicted three Content-Location examples:- 1. an absolute Content-Location matching a referencing relative URI resolved by a Content-Base at the multipart/related level; 2. a relative Content-Location resolved by a Content-Base at the multipart/related level, matching a referencing relative URI resolved by the same Content-Base; and 2. a relative Content-Location resolved by a Content-Base in the same content heading, matching a referencing relative URI resolved by a Content-Base at the multipart/related level. Here is the reworked example Example with a relative URI to an embedded GIF picture From: [log in to unmask] To: [log in to unmask] Subject: A simple example Mime-Version: 1.0 Content-Base: http://www.ietf.cnri.reston.va.us/ Content-Type: multipart/related; boundary="boundary-example"; type="text/html" --boundary-example Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE ... text of the HTML document, which might contain URIs referencing resources in other body parts, for example through statements such as: IETF logo1 IETF logo2 IETF logo3 Example of a copyright sign encoded with Quoted-Printable: =A9 Example of a copyright sign mapped onto HTML markup: ¨ --boundary-example Content-Location: http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif ; Note - Absolute Content-Location does not require a Content-Base Content-Type: IMAGE/GIF Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example Content-Location: ietflogo2.gif ; Note - Relative Content-Location is resolved by Content-Base ; specified in the Multipart/Related heading Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example Content-Location: ietflogo3.gif ; Note - Relative Content-Location is resolved by Content-Base ; within the same Content-Heading, even though it follows the ; Content-Location header Content-Base: http://www.ietf.cnri.reston.va.us/images/ Content-Transfer-Encoding: BASE64 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A etc... --boundary-example-- Nick