ietf-822
[Top] [All Lists]

Re: Handling external refernces ; Multi-part/alternative ideas

1991-12-16 10:47:27
 
From: someone
To: someone else
Content-type: application/external

Content-type: application/postscript
Access-type: NFS; Name=/pub/read-only/some.ps
Access-type: FTP; host=east.filestore.org; user=anonymous; 
                  pass=email-retriever; name=some.ps
Access-type: FTP; host=west.filestore.org; user=anonymous;
                  pass=email-retriever; name=some.ps
Access-type:...

Dave,

I have several problems with this scheme.  1) It adds a layer of
dependency between content-??? headers that did not presently exist,
which will make things more compex, and 2) as pointed out John Wagner,
there is not a clear concept of hiearchy between the options. 3) This
proposal does not easily fit mail servers.  What If I offer two mail
servers with two different sets of commands.  How do Identify which
commands go with which server? (Assuming you would put the commands
in the body)

If we adopt Dave's proposal, We now need regester new access-type
content header fields also!  Please, keep to the current architecture
where extension is done simply by adding new content types.

On the issue of heararchy, things get complex.  It may be that it
really is up to the UA to determine the best match.  For example, at
ISI, I'd rather use the FTP.nisc.sri.com internet drafts archive, and
at Mitre, I'd prefer the local nic.ddn.mil archive.  Here on my local
site, I'd like people to just copy the file from the directory via NFS.

Multi-part/alternative does currently have a rule that you are to use
the "richest" version you can.  I'd like to see the rule generalized a
bit, adding some words to say, use the "best".  It is up to the user
and his/her UA to figure out in their context the "best".

So, what am I saying?  For the external body, I propose what I
originally sent.  This proposal was for use of multipart alternative
with specific subtypes for each retrieval mechanism like,
application/ftp-getter and application/mail-server.  (I don't care
anymore whether it is application/mail-server or message/mail-server).  

I would also make the following changes to the wording on multipart
alternative.  It currently reads (7.2.3)

         The multipart/alternative type is syntactically identical to
         multipart/mixed,   but  the  semantics  are  different.   In
         particular, each of the parts is an "alternative" version of
         the  same information.  User agents should generally display
         only the LAST part that  they  are  capable  of  displaying.
         This  may be used, for example, to send mail in a fancy text
         format in such  a  way  that  it  can  easily  be  displayed
         anywhere:
....
            In general, user agents that  compose  multipart/alternative
            messages  should place the body parts in increasing order of
            preference,  that  is,  with  the  preferred  format   last.
            Receviers  should  pick and display the last format they are
            capable  of  displaying.  In  the  case  where  one  of  the
            alternatives  is  itself  of  type  "multipart" and contains
            unrecognized sub-parts, the user agent may choose either  to
            show that alternative, an earlier alternative, or both.


I'd prefer the following:

         The multipart/alternative type is syntactically identical to
         multipart/mixed,   but  the  semantics  are  different.   In
         particular, each of the parts is an "alternative" version of
|         the same information.  User agents should recognise that the
|         content of the various parts are interchangable.  The user
|         agent should either choose the "best" type based on the
          users enviroment and preferences, or offer 
|         the user the available alternatives.
....

            In general, user agents that  compose  multipart/alternative
            messages  should place the body parts in increasing order of
            preference,  that  is,  with  the  preferred  format   last.
|            For fancy text, the sending UA should put the most
|            plain text first and the richer text later. Receiving 
|            UA's  should  pick and display the last format they are
|            capable  of  displaying.  In  the  case  where  one  of  the
            alternatives  is  itself  of  type  "multipart" and contains
            unrecognized sub-parts, the user agent may choose either  to
            show that alternative, an earlier alternative, or both.


How does this sound?

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