Subject: Change prefix? (was: Re: A word from the chair...)

From: "Martin J. Duerst" <[email-masked]>
Date: Thu, 1 Jun 2000 14:13:56 +0900

Hello Leslie,

I'm pretty much sure I haven't been able to read all the
messages on this topic, but it seemed to me that things
might get a lot easier if the prefix were changed from
urn:pin: to something like urn:nispin: or whatever.

I guess many people won't like that because it's not
enough 'urn-like', but any name that was a bit longer
than just 'pin', and would somehow not give the impression
that this was THE person identification number, would
be helpful.

Regards,   Martin.

At 00/05/30 23:12 -0400, Leslie Daigle wrote:
>Hi all,
>
>Putting my dusty WG chair hat back on... I think we've had some
>useful discussion airing perceptions of use of URNs/resolution.
>There may well be more issues to pursue here, so general discussion
>of the issues may continue.
>
>However, I'm not hearing a lot of people pushing back on/offering
>specific comments to the URN:PIN proposal.  If there aren't
>yells from new quarters, I will declare the issue closed, and
>when the revised URN:PIN Internet-Draft comes out, comments
>should be limited to the changes in the text (i.e., new issues).
>
>So, if you have a strong opinion either way, not yet aired, please
>do so or forever hold...  whatever you'd like to hold for a long time
>;-)
>
>Leslie.
>--
>
>-------------------------------------------------------------------
>"My body obeys Aristotelian laws of physics."
>    -- ThinkingCat
>
>Leslie Daigle
>[email-masked]
>-------------------------------------------------------------------

---

From: Michael Mealling <[email-masked]>
Date: Thu, 1 Jun 2000 10:39:35 -0400

> that this was THE person identification number, would

The question becomes this: is this a new policy? I.e. if
OCLC wanted to create a PURL URN namespace would we require
then to register it as oclc-purl?

If so then that sounds like vendor tree policy statement
that needs to be explicit. If it isn't then it sounds
very arbitrary....

-MM

--
--------------------------------------------------------------------------------
Michael Mealling        |      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions       |          www.lp.org          |  [email-masked]

---

From: "Stephen D. Williams" <[email-masked]>
Date: Thu, 1 Jun 2000 12:52:26 -0400

> that needs to be explicit. If it isn't then it sounds

It seems common sensical, not arbitrary at all.  The use of 'generic' namespace
names in a non-fully-public way is what seems arbitrary.

> -MM

sdw

--
Insta.com - Revolutionary E-Business Communication
[email-masked] Stephen D. Williams  Senior Consultant/Architect   http://sdw.st
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax  Jan2000

---

From: Michael Mealling <[email-masked]>
Date: Thu, 1 Jun 2000 13:38:27 -0400

On Thu, Jun 01, 2000 at 12:52:26PM -0400, Stephen D. Williams wrote:
> It seems common sensical, not arbitrary at all.  The use of 'generic'
> namespace names in a non-fully-public way is what seems arbitrary.

That may be your opinion but it isn't stated anywhere in the documents
or in any other IETF standard or stated policy....

-MM

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 Jun 2000 20:35:21 -0400

> or in any other IETF standard or stated policy....

I thought the idea here was persistent names.

If anyone can tell Michael for certain whether his business card will
have Network Solutions or VeriSign on it as the company name in six
months time they would be doing well. And folk want that name bound into
a URN supposedly persistent for a century...

Corporate names are simply not persistent. Attempting to build trees
is silly. I have just had to rework my homepage after bankboston
changed the url for their home banking service to homelink.fleet.com.

                Phill

---

From: Renato Iannella <[email-masked]>
Date: Fri, 2 Jun 2000 09:56:38 +1000

> or in any other IETF standard or stated policy....

This is true, however, RFC2611 states that Namespace IDs are
  "Assigned by IANA.  In some contexts, a particular one may be
  requested"

Network Solutions has requested "PIN" (which it has the right to do).
It is up to IANA to actually assign the NID.

Cheers...Renato                      <http://purl.net/net/renato>
Chief Scientist, IPR Systems Pty Ltd      <http://iprsystems.com>
...............................unlocking the value of information

---

From: Justin Couch <[email-masked]>
Date: Fri, 2 Jun 2000 08:15:29 +0800

> or in any other IETF standard or stated policy....

Good point. The standard approach of the IETF is protocols not policy so
I'm not sure if it is in our interests to state this.

I like the idea of the non-generic statement perhaps that can be a
"recommended practice" if at all possible. Problem is that it requires
policing by somebody which I don't think we want to do :)

--
Justin Couch                                   Author, Java Hacker
Snr Software Engineer                             [email-masked]
rbuzz.net                           http://www.vlc.com.au/~justin/
Java3D FAQ                                 http://www.j3d.org/faq/
-------------------------------------------------------------------
"Look through the lens, and the light breaks down into many lights.
 Turn it or move it, and a new set of arrangements appears... is it
 a single light or many lights, lights that one must know how to
 distinguish, recognise and appreciate? Is it one light with many
 frames or one frame for many lights?"      -Subcomandante Marcos
-------------------------------------------------------------------

---

From: Michael Mealling <[email-masked]>
Date: Thu, 1 Jun 2000 21:47:24 -0400

On Fri, Jun 02, 2000 at 10:09:25AM +0900, Martin J. Duerst wrote:
> Michael - Is it stated (IETF or somebody else relevant)
> policy that urn namespace names are given out to registrants
> on a first come, first serve base? If yes, can you tell me where?

I don't know if you'd call it "first come first served" but
it is fairly explicit in RFC 2611 Section 4.0 part III.
The document does say the NID is is assigned by IETF concensus.
But the point is that if the IETF concensus is that people won't
get the NID they ask for then there needs to be some reason why
other than "just cause" or else why even ask in the first place?

Also, if the concensus says that we don't get 'PIN' as the NID
we request then we will withdraw the document and the request
and wait until the process becomes a little bit more deterministic.

> If not, can you tell me why you implicitly assume
> this is the policy, or what policy you think applies?

Section III states that if you want a URN namespace with
a specific 'short' NID then you follow these steps:

submit a draft, get comments, edit it accordingly or
withdraw it, submit for RFC publication (any status),
and then you get your NID from the IANA.

> If no, this means that there is no policy for urn namespace
> names assignements, and that most probably means that somebody
> somehow has to create one.

Here's the relevant section to save you looking for it:

           III. Formal:  These are processed through an RFC review process.
           The RFC need not be standards-track.  The template defined in
           section 3.0 may be included as part of an RFC defining some
           other aspect of the namespace, or it may be put forward as an
           RFC in its own right.  The proposed template should be sent
           to the
                               [email-masked]

           mailing list to allow for a 2 week discussion period  for
           clarifying the expression of the registration information,
           before the IESG progresses the document to RFC status.
           A particular NID string is requested, and is assigned by IETF
           consensus (as defined in [RFC2434]), with the additional
           constraints that the NID string must
               - not be an already-registered NID
               - not start with "x-" (see Type I above)
               - not start with "urn-" (see Type II above)
               - not start with "XY-", where XY is any combination of 2
                 ASCII letters  (see NOTE, below)
               - be more than 2 letters long

-MM

---

From: "Martin J. Duerst" <[email-masked]>
Date: Fri, 2 Jun 2000 10:09:25 +0900

Michael - Is it stated (IETF or somebody else relevant)
policy that urn namespace names are given out to registrants
on a first come, first serve base? If yes, can you tell me
where? If not, can you tell me why you implicitly assume
this is the policy, or what policy you think applies?

Regards,  Martin.

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 1 Jun 2000 22:18:13 -0400

I appreciate the thought that has been put into expressing concerns,
and recognize that there are some real concerns and uncertainty here.

I can't say that some of the concerns expressed here won't turn
out to be true.

But I don't see WG work here.

I haven't heard consensus that the mechanical process (RFC2611) is
viewed as being fundamentally broken because it does admit URN:PIN.
We discussed these issues when we put together the process,
RFC2611 was the outcome, and I don't see new enlightenment now.
Passing judgement on every proposal, dismissing the ones from
proposers that are not trusted is not a process.  We can't build a
process that will admit only the things we all like.  We don't
(yet) have evidence that RFC2611 should be "fixed".

So, I suggest we move on.

Leslie.

--

Leslie Daigle
[email-masked]

---

From: Michael Mealling <[email-masked]>
Date: Thu, 1 Jun 2000 23:12:39 -0400

> It is up to IANA to actually assign the NID.

Actually, the IANA assigns whatever "IETF concensus" comes up with.
Now if the "IETF concensus" comes up with something other than
what we requested we will withdraw the request until the process
becomes a little bit more deterministic...

-MM

---

From: Keith Moore <[email-masked]>
Date: Fri, 2 Jun 2000 12:37:26 -0400

> other than "just cause" or else why even ask in the first place?

in other cases where IETF makes decisions by consensus, there only
needs to be a consensus on the decision itself.  there does not need
to be a consensus as to the reason why.

a concrete example is patent validity - when approving a specification
for proposed standard, or for advancement in grade, IETF itself will
not try to decide whether the patent is valid or whether it applies to
the specification.  however, any number of participants might decide that
the existence of that patent prevents them from implementing the specification,
or, alternatively, that the patent doesn't get in the way.   but even if
there is consensus about whether to adopt the spec, they don't have to
agree on why the spec should or should not be adopted.   for the example
of a spec which uses patented technology, some folks might believe that
they can license the technology at a reasonable price, others might believe
that the patent doesn't apply, others might believe that the patent is
easily invalidated by prior art, and the patent holder might support the
spec because he believes that he can make a hundred million bucks if it
gets approved.  but the outcome of the consensus process is either "yes"
or "no" (or a different spec).

at a distance, this might look like "just 'cause", even though the individuals'
decisions were more detailed than that.

Keith