To: raisch@ora.com
In-Reply-To: raisch@ora.com's message of Wed, 21 Jul 1993 10:51:01 -0700 <93Jul21.105117pdt.2795@golden.parc.xerox.com>
Subject: Re: URLs for non-Internet networks?
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <93Jul21.111404pdt.2794@golden.parc.xerox.com>
Date: Wed, 21 Jul 1993 11:13:50 PDT
I was writing a paper and tried to give URLs for all of the references
that were available over the internet. The one thing I found that was
missing was something that exists in the MIME external-body types were
MAIL-SERVER access. I really do think it would be good to somehow
converge the SEMANTICS if not the FORMAT of MIME external-body
references and URLs.
MIME has FTP and ANON-FTP (same with URLs, although non-anon-FTP isn't
used widely). MIME has AFS but it didn't get added to the URL spec;
both MIME and URLs have LOCAL-FILE capability. MIME has TFTP, which
doesn't seem too interesting, while URLs have gopher and http.
As part of converging these, should we register HTTP and GOPHER as
valid MIME message/external-body types?
Is the 'name=' field the same as the string in URLs? Should we lobby
to extend MIME Message/External-Body to allow references to portions
of documents?
================================================================
Message/External-Body
indicates that the actual body data are not included, but
merely referenced. In this case, the parameters describe a
mechanism for accessing the external data.
When a body or body part is of type Message/External-Body,
it consists of a header, a blank line, and the message header
for the encapsulated message. If another blank line appears,
this ends the message header for the encapsulated message.
However, since the encapsulated message's body is itself
external, it does not appear in the area that follows. For
example, consider this message:
Content-type: message/external-body;
access-type=local-file;
name=/u/nsb/Me.gif
Content-type: image/gif
THIS IS NOT REALLY THE BODY!
The area at the end, which constitutes a phantom body, is
ignored for most external-body messages. However, it may be
used to contain auxiliary information for a
"mail-server".
The only parameter of Message/ExternalDBody that is always
mandatory is Access-Type. Its other parameters are mandatory
or optional depending on the value of Access-Type. The values
defined for the Access-Type parameter are FTP, ANON-FTP, TFTP,
AFS, LOCAL-FILE, and MAIL-SERVER. Except for values beginning
with X-, other values must be registered with IANA.
The standard also specifies additional parameters that are to
be used in conjunction with the various access types.
In addition to access-type specific parameters, the standard
defines the following parameters which are optional for all
access types:
* The Expiration parameter is used to specify a date after
which the existence of the external data is not
guaranteed.
* The Size parameter is used to specify the size of the
data.