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