A proposal for a new protocol

 
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.

Received on Wednesday, 5 March 1997 16:28:24 UTC