IETF WG started - NOTARY

Hello,
in case some people missed this , I wanted to remind you:

- A new IETF working group has been formed, called NOTARY, to start tackling
  the problems of delivery notifications in the Internet Mail community
- Its mailing list is notifications <at> cs.utk.edu; E-mail to
  notifications-request <at> cs.utk.edu to join.

I enclose the charter below.
I promise: I won't disturb those other lists again with postings abouth
this item!

                          Harald Tveit Alvestrand

Notifications and Acknowledgments Requirements (notary)
-------------------------------------------------------

 Chair(s):
     Harald Alvestrand  <Harald.T.Alvestrand <at> uninett.no>
     Ned Freed  <ned <at> innosoft.com>

 Applications Area Director(s)
     John Klensin  <Klensin <at> infoods.unu.edu>
     Erik Huizer  <Erik.Huizer <at> SURFnet.nl>

 Mailing lists:
     General Discussion:notifications <at> cs.utk.edu
     To Subscribe:      notifications-request <at> cs.utk.edu

Re: Comments on MIME/SGML

Daniel,

Thank you for your comments on my draft.  My travel schedule made it
impossible for me to unable to respond to your comments immediately; I
appologize for the delay.  I deal with your comment on the DTD and
prolog first and then address the correspondences and the content-type.

You point, that I confused DTD and prolog, is on the mark.  After
reviewing your comments and 8879 I agree that the distinction must be
made and I propose a solution slightly different than the one you
propose.

The essence of my proposal is to replace the "dtd" parameter with "prolog"
and to require both prolog and instance.  The reason I suggest this
approach is practical, various implementations treat these two document
elements differently.  Having them as distinct body parts enables the
unpacker to present them to the SGML application in whatever form is
needed.  Thus the example you gave

> <!DOCTYPE T SYSTEM "t.dtd" [
> <!ENTITY fig1 SYSTEM "foo.ps" postscript>
> ]>
> <T>blah blah blah <figure graphic=fig1> blah blah blah</T>

I propose to split into two parts, the prolog:
	<!DOCTYPE T SYSTEM "t.dtd" [
	<!ENTITY fig1 SYSTEM "foo.ps" postscript>
	]>
and the instance:
	<T>blah blah blah <figure graphic=fig1> blah blah blah</T>

Re: Comments on MIME/SGML

Tim,

Your suggestion to use URIs in the Content-IDs is quite appropriate. 
I did not use your
suggestion, which I acknowledge you made earlier and to which I did
not respond, for two reasons.  First, it is important for me to have
the entire document self contained; second, I am unable to point to
URIs through an Internet standard, unfortunately we haven't gotten
there yet.

Is there any reason, however, that someone cannot use a URI in the
Content-ID.  What language would you suggest that would open up the
usage to your proposal.  From my point of view, URIs are useful.  Another
way I think they can be used is as a Message/External-body.  That way
is more general and URIs are available beyond SGML.  Is there a proposal
for doing that?

Thanks.../Ed

repl: bad addresses:
	distribution. <at> dimacs.rutgers.edu; (see end of body) -- no colon found to terminate route (;)
> 
> 
> Dan,
> 
> >    1. We make the following correspondence between the terms of the SGML
> >    standard and the MIME RFC:
>     
> 
> ....

Re: Comments on MIME/SGML

Daniel,

Thank you for your comments on my draft.  My travel schedule made it
impossible for me to unable to respond to your comments immediately; I
appologize for the delay.  I deal with your comment on the DTD and
prolog first and then address the correspondences and the content-type.

You point, that I confused DTD and prolog, is on the mark.  After
reviewing your comments and 8879 I agree that the distinction must be
made and I propose a solution slightly different than the one you
propose.

The essence of my proposal is to replace the "dtd" parameter with "prolog"
and to require both prolog and instance.  The reason I suggest this
approach is practical, various implementations treat these two document
elements differently.  Having them as distinct body parts enables the
unpacker to present them to the SGML application in whatever form is
needed.  Thus the example you gave

> <!DOCTYPE T SYSTEM "t.dtd" [
> <!ENTITY fig1 SYSTEM "foo.ps" postscript>
> ]>
> <T>blah blah blah <figure graphic=fig1> blah blah blah</T>

I propose to split into two parts, the prolog:
	<!DOCTYPE T SYSTEM "t.dtd" [
	<!ENTITY fig1 SYSTEM "foo.ps" postscript>
	]>
and the instance:
	<T>blah blah blah <figure graphic=fig1> blah blah blah</T>

Re: Comments on MIME/SGML

In message <9403072210.AA02671 <at> Accurate.COM>, Ed Levinson writes:
>
>The essence of my proposal is to replace the "dtd" parameter with "prolog"
>and to require both prolog and instance.  The reason I suggest this
>approach is practical, various implementations treat these two document
>elements differently.

Hmmm... my reasons were chiefly practial too; they were based on
experience with the SGMLs package. Could you give some background (or
pointers to materials I should read) about these "various
implementations" that treat the prologue and the instance differently?

>As to using text/sgml or application/sgml, I chose application to keep
>within expressed boundaries others in the MIME community have
>suggested.  Namely, that text be reserved for very simple things.

Formally speaking, it's a coin toss. I agree we should go with
whatever precedents are out there. application/sgml is fine. I just
don't like it when MH uses base64 encoding on my html body parts when
I know most of my audience can read html source -- perhaps I just need
to learn to use my tools better.

>The correspondences you provided I like, it may be easier to explain
>waht is happening using your table.  I summarize it, with my own
>suggestions, below.
>
>Do you find my proposal acceptable?

It's acceptable, but I'm not sure it's optimal yet.
Let's take another whack at the SGML->MIME correspondence:

Re: Comments on MIME/SGML

Ed, Dan,
I just wanted to add a few comments on the SGML part.
The term "notation type" is indeed not defined.  You have found data
content notation which is usually called "notation" in the SGML world.
A data content notation always has an external identifier associated
with it (4.213).
The term "data entity" is defined in the standard in 4.75.1.

	4.75.1 data entity: An entity that was declared to be data and
		therefore is not parsed when referenced.
	NOTE: There are three kinds: character data entity, specific
		character data entity and non-SGML data entity.

The data content notation for an external data entity is specified in
the entity declaration as you mentioned.

It is false to say you cannot split the prolog and the instance across 
several entities (note that I did not write SGML entities).  For example
you can have a Document Type Definition split across different files.
Here is an example:
	<!DOCTYPE foo [
	<!ENTITY % part1 SYSTEM "part1.dtd" >
	<!ENTITY % part2 SYSTEM "part2.dtd" >
	<!ENTITY % part3 SYSTEM "part3.dtd" >
	%part1;
	%part2;
	%part3;
	]>
Here the declaration subset contains three external parameter entity
declarations and then these parameter entities are referenced so that

Re: Comments on MIME/SGML

>>As to using text/sgml or application/sgml, I chose application to keep
>>within expressed boundaries others in the MIME community have
>>suggested.  Namely, that text be reserved for very simple things.
>
>Formally speaking, it's a coin toss.

Representing (I believe) lots of relatively unsophisticated users, I'd like
to push for keeping text reserved for only the very simple things, please.

Re: Comments on MIME/SGML

Jim Conklin writes (on text/sgml vs application/sgml)...

> Representing (I believe) lots of relatively unsophisticated users, I'd like
> to push for keeping text reserved for only the very simple things, please.

The other thing that top-level types are used for is gateways that have to do
translation.  text/* types will probably be translated for readability by
humans instead of by machines -- so the charset might be translated even if it
involves some loss of information, and a content-transfer-encoding of 8bit
might be converted to quoted-printable instead of base64, even though the
latter encoding is probably "safer".   The goal is to make it readable
according to the conventions for "text" in the destination environment.

Body parts of type application/*, on the other hand, probably aren't useful
unless you (a) have the right application and (b) have all of the bits intact.
So gateways are more likely to preserve such information for these types,
rather than translate it to something.

I believe the latter behavior is more likely to be appropriate for SGML
documents.

Keith

Re: Comments on MIME/SGML

In message <9403091410.AA02575 <at> cln49ib.der.edf.fr>, Christophe ESPERT writes:
>Ed, Dan,
>I just wanted to add a few comments on the SGML part.
[...]
>It is false to say you cannot split the prolog and the instance across 
>several entities (note that I did not write SGML entities).  For example
>you can have a Document Type Definition split across different files.
>Here is an example:
>	<!DOCTYPE foo [
>	<!ENTITY % part1 SYSTEM "part1.dtd" >
>	<!ENTITY % part2 SYSTEM "part2.dtd" >
>	<!ENTITY % part3 SYSTEM "part3.dtd" >
>	%part1;
>	%part2;
>	%part3;
>	]>
>Here the declaration subset contains three external parameter entity
>declarations and then these parameter entities are referenced so that
>they are actually expanded to make up the DTD.

This is a different issue. Yes, different parts of the prologue and
different parts of the instance can reside in various entities, but
there is always a single entity -- the SGML document entity -- that
contains the prologue and the instance either directly or through
references to other entities. Hence the example you gave is
not an SGML document entity -- there's no instance.

>In conclusion I would say that what you need in order to build your
>MIME data stream is to be able to get the entity structure of an

Re: Comments on MIME/SGML

Dan,
I agree with you that the example I gave is not an SGML document entity.
But I wrote before that the Document Type Definition may be split across
several entities.  Let's add the document instance set to the example:
	<!DOCTYPE foo [
	<!ENTITY % part1 SYSTEM "part1.dtd" >
	<!ENTITY % part2 SYSTEM "part2.dtd" >
	<!ENTITY % part3 SYSTEM "part3.dtd" >
	%part1;
	%part2;
	%part3;
	]>
	<foo><!-- Let's say the instance set is made of a few characters
	to make it simple. -->Blablabla</foo>
This example was very simple.  As you may know the HyTime standard has been
defined to be an "extension" of SGML.  HyTime addresses issues about
multi- and hypermedia documents.  As you can imagine these documents could
be extremely complex.  For instance in HyTime you can link two elements
belonging to different SGML documents.  In order to do that in a coherent
way, you have to consider the main document as the hub document and declare
the other documents that make up the hyperdocument as external entities.
I am sorry if it is not clear enough but what I want to point out is the
fact that the entity structure might be very intricate due to nesting,
Let's take a look at an example:
	<!DOCTYPE foo SYSTEM "foo.dtd" [
	<!ENTITY doc1 PUBLIC "-//Owner//DOCUMENT another doc//EN">
	<!ENTITY % special PUBLIC "-//Owner//ENTITIES Special char//EN">
	%special;
	]>
	<foo>.........<!-- I am lazy  -->