On Fri, 2004-06-04 at 16:55, Ted Hardie wrote:
(Michael added to the cc list)
At 12:54 AM -0400 6/4/04, Andrew Newton wrote:
Plus, the BCP 81 (is that right?) registry does not allow
sub-registries. In other words, each URN must be registered. There
can be no registration for "every URN under marid:". This is how
Mr. Mealling has described it to me when this came up in GEOPRIV.
The issue is that the registry is mean to reflect names registered with
the IANA. So the issue is are you suggesting that there is structure
that the IANA must deal with or is your 'structure' opaque to anyone but
you, including the IANA.
The document says that the urns have the form:
urn:ietf:params:xml:<class>:<id>
but I had been working off the assumption that you could register URNs where
the ID had structure, provided you registered every ID. So the id
in urn:ietf:params:xml:ns:marid:m1 is "marid:m1"; the id in
urn:ietf:params:xml:ns:marid:m2 is "marid:m2". This isn't very
different from using urn:ietf:params:xml:ns:marid-1 and
urn:ietf:params:xml:ns:marid-2, except that you may be able
to shorten things on a slightly more regular basis when you are
in MARID context, and you may be able to have a slightly simpler
parser.
This is fine, but the issue is that the IANA is not going to have the
resources to deal with an increasingly complex namespace. If the
proposal is that "marid:m2" is an _opaque_ id and that the IANA can
safely ignore your naming convention, then I'm pretty sure the IANA
would be fine with that. But if you're suggesting that the IANA is going
to create a whole new registration subtree with directories and files to
maintain on their website, then that begins to create a burden that,
IMHO, isn't required.
The issue is that marid has chosen to re-use the ":" character for its
substructure. Since these are opaque identifiers anyway, why not just
pick another character so it won't confuse people who think it has
meaning because the earlier parts of the URN do (to a certain extent).
If the intent is that IDs can't have any structure, then this clearly
doesn't work, though.
The intent is that any structure is opaque to the IANA and its
responsibilities and processes. If you're application needs that part to
not be opaque, then that's your business....
-MM