More interesting is the idea of a URL that's actively visible to MIME. A
specification for this is already in the works under the auspices of the
MAILEXT working group -- I'm the author of this. It extends the
MIME external-body mechanism to cover URLs.
Even more interesting than this is the idea of being able to sign the content
of the URL in a message, so that people know they're retreiving the right
thing. And it turns out that once the URL access-type is in place this
capability simply falls out of existing mechanisms -- a content-md5 header
can
be used to provide a checksum of the content of the URL within the context of
a signed message.
Its also possible to use either security multiparts or S/MIME to sign or
encrypt the content a given URL points at.
Ned, you and I had some dialogue along these lines four or five months ago. At
the time, I was working on a proposal for the Army for battlefield
communications of multimedia objects, where there is insufficient bandwidth to
accommodate the traditional "push" type of e-mail architecture. I think we
convinced the Army that they needed something like the multipart/alternatives
capability to specify a URL to a high-res, full color map, a medium res
version of the same thing without all of low-level details, and a bit mapped
low-res thumbnail sketch. Then, depending on the bandwidth and priority
available at the moment, the user can download the portion of the informaiton
that is most relevent.
A similar concern has popped up in the Cellular Digital Packet Data (CDPD)
world, where the user gets charged by the packet for the information that is
either send or received. If an unknowing correspondent sends the CDPD user a
simple mail message asking for an opinion and includes a 400K spreadsheet, the
charges could be ruinous. The more reasonable strategy is to communicate the
short, urgent portion of the message, and let the user retrieve the details
once he gets back to his hotel room or wherever.
And in the ietf-pkix forum as well as the Information Security committee of
the American Bar Association, I have been trying to whip up some enthusiasm
for including a URL to the Certification Authority's on-line policy document
within the certificate that is issued by the CA, together with a message
digest of the policy, since an OID is not necessarily sufficient to capture
any subtle changes in the policy.
In all of these cases, it is important to tie down the URL to a specific
document by including a message digest of the external body part within the
signed message or certificate. Since the originator of the document could
easily replace it with another version which was also signed at about the same
time, not having the message digest tied to the URL means that the recipient
can easily be spoofed by a replaced version.
I hate to confess my almost appalling ignorance of the details of URL formats,
HTML tags, and all of the rest of the web paraphenalia, but I sure would like
to see someone come up with a good STANDARDIZED way to solve this problem.
(I'd really prefer an X.500 solution, where instead of a URL there would be a
distinguished name of the document. That way, when someone decides to take
down one file server and move all of the document somewhere else, users
wouldn't be left with a bunch of useless, dangling URLs. But I'm not holding
my breath.)
Bob
Robert R. Jueneman
GTE Laboratories
1-617-466-2820 Office
1-508-264-0485 Telecommuting