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: Notes on MHTML-Rev-04
From: Alex Hopmann <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Tue, 25 Nov 1997 08:25:29 -0800
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (296 lines)


Sorry everyone about the delays. I'm updating my notes for the rev-04 that
Jacob just posted. Here goes.

1) I would like to improve the glossary section a bit:
  a) The current glossary just uses references. We should retain the
references (and make sure its clear that they are normative), but include
some explanitory text so you don't just to jump all over to understand the
document.
  b) The current glossary includes some repedative versions of the same
terms, sometimes with just different spacing or word order. I think that is
unnecessary, and we should rather just make sure we use the terms
consistently in the rest of the document.
  c) I've also removed a few definions that I considered unnecessary (VRML,
PDF).
  D) I would still like to rewrite the "HTML Aggregate Object" definition to
change it to "MIME Aggregate Object", but I was having some trouble coming
up with the right lanuage.

Here is a new proposed version of this section (thanks to Eric Berman for
work on this section):

2.2   Other terminology

Most of the terms used in this document are defined in other RFCs.
Definitions
here are for the convenience of the reader of this document; where
applicable,
the specifications that are referenced contain the normative definition of
the
term.

Absolute URI          A fully-qualified uniform resource indicator, which
can
                      be used to find a resource.  See Relative Uniform
                      Resource Locators [RELURL].

CID                   A Content-Identifier, which provides a globally unique
                      Label for a specific MIME body part.  See
Message/External
                      Body Content-ID [MIDCID].

Content-Base          The URI to use when converting relative URI's into
                      absolute URIs.  See section 4.2 below.

Content-ID            The identifier for a particular body part of a MIME
                      message.  See Message/External Body Content-ID
[MIDCID].

Content-Location      MIME message or content part header with the URI of
                      the MIME message or content part body, defined in
                      section 4.3 below.

Content-Transfer-     The method used to encode data text into 7-bit octets,
Encoding              as specified in [MIME1] chapter 6.

CR                    "Carriage Return", an US-ASCII character with value
13.
                      See [RFC822].

CRLF                  "Carriage Return Line Feed", a sequence of two
US-ASCII
                      characters with values 13 and 10, respectively.  See
                      [RFC822].

Displayed text        The text shown to the user reading a document with
                      a web browser. This may be different from the HTML
                      markup, see the definition of HTML markup below.

Header                Field in a message or content heading specifying
                      the value of one property.

Heading               Part of a message or content before the first
                      CRLFCRLF, containing formatted fields with
                      Properties of the message or content.

HTML                  "HyperText Markup Language."  HTML is a rich common
                      document format on the World Wide Web.  HTML can
                      contain links to additional resources, such as
embedded
                      images.  See HTML 2 specification [HTML2].

HTML Aggregate        HTML objects together with some or all objects, to
objects               which the HTML object contains hyperlinks.

HTML markup           A file containing HTML encodings as specified in
                      [HTML] which may be different from the displayed
                      text which a person using a web browser sees. For
                      example, the HTML markup may contain "&lt;" where
                      the displayed text contains the character "<".

LF                    "Line Feed", an US-ASCII character with value 10.
                      See [RFC822].

MIC                   Message Integrity Codes, codes use to verify that a
                      message has not been modified.

MIME                  "Multipurpose Internet Mail Extensions", a method for
                      encapsulating and transporting rich message content.
                      See the MIME specifications [MIME1 to MIME5].

MUA                   Messaging User Agent.

Relative URI          A URI that is defined relative to another.  See HTML 2
                      [HTML2] and RFC 1808[RELURL].

URI                   "Uniform Resource Indicator", a generalized way to
                      refer to a resource.  See RFC 1866 [HTML2].

URL                   "Uniform Resource Locator", a form of URI that points
                      directly to a resource.  See RFC 1738 [URL].


2) Section 3 "Overview", small language change (awkward):
was:
resources for non-IP connected clients. Also with other
protocols such as HTTP or FTP, may sometimes be a need to retrieve aggregate
documents. Receiving agents also have several differing needs. Some

new:
resources for non-IP connected clients. In addition other
protocols such as HTTP or FTP may sometimes need to retrieve aggregate
documents. Receiving agents also have several differing needs. Some

3) Section 4.1. We should be more inclusive of other URI forms. I think  it
is a mistake to decorate a potentially long living standards document with
too much language like "at present". there is no reason why the
Content-Location mechanism shouldn't work easily for URNs or any other type
of URI today (It is just a string matching).

Was:

At present only those URIs which are URLs are affected by these
headers, but it is anticipated that in future other forms of URIs maybe
affected.

New:
These headers apply to all forms of URIs including URLs, URNs and anything
else which follows the general URI syntax.

4) Also in section 4.1. First of all, there is no construct "URI", just
"absoluteURI" and "relativeURI" (the text after the grammar uses the term
URI). Second, do we need to be specific about distingishing between URLs and
the general URI syntax in this case (similar to above). I do think that
Relative URIs are not necessarily defined, maybe we should stick to
"RelativeURLs". The only catch is that I'm not sure what we can reference
for URIs in general, I assume this is why the current spec only references
URLs. I will do some research & follow up more on this.

