Re: [secdir] secdir review of draft-saintandre-urn-example-04

[Barry Leiba <[e-mail]>]

Hi, Radia, and thanks for the review.

On the chance that you really do want some of your questions answered,
let me take a stab:

> But then I started hearing about URNs and URIs.  I pretty much ignored them
> because my life seemed to be complete without needing to understand them.
> But then since I was assigned this draft to review, I decided to investigate
> what URNs and URIs are and how they are different.

"URI" is an abstraction.  We have here a protocol (or a data format),
and in this spot in the protocol we want the client to send the server
something.  We're going to say that the something is a URI, which is
rather like saying that the something is a fruit.

Broadly speaking, we've divided URIs into two types: locators and
names.  A URL (locator) tells you where to find something and/or what
to do with it.  A URN (name) tells you what something is called.
Different sub-abstractions, like "fruit that needs to be peeled" and
"fruit that you can eat without peeling".

The first part of a URI is called a "scheme" -- it's the part that
looks like "http:" or "sip:" or "mailto:" or "urn:".  That's what
tells you how to interpret this particular URI; it's the concrete
instantiation of the abstraction -- the lemon or the apple.  When you
see a URI with the scheme "http:", you know you're meant to go look at
RFC 2616 to see how to process it, and you'll usually end up
contacting a server on port 80 and sending it certain stuff, expecting
certain stuff in response.  When you see "mailto:", you know you'll be
using SMTP (RFC 5321).

But names are different.  URIs with the "urn:" scheme are a type of
URN, and they're just meant to name things (but there are other URNs;
the "ni:" scheme, defined in
http://tools.ietf.org/html/draft-farrell-decade-ni , also defines
names, not locators).  There are documents that say how to map ISBNs
into URNs (RFC 3187), how to map serial numbers into URNs (RFC 3044),
and so on.  The URN just gives you a name, and it doesn't tell you
what to do with the name.

But they're still part of the abstract thing called a URI, and they're
syntactically valid where URIs are allowed.  Of course, specifications
can, and often do, limit the types of URIs that are semantically
appropriate in any particular spot in any particular protocol or
application.  A web browser probably knows how to deal with http: and
ftp: URIs.  Many can deal with mailto: URIs.  They're less likely to
know what to do with sip: URIs and probably won't do anything at all
useful with urn: URIs.  But because of the common syntax imposed by
the abstraction, the web browsers know how to start parsing the sip:
and urn: URIs, and, thus, know when to throw them out as unsupported
instantiations.

> Then I read yet another incomprehensible RFC, #3986, which has this
> sentence:
> "Future specifications and related documentation should use the general term
> "URI" rather than the more restrictive terms "URL" and "URN" [RFC3305]." So,
> why are we, today, in 2013, tweaking URNs if we are supposedly trying to
> mercifully put the term "URN" to bed?

What the text in 3986 (which needs updating, by the way, an update
which is on the radar, if not actually in the works yet) is trying to
get across is that in the general case, specifications should refer to
the abstraction, the URI.  But there certainly are times when, for
example, something specifically needs to be a name, a URN... and in
those cases it's perfectly sensible to use the term "URN".  Today, in
2013, we're still tweaking URNs because we still need resource names
(see the aforementioned draft-farrell-decade-ni, for example).

> And why is the NSS (Namespace Specific String, which is part of the URN)
> ASCII? Given that I'm never planning on using a URN, I don't really care,
> but if people wanted these things for whatever reason, mightn't they want to
> use International characters?

That's an artifact of history, and of the need to maintain
compatibility.  For better or worse (well, worse, surely) our
protocols and the implementations thereof were set up to expect only
ASCII character encoding.  We can and should move over to UTF-8, and
we are working on it, a few protocols at a time.  But look at the
difficulty the seven-year effort on EAI (email address
internationalization) has had, and you can see that it's not as simple
as suddenly saying, "OK, we can now send these protocol elements
encoded in UTF-8."

For URIs, specifically, much of the internationalization can be
handled by the encoding mechanisms specified in RFC 3986, and it's
working well.  The IRI (internationalized resource identifier) work
has tried to expand that, but there've been bumps in that road.  But
the bottom line is that URIs *can* use international characters, by
encoding them, and it's the job of the presentation layers to encode
the user input and to decode for display.

> So my conclusion is that invention of UR* terminology is a low level denial
> of service attack on people, but is otherwise harmless.

You won't hear much argument about that from me, indeed.  Though I'll
point out that that describes more of what we do than most of us would
like to admit.

Barry