ietf-822
[Top] [All Lists]

Re: External reference

1991-12-13 04:11:27
Commenting on  ExternalBody/External (and a bit of its related things).

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

  Definitely a bad point.

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.

  Yes, one byte less is often well handled byte...

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

  Very least so.  Your proposal is a bit more generic (just a bit) (?)

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"

 There are now numerous systems which say "enter your email address as
the password".  How that should be encoded ?  password = email  (no quotes)
while all explicitic character strings should be quoted.

  There are also numerous systems which advertice FTP access with certain
userid & password.  Therefore the selection of specific character string
must be possible, while in some cases locally customized responces are
needed...

Also systems with some other than UNIX directory semantics will cause
you trouble.  Pick VMS (maybe easy one that..)  Pick VM/SP CMS!
        
 Content-Type: Application/ExternalBody-FTP;
     site = "ftp.nisc.sri.com",
     user = "anonymous",
     password = email,
     directory = "internet-drafts",
     name = "draft-ietf-822ext-messagebodies-02.txt",
     content-encoding = text,
     expiration = "unknown"

In CMS you can do CD  (and might need minidisk access password..)
while you can't refer to a directory, like in the UNIX.
A complete referral to a remote file isn't so easy thing at all :-(
(Ask FTAM people, or FTP Archive working group people, or comp.archive.admin..)

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

  Yes. Nice. (And occasionally mailservers will not tolerate random
subjects, but use  subject  as command...)

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?  

  It is a controversial subject.   Some sort of registration must be there,
or else network starts to profilerate with incompatible extensions.

Registration via IANA is a light-weight operation (compared to full RFC),
and therefore I would prefer it.  However, a time to time RFC generation
of single document, which binds together all IANA registered extensions
(subtypes), should happen.  (Less documents to browse to verify
compliance.)  ( And I hope that RFC-MIME will become self contained, and
therefore would not need RFC-822 as its complement..  Chapter 2 tells
your reasoning for present setup though. )

  A document which states "Supercedes documents ABC, 1234, 5678" is better
than one saying "Updates documents .." (my opinnion only of course)

  Well, how to update some subtype ?  (see above what I added)
How to note subtype version ?  Why I have a feeling of sticky mud about
this ? :-)

  I also have a "feature of the week" in mind - hypertext buttons;
but that shall wait until basic things work.
(Basic things for that is a referral mechanism to another sub-body in
 the message which contains application/whatever descriptions, and a bit
 richer richtext :-)  )

Greg V.

        /Matti Aarnio <mea(_at_)nic(_dot_)funet(_dot_)fi> 
<mea(_at_)utu(_dot_)fi>
                - FUNET network archive service
                - University of Turku, Computing Centre

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