[10665] in www-talk@info.cern.ch
A proposal for a new protocol
daemon@ATHENA.MIT.EDU (didier ph martin)
Wed Mar 5 16:42:36 1997
From: "didier ph martin" <dmartin@cedep.com>
To: <www-talk@w3.org>
Date: Wed, 5 Mar 1997 16:17:53 -0500
Resent-From: www-talk@w3.org
During the past months we have worked on an implementation of the MCF
language (ref:
http://mcf.research.apple.com/hs/mcf.html). However, instead of using URLs
identifier for units we used URNs. We looked at
several draft:
PATH URL: draft-ietf-uri-urn-path-01.txt
PURL
Handle
We found in these projects very interesting things, but we got a major
constraint. Independently of turf and religion wars (which
remind me of some dark ages) we have market constraints. Concretely, this
means that to implement name spaces (at the base of
URN), we have to deal with Novell NDS, Microsoft Active Directory, DNS on
some systems, the desktop name space and so
on... Even if we grabbed ideas from these previously mentioned projects, we
had, after more thought, to design a URN protocol
that would take into account this reality.
What is the procedure to propose a new protocol? At the same time, we want
to propose a modified MCF language proposal as
well as a new URN protocol.
Thanx for your help.
To get some immediate feedback from people that subscribe to this list.
Here is some info about the URN protocol.
We call it "tns" for transportable name service. The spirit behind this is
to create a Uniform Resource Name naming convention for
name spaces. It doesn't tell where are the objects, it just position them
into a hierarchical name space that you can represent as a
tree. Name servers implementing these name spaces have to keep a record of
attributes associated to this name. As you already
know there two kinds of name services (maybe more?) you give the name path
and you get a record or a field associated to this
name path. The other one being that you give an attribute and you receive
an object associated to that. This is the white vs yellow
pages thing.
The syntax for tns is as follow: tns://<name server>:<name path>
where <name server> could be something like dns:w3.org (the access protocol
for this name server is DNS) or nds:w3.org if
Novell directory service is used. If a local workstation support namesake
conventions: the wks protocol is then used. This means
that we are using a local name server resident on the workstation.
<name path> is a set of names separated by "/" like for example
"NameConvention/URN/OurProposal".
As an example: "tns://dns:w3.org/ NameConvention/URN/OurProposal" would
result on a query to a name server located at
W3.org and the path "NameConvention/URN/OurProposal" as a hierarchy of
names. the result can the be the associated URN's
record.
Used in a different context, a URN can be useful as well. The other context
we tested is the MCF context. In MCF, each object is
defined as a unit with an associated set of attributes. The syntax
described in the document
(http://mcf.research.apple.com/hs/mcf.html this is a real URL) states that
attributes (and a unit may be seen as an attribute) has
values associated to them. The syntax (only an idea not he complete specs)
is as follow:
<slot>:"<value>" (this only mention single value attributes, but he
language can support multi valued attributes or slots)
So if we use the tns protocol to uniquely identify an object, we then have:
unit:"tns://wks:Desktop/MyWork/NameConvention/URN/OurProposal/" (this
means that this object is part of a local workstation
name space)
location:"http://w3.org/specs.htm" (this is the location - be cautious,
these are not real URLs or URNs that are only examples)
subject: "new proposals"
author:"Didier PH Martin"
(the unit may have any number of attributes. Each interpreter just pick
what's useful).
So the "tns" protocol can be used in two (probably more) different
contexts:
to reach a name server particular name's record.
to uniquely identify a unit within a MCF document
To the original specs proposed by R.V Guha, we suggest a modification to
the value syntax. To each attribute is associated a value.
This value (or these values) are enclosed by a set of "". To unify the MCF
language with RFC 822 we propose that attributes'
values can be delimited by "" and by a space and a CTRLF. This way, a
e-mail header would be treated by a MCF interpreter.
Therefore a mail header could be treated as meta content (isn't that anyway
what it is?)
example:
to: www-talk@w3.org
subject: table of content
tocOf: the proposal
unit: tns://tns://wks:Desktop/MyWork/NameConvention/URN/OurProposal/
location: http://w3.org/specs.htm
author: Didier PH Martin
etc...
If you want to give some feed backs you can in this list if it is
appropriate (I don't know anymore what's appropriate and not we I
get invaded by religion Microsoft vs Non-Microsoft war messages).
or you can send me e-mail to dmartin@cedep.com
Didier PH Martin
Talva inc.
