xanadu://path or http://xanadu-path (RE: "xurl?)

[____Textpert Alert____ <ianf@xxxxxxxxx>]

Writes Steve James <sjames@xxxxxxxxxxxxxxx>

Ted>> But two of my collaborators, Roger Gregory and Sam Epstein,
Ted>>  think that transcopyright protocol should be recognizably
Ted>>  different at the top level, eg

Ted>>  xu://whatever@xxxxxxxxxx

> To put my $0.02 in, This seems reasonable.  

  To begin with taxonomy, that "top level" has a name, and it 
  is "scheme," rather than "protocol." The URL/URN/URI syntax
  decomposes into

scheme://path

  parts, all nicely explained in

http://www.w3.org/pub/www/doc/url-spec.txt  ; may have gone cold


  While instinctively agreeing with Tim Berners-Lee that transcopy-
  righted material could well be served using the HTTP protocol for
  the transport layer, but with proprietary negotiation, validation,
  fragment-assembly and billing mechanisms incorporated along the
  way (which need to be there no matter what transport methods have
  been chosen), I have come to realize that having a dedicated
  protocol called "xanadu," ie. having URIs begin with that word
  would offer clear advantage for the users and publishers alike.
  (URIs not URLs, because they won't be simple URLs anymore; see

http://www.w3.org/pub/www/doc/uri-spec.txt  ; may have gone cold)


  For one, no publisher could claim to have accidentially linked
  in a fragment for which his readers subsequently end up paying. 
  Since any seamless, transparent transcopyright mechanism also
  means that end-users lose a degree of control over what they are
  served, we need to ensure that there is ample room for filtering
  out potentially-unwanted bits, also based on any particular 
  scheme ALONE. 

  Once the WWW becomes a charge-by-the-byte medium, browsers will
  need to be able to recognize, and _filter out_ both the given 
  AND reg-expressed schemes, servers and documents (ie. a user
  instructs his browser to ignore all xanadu://xu.whitepower.com/*
  fragments, and can forget about ever seeing anything from there). 

  For the sake of this argument alone I assume that Xanadu-servers
  would be implemented as a superclass of HTTP-servers, ie. capable
  of dealing also with non-Xanadu browser requests, though perhaps
  only delivering some boilerplate text ("This 123456 byte long
  fragment of _What I Did On My Summer Vacation_ by A. Pupil can
  only be seen by Xanadu-capable browers.  Get one from [here]") 
  in lieu of the correct fragment in such cases. 

  Observe, however, that I advocate the scheme called "xanadu:", not
  "xu:", which is much more vacuous and ambiguous than that.  There
  already is a valid URL scheme called "prospero", so "xanadu" 
  wouldn't be out of place in such company. Ergo:

xanadu://xu.w3.org/hypertext/WWW/Xanadu.html#transcopyright


__Ian