[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: xanadu@xxxxxxxxxxxxx
- Subject: Re: "xurl?
- From: william@xxxxxxxxxxxx (William C. Archibald)
- Date: Sat, 11 Nov 95 21:34:12 CST
- Cc: william@xxxxxxxxxxxx
- Reply-to: xanadu@xxxxxxxxxxxxx
> At what level should there be a protocol difference for
> transcopyrighted material?
> [ ... a number of interesting observations and arguments elided . . .]
I think it is valuable to recognize that there are several things
going on here:
A) Signification of 'Transcopyright'
B) Message Transport Layer
C) Role of URL/URN/URI
No one would argue that transcopyright is something that should and
arguably _must_ be differentiated somehow from other types of
material and services. Thus it is necessary to signify trancopyright.
HTTP though, is not just a "web thing" for html documents. It is a
transport layer for all sorts of (MIME) objects and data constructs
-- as are smtp, nntp, and to some degree ftp.
It is important to disengage in our minds the transport layer, the
content being transported (or not being transported), the visual
display of the content being transported, the rights associated
with the content being transported, and the way the content being
transported is paid for.
Why? Because treating each of these as orthogonal, and essentially
independent concepts allows each of them to evolve independently of
the others, and allows each of them to utilize advances in all of
the others when they occur.
URLs are a wonderful invention because they allow specification
of transport and a virtual or physical path to the document -- all
in one fell swoop. Surely there is an appropriate add-on to the URL
that doesn't require replacement of an entire message transport substrate.
Thus, I would argue that because 'xu' isn't a signifier of transport,
like http and ftp, but rather of transcopyright -- the URL should
in fact be something like:
or better yet tie it to the Content-type: application/xu, which
allows the best of all worlds:
Transport independence: mail, news, http
Security system independence: S/MIME, MOSS, STT, SSL, ...
Payment system independence: SEPP, STT, Digicash, SPaM, ...
And give you the ability to make strides on the things that are important:
namely the concept and deployment of transcopyright.
I remain, humbly,