LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives


MHTML Archives

MHTML Archives


View:

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

Options:

Join or Leave MHTML
Reply | Post New Message
Search Archives


Subject: Re: New version of the MHTML ietf draft
From: Nick Shelness <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Sun, 23 Nov 1997 12:10:26 +0000
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (173 lines)


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: &#168;

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

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

Permalink



LISTSRV.NORDU.NET

CataList Email List Search Powered by the LISTSERV Email List Manager