Was:
    content-location = "Content-Location:"
                       ( absoluteURI | relativeURI )
    content-base = "Content-Base:" absoluteURI
where URI is restricted to the syntax for URLs as defined in Uniform
Resource Locators [URL] until IETF specifies other kinds of URIs.

New:
    content-location = "Content-Location:"
                       ( absoluteURI | relativeURL)
    content-base = "Content-Base:" absoluteURI
where absoluteURI is defined by xxx and relativeURL is defined by [RELURL].


5) Small typo, beginning of 4.2.

Was:
An The Content-Location header can be used to indicate that the data

New:
A Content-Location header can be used to indicate that the data

6) Small typo, 4.2:
was
relative URIs). However, URI-s in Content-Location headers (if

new:
relative URIs). However, URIs in Content-Location headers (if

7) i would remove this sentence. We just said about that the URIs SHOULD be
globally unique (which implies that they don't have to be although
non-unique ones can cause problems).

was:
a fictitious URI. Such an URI need not be globally unique.
new:
a fictitious URI.

8) I still think we should support multiple content-location headers. I
assume this is a good thing to talk about in DC, so I won't submit change
text for this right now.

9) Section 4.3, language edit:

Was:
Example showing which Content-Base is valid where:

New:
Example showing correct scoping of Content-Base:

10) Section 4.3. I think we might even want to conside taking this example
out/moving it to section 8. I don't like to see so much text in an example,
and in fact the text in this example is the first introduction to many of
these rules in the spec. If we keep the example we should add a Content-Base
to the multipart.

11) 4.4.1. I thought URIs don't have a charset? Research this.
With method (b), the charset parameter value "US-ASCII" SHOULD be used

12) Section 5, typo:

Was:

(d) Step (b) and (c) can be repeated recursively to find a suitable
    Content-Base or Content-Location header in a surrounding multi-part

New;

(d) Step (b) and (c) can be repeated recursively to find a suitable
    Content-Base or Content-Location header in a surrounding multipart

13) Section 8 (skipping ahead since it is referenced at the end of section
5). This whole section concerns me, since it becomes unclear where the
normative text is. For example, at the end of section 5, the following line
occurs. I think this line should be deleted anyway. I'm not sure what we
should do about section 8 since it provides useful text. We could either (a)
leave it, (b) merge it into other sections or (c) delete it.

This is also described in other words in section 8.2 below.

14) Section 6, language edit:

Was:
recipients. This is because not all e-mail recipients have full
internet connectivity, or because URIs which work for a sender will not
work for a recipient. This occurs, for example, when an URI refers to a
resource within a company-internal network that is not accessible from
outside the company.

New:
recipients. This is because not all e-mail recipients have full
internet connectivity, and because URIs which work for a sender may not
work for a given recipient. This can occur, for example, when an URI refers
to a
resource within a company-internal network that is not accessible from
outside the company.

15) Section 7, spelling:
Was:
Implementors are warned, however, that some receiving agents treat
New:
Implementers are warned, however, that some receiving agents treat

16) Section 7. I'm not sure I see how rewriting a document could fix issues
with URIs that the sending MUA is unaware of (I assume this is the problem).
I think this paragraph should be deleted or else replaced with something
just saying "Issues associated with this are discussed in more detail in the
Informational RFC..."

In certain cases this will not work - for example, if a resource
contains URIs as parameters to objects and applets. In such a case, it
might be better to rewrite the document before sending it. This problem
is discussed in more detail in the informational RFC which will be
published as a supplement to this standard.

17) Section 7. This language is insufficiently precise. Content-IDs MUST be
globally unique.

Was:
Within a multipart/related structure, each body part MUST have, if
assigned, a different Content-ID header value and a Content-Location
header values which resolves to a different URI.

New:
If a Content-ID header value is assigned to a body part, it MUST be globally
unique. The Content-Location header MUST be unique within its enclosing
multipart/related structure.

18) Section 8. Language, consistent capitalization. Also I removed
obsolete/depricated tags (including APPLET which may be contraversial since
it is widely used, however technically it has been depricated in the HTML
recomendation).
Was:
the ongoing development of HTML (examples: APPLET, FRAME, PROFILE,OBJECT,
CLASSID, CODEBASE, DATA, SCRIPT). A sender might also want to
send a set of HTML documents which the reader can traverse, and which
are related with the attribute href of the A element.

New:
the ongoing development of HTML (examples: FRAME, OBJECT, CITE, CLASSID,
CODEBASE, DATA, SCRIPT). A sender might also want to
send a set of HTML documents which the reader can traverse, and which
are related with the HREF attribute of the A element.

Thats it for now, I'm not quite done re-reviewing the spec, but I'll try to
finish asap.

Alex

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