All, I finally written or updated three documents: 1. Delegation of urn:ogf to the OGF 2. Procedure for registration of namespaces within urn:ogf 3. Specification of urn:ogf:network (also attached) All documents can be found in the repository at http://forge.ogf.org/svn/repos/urn-ogf-docs Only document #3 is in scope of the NML working group. I welcome feedback for all documents though. Delegation of urn:ogf to the OGF ================================ See http://tools.ietf.org/html/draft-dijkstra-urn-ogf Please sent comment to me off-list or to the urn-nid@ietf.org mailing list. Procedure for registration of namespaces within urn:ogf ======================================================= See http://forge.ogf.org/sf/go/artf6478 Please leave comments at this artifact or sent them to me off-list. Specification of urn:ogf:network ================================ See http://forge.gridforum.org/sf/go/doc16260 Please sent comments to the NML-WG mailing list or sent them to me off-list. I certainly appreciate feedback on the following two issues. Compatibility with GLIF and perfSONAR usage ------------------------------------------- The current syntax is compatible with both current usage, although it is now specified that recipients of a URN SHOULD NOT interpret the local part. This is a change from the existing use. Also, the document specifies that the following two URNs are NOT lexical equivalent. I have no opinion on this. Should this be equivalent or not? - urn:ogf:network:example.net:path:2011-0418 - urn:ogf:network:domain=example.net:path:2011-0418 International Characters ------------------------ No international characters are allowed. I actually worked out a solid schema (using RFC 5982 and NFKD normalisation that would allow quite a few code points, but still have a very simple URN comparison -- no decoding required.), but decided not to use it. I was finally convinced NOT to allow international characters by the following comments on the urn@ietf.org list: If you allow people to assign URNs as they prefer, they always tend to "invent" some semantic rules. At the end you have your database full of Identifiers like: [institution]-[division]-[collection-name]-[date]-[item-number] This goes fine many years. Till the day the collections are renamed or two divisions fusion under another name or renaming of the institution or ... Experiences like those are the reason why many colleagues with Long Term Archiving background propagate Identifiers without semantics --meaningless strings just for machines. IMHO that is the problem and not if those meaningful-names written in Kanji, Chinese, Arabic or Krill. Seriously I would allow ONLY numbers and 3-4 separator chars if I could define a new generation ID system. That is NOT "restrictive" but functional and problem free. (source: http://www.ietf.org/mail-archive/web/urn/current/msg01564.html) Regards, Freek