[Nsi-wg] NSI endpoint references

John MacAuley john.macauley at surfnet.nl
Sat Mar 12 19:42:45 CST 2011


On 2011-03-10, at 11:16 AM, Jerry Sobieski wrote:

> If someone thinks we need a URN specification for version 1.0, please pipe up and
> provide the reasoning - there may be such, I just am unaware of one in my mind at
> this moment.  (But please don't tell me its needed for web services-WS is not why we
> created NSI:-).  Adding a URN prefix qualifies the namespace - why does/should NSI
> need a qualified namespace for endpoint references?  If you think we do, or even if
> you think it is just a good idea, please explain how this reconciles with the NSI
> architecture - i.e. how the URN version maps the <network><endpoint> tuple, and
> how it improves the basic GID mentioned above?   Remember, we are only speaking
> to NSI endpoint references,...

Jerry,

It makes me giggle just imagining you in front of our computer having a seizure every time you think of web services.  Just to make sure we are clear on definitions, URNs are not specifically associated with web services, and in fact, have little to do with web services.  Here is the introduction from RFC2141 that defines the URN:

Uniform Resource Names (URNs) are intended to serve as persistent location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. Therefore, the URN syntax provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc.

By definition it is exactly what you have been asking for with physical location independent naming.  Whether you are using web services or some other binary protocol, a URN is just a syntax for identification and naming.  This mechanism has been chosen for use by the GLIF, perfSONAR, and the NML group.

Now, a URN also qualifies as an instance of a URI similar to how a URL is also an instance of a URI.  Perhaps this is why you may have confused it with  web services?

Personally, I do not like to be wishy washy with types when defining protocols.  Stating that an endpoint mush be from a URN namespace, or more specifically, the OGF URN namespace, will give more clarity in the protocol definition, and bind the protocol definition to other OGF specifications.  I would probably define a compound type as follows (I use XML schema since I know it well):

   <xsd:complexType name="StpType">
      <xsd:sequence>
         <xsd:element name="domain" type="xsd:anyURI" />
         <xsd:element name="endpoint" type="xsd:anyURI" />
      </xsd:sequence>
   </xsd:complexType>

However, I am not going to argue is people think it should be two strings instead of two URN.

John.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110312/b1895c77/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1791 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110312/b1895c77/attachment.bin 


More information about the nsi-wg mailing list