ietf-822
[Top] [All Lists]

External reference

1991-12-10 14:07:14

Chair on....

Several issues were left unresolved in Santa Fe.  Now that the 
next to final version of the specification is out, comments on those
unfinished items is solicited.  The unresolved issues are

1) ExternalBody/External Reference syntax
2) Compression (transfer encoding or attribute)
3) Message Integrity Check
4) Internal Reference in Rich Text

I eagerly await proposed text for the compression and MIC.  

Chair off....

I would like to propose some changes to the external reference subtype
as currently specified in the document.  As specified, external-body
is a expandable, open ended mechanism for retreiving data from an
external source.  I think this is the wrong model for several reasons.

1) The mechanism for the use of parameters for general functional
extension is not as well defined as it is for content-sub-types. No
registration mechanism has been defined for attribute pairs.

2) I believe this functionality should be under Application rather
than Message.  I'm not sure why we need the overhead of an 822 message
just to include a pointer to say an external audio file.

3) The current syntax is unfriendly to old-style users. (Me! until my
systems guy installs a MIME system)

I'd prefer a sequence of sub-types which closely parallel existing
access mechanisms. Here is my cut by example rather than rigorous
definition.

Content-Type: Multipart/Alternative; boundary = "achoo"

--achoo
Content-Type: Application/ExternalBody-FTP;
    name = "internet-drafts/draft-ietf-822ext-messagebodies-02.txt",
    site = "ftp.nisc.sri.com",
    user = "anonymous",
    password = "guest",
    expiration = "unknown"

--achoo
Content-Type: Application/ExternalBody-MailServer;
   (The body of the content-type includes the message to send to get
   the body)
Content-ID: randomalphanumeric

To: mail-server(_at_)nisc(_dot_)sri(_dot_)com
Subject: MailRequest randomalphanumeric 
-------

SEND internet-drafts/draft-ietf-822ext-messagebodies-02.txt

--achoo--


When a new access method is defined, a new subtype is recorded with
IANA explaining how to use it.  I prefer this to the use of a new
attribute which is defined only by assumption of the parameters needed
by that method, or by a separate RFC.  I'd like to avoid the need to
begin registring attributes.

Comments?  

Greg V.




<Prev in Thread] Current Thread [Next in Thread>