Subject: [apps-discuss] applicability of draft-ietf-appsawg-uri-scheme-reg-05.txt to URN namespaces and fragments

From: Larry Masinter <[email-masked]>
Date: Thu, 2 Apr 2015 00:26:31 +0000

> 3. Update of formal namespaces with ‘Expert Review’ - I agree with you

> that what draft-ietf-appsawg-uri-scheme-reg says has no impact on URN
> namespaces. However, I agree with Larry that a similar solution should
> (SHOULD ;-)) be used for URNs

There is the basic “should go without saying" constraint:
 you can’t delegate rights you don’t have yourself.

That’s to be reviewed the Expert Reviewer or whoever
is authorized to approve the parent registration.

Note, I don’t think 2141 disallows fragments, or that 2141bis should.

In fact, if fragments aren’t defined by the scheme, they shouldn’t
be disallowed either. It’s just that if you use a fragment with
‘mailto:’ it’s unlikely to work.

My problem with 2141bis is not that it allows fragments, but rather
it seems to want to delegate to urn namespaces the
ability to specify the interpretation of fragments.

Schemes don’t define fragment syntax OR semantics, so they
shouldn’t be allowed to delegate it.

As far as uri-scheme-reg is concerned, we might say something
about delegation. We should remove “New” from the title, as
the simplest edit to clarify applicability to updates.

I don’t think we need a ‘grandfather’ clause: a good reason
for breaking BCP35 guidelines would be “existing deployment”.
So previously registered schemes (like URN) don’t have to
follow a BCP35 rule if they didn’t before, or if there are
widely deployed implementations that don’t.

Larry
—
http://larry.masinter.net

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Apr 2015 03:29:50 -0400

--On Thursday, April 02, 2015 00:26 +0000 Larry Masinter
<[email-masked]> wrote:

>> 3. Update of formal namespaces with 'Expert Review' - I
>> agree with you
> 
>> that what draft-ietf-appsawg-uri-scheme-reg says has no
>> impact on URN namespaces. However, I agree with Larry that a
>> similar solution should (SHOULD ;-)) be used for URNs
> 
> There is the basic "should go without saying" constraint:
>  you can't delegate rights you don't have yourself.
> 
> That's to be reviewed the Expert Reviewer or whoever

I have lost track of what you are talking about and can't parse
the above non-sentence.  Sorry.

> Note, I don't think 2141 disallows fragments, or that
> 2141bis should.
> 
> In fact, if fragments aren't defined by the scheme, they
> shouldn't be disallowed either. It's just that if you use
> a fragment with 'mailto:' it's unlikely to work.

> My problem with 2141bis is not that it allows fragments, but
> rather it seems to want to delegate to urn namespaces the

>From the perspective of 2141bis (and the WG consensus decision
about using 3986's syntax but not its semantics), there is no
such thing as a fragment to allow or disallow.  There is only a
piece of 3986-conformant syntax that is introduced by a "#" and
and 2141bis calls, for convenience, an "f-component".    Perhaps
it should have been called, e.g., a "frigglefraggle" instead
because "f-component" reminds you of "fragment" too much, but
the whole point of using a different name for that piece of
syntax (relative to what 3986 uses) for an identical piece of
syntax was to reinforce the point that, the moment you start
talking about "fragments" and how they behave, are defined, or
how they interact with other things, you are outside the scope
and frame of reference of 2141bis.

If that doesn't work for you, your problem isn't really with
2141bis.  It is with the "syntax only" decision, a decision on
which Andy, as WG Chair at the time, made a consensus call and
told us to move on.

> Schemes don't define fragment syntax OR semantics, so they
> shouldn't be allowed to delegate it.

And that is an assertion that depends on 3986 semantics about
pieces of syntax.  See above.
 
> about delegation. We should remove "New" from the title, as

"New" has already been removed from the title.  It has not been
removed from many places it appears in the text so, if you think
its removal is important, you are co-author of a wildly
inconsistent document.
 
> I don't think we need a 'grandfather' clause: a good
> reason for breaking BCP35 guidelines would be "existing
> deployment". So previously registered schemes (like URN)
> don't have to follow a BCP35 rule if they didn't before,
> or if there are widely deployed implementations that don't.

That makes sense to me, but the document doesn't say "you can
break these guidelines if you have a good reason".  It says some
very specific things and we have had many incidents of people
turning protocol lawyers to block an outcome that they don't
like for altogether unrelated reasons.

     john