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

From: Radia Perlman <[email-masked]>
Date: Fri, 22 Mar 2013 20:08:43 -0700

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document proposes to standardize the use of "example" as a namespace
identifier in URNs (like "example.com" is for DNS names), and is harmless.

I could (and perhaps should, or is it SHOULD) stop there.  However, I'll
editorialize a bit.  I more or less understand what a URL is.  You type it
into a browser, though mercifully, actual humans seldom have to type
https://www.example.com/extrastuff/whatever/934573895838.

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.

The definition given in RFC 2141 is "Uniform Resource Names (URNs) are
intended to serve as persistent, location-independent, resource identifiers
and are designed to make it easy to map other namespaces (which share the
properties of URNs) into URN-space."

I could memorize that definition and it still wouldn't help me understand
why my life was incomplete without URNs. Then I read RFC 1630 to find out
about URIs, and that was equally non-illuminating to me, who was simply
groping for "why do I need one of these things, and when would I use it".

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?

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?

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

Radia

---

From: Barry Leiba <[email-masked]>
Date: Sat, 23 Mar 2013 10:53:03 -0400

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 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.

> "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).

> 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.

> 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