Re: [Handle-info] Handle identifier and URN - what about the slash?

[Jakob Voss <jakob.voss@gbv.de>]

Tony Hammond wrote:

> Note also that since URIs use a subset of ASCII it is therefore not possible
> generally to form *any* handle-based URI (whether native or URN namespaced)
> without %-escaping. And since URN reserves the "/" char this MUST be
> %-escaped in URN-based handle URIs. So, URN-based handle URIs MUST be
> %-escaped, whereas native handle URIs MAY be %-escaped depending upon which
> chars are used within the handle suffix.

My conclusion is that if you want to use handle *and* URN you should
*always* specify and provide a strict and clear mapping from your
handles to a specific URN namespace. This mapping rule must mention how
the "/" will be encoded. The "default" mapping with %-escaping of
reserved and invalid characters  cannot assumed to be the default
mapping because people already used "/"  unencoded in URLs without
further specification, for instance in the DOI handbook.

> And because of the char reservations in URN (RFC 2141), the write-up in the
> DOI Handbook
> 
>     http://www.doi.org/factsheets/DOIIdentifierSpecs.html
> 
> is somewhat misleading. "urn:doi:10.1000/1" is not a valid URI per RFC 2141.

Well, RFC 2141 (URN) does claim "/" to be invalid it just states that
applications *should not* use it in unencoded form:

"The URN-WG has not yet debated the applicability and
precise semantics of those purposes as applied to URNs. Therefore,
these characters are RESERVED for future developments. Namespace
developers SHOULD NOT use these characters in unencoded form, but
rather use the appropriate %-encoding for each character."

In my opinion this is a perfect example of an imperfect standard - I
would not wonder if there already is some kind of Murphy's law:

Every part of a standard this is not specified strictly enough will be
interpreted in a way that was not intended by the authors of the standard.

Greetings,
Jakob



_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info