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:
<IMG SRC="/images/ietflogo1.gif" ALT="IETF logo1">
<IMG SRC="/images/ietflogo2.gif" ALT="IETF logo2">
<IMG SRC="/images/ietflogo3.gif" ALT="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
|
