Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

I disagree strongly.

A URI is any string that fits in the URI slot in existing protocols
and will continue to be so regardless of decisions made here.

We should redefine the syntax of URIs to be a label followed by a
colon followed by any sequence of non-whitespace characters.

URI = label ':' anything

label = [a-z, 1-9, A-Z] +
anything = [not-whitespace]*

That should give the URN world more than enough scope. All they need
to do is to make sure their URN encoding escapes significant
whitespace which is probably an essential success criteria in any
case.

The syntax I give is pretty much the definition of a URI used in
pretty much all code that attempts to turn text into hyperlinks that
is not limited to http and https.

On Mon, Apr 14, 2014 at 4:11 PM, John C Klensin <john-ietf@jck.com> wrote:
> Hi.
>
> It seems wise to call the attention of this broader group to
> something that is going on in URNBIS (and more generally).
> This message is a personal opinion.  It summarizes some
> discussions in and around that WG but is not an attempt to
> report on any sort of consensus.
>
> RFC 3986 on Generic URI Syntax was an attempt to create a
> general syntax (and, despite its title, partial semantics) for
> an extremely general set of resource identifiers, using
> experience with and developments from URLs as a starting point.
> The general URI concept was intended to including URLs, URNs,
> and possible future types.  That approach worked for URNs as
> long as they preserved the very narrow definitions and syntax of
> RFC 2141 but without taking advantage of any of the provisions
> for extensibility ("future use") in that specification.
>
> In the nearly 20 years since RFC 2141 was published, experience
> with URNs in various communities has demonstrated the need, with
> some URN types (NIDs), to be able to specify operations or
> retrieval of metadata as well as objects and for partial
> retrieval or other operations on either metadata of the objects
> themselves.  At the same time, there have been forceful
> discussions in information science, library, museum, and
> publisher communities about the fundamental differences between
> locators and names (which much of that community calls
> "identifiers", excluding locators from that category) and the
> disadvantages of mixing the two concepts.  That might be mostly
> a theoretical issue except that the URNBIS WG has found it
> impossible to define the functionality it needs while remaining
> within the syntax and semantic constraints of RFC 3986 (at least
> without creating obvious and very ugly kludges).
>
> The WG is now considering
> draft-ietf-urnbis-urns-are-not-uris-00, which proposes to
> separate URNs from RFC 3986, presumably leaving the latter with
> URLs and name-like things that are not URNs.   It may be worth
> noting that there is now work in W3C and WHATWG on a new URL
> definition.  The intent of that work includes eventually
> superceding 3986 (and 3987), at least for URLs, so there are
> multiple forces working to dismember RFC 3986.  However, the
> URNBIS draft is intended to narrowly focus on the needs of URNs,
> rather than trying to boil the URI ocean.
>
> Those who are interested in this topic should probably take a
> look at the draft and the discussions during the last week or so
> on the URN mailing list
> (http://www.ietf.org/mail-archive/web/urn/).   That list has
> been fairly low-volume, so looking at those messages should not
> be burdensome.  Discussion should also occur on that list unless
> there are very broad issues that belong here.
>
> thanks,
>    john
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
Website: http://hallambaker.com/