Re: [urn] Namespace and Community Considerations ... (in rfc3406bis -02 draft)

Alfred Hönes <> Sun, 25 March 2012 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A3DD21E801A for <>; Sun, 25 Mar 2012 13:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -98.613
X-Spam-Status: No, score=-98.613 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gxPcoYsgD6rc for <>; Sun, 25 Mar 2012 13:16:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AE4B421E8015 for <>; Sun, 25 Mar 2012 13:16:18 -0700 (PDT)
Received: from by w. with ESMTP ($Revision: $/16.3.2) id AA257586510; Sun, 25 Mar 2012 22:15:10 +0200
Received: (from ah@localhost) by (8.9.3 (PHNE_25183)/8.7.3) id WAA20420; Sun, 25 Mar 2012 22:15:08 +0200 (MESZ)
From: Alfred Hönes <>
Message-Id: <>
Date: Sun, 25 Mar 2012 22:15:07 +0200
In-Reply-To: <> from Leslie Daigle at Mar "25, " 2012 "08:58:32" am
X-Mailer: ELM [$Revision: $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Subject: Re: [urn] Namespace and Community Considerations ... (in rfc3406bis -02 draft)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Mar 2012 20:16:20 -0000

thanks for your review and comments.
I'll answer the various threads separately, slightly shortening
the Subject for convenience.

> Hi,
> Following up the editorial notes in the current draft (copied below for
> ease of reference[*]

For clarity to other readers on the list:
That's in Section 4.4.2 of the draft, and another, closely related
Editorial Note is present in Section 4.4.1 of the draft.

> First, to the question of the bulleted lists:  these were merely
> suggestions of dimensions in which a proposed namespace might differ
> from existing namespaces of similar syntactic structure.
> These 2 sections ("namespace" and "community" considerations) were meant
> to address the basic questions of "why do you need a new namespace
> anyway?" and "is your audience broad enough that this merits an
> Internet-wide identifier scheme?".


And every now and then, it's properties of the interested community
that impact the need for a new namespace; so registration documents
have been seen to need to explain the community aspects first
in order to discuss the first question.

> Mostly what I've seen is that registrants don't understand the
> questions, and first drafts often don't particularly address those
> questions.   [...]

That matches my observations.

>     [...]  That some of the registrations may duplicate text between
> their answers in each section is, I think, more a function of that
> than a reason to conflate the 2 into one section.

Maybe the situation is different for already well-established (e.g.
standards-based) "foreign" namespaces seeking integration into the
URN framework vs. for newly conceived conceptional namespaces that
are looking for the "proper" way to address the needs of their

> Perhaps a better path would be to more clearly articulate the
> question/section requirements in ways that will be compelling to
> people  who haven't been privvy to this sort of discussion.  (And,
> I'd send text, but it's my text that is clearly the problem ;-) ).

Well, we'd appreciate if years of experience might allow you to
anyway now suggest alternate text.   :-)

But I'm happy that you seem to agree that the original bulleted
lists might better be replaced by more elaborate explanations of
what should be provided, and that it is most essential that the
two primary questions you re-stated above are thought out and
answered convincingly in a registration document.

> [*]
>> [[ Editorial Note:
>>    It is acknowledged that, in many cases, the Namespace Considerations
>>    and Community Considerations are closely intertwined.  Further, the
>>    bulleted lists above (from RFC 3406) seems to be more related to the
>>    items in the registration template entitled "Identifier uniqueness
>>    considerations", "Identifier persistence considerations", "Process of
>>    identifier assignment", and "Process for identifier resolution" than
>>    to the primary objectives presented in the first paragraph above
>>    (also from RFC 3406).
>>    In fact, Namespace registration documents seen so far duplicate in
>>    the registration template material from the "Community
>>    Considerations" that addresses the above bullets.
>>    Therefore: Should this specification now allow a combined section
>>    "Namespace and Community Considerations" that focuses on the
>>    (non-)utility of possible alternate namespace re-use and the
>>    *benefits* of an independent new Namespace?
>>    ]]
> Leslie.
> --
> -------------------------------------------------------------------
> "Reality:
>       Yours to discover."
>                                  -- ThinkingCat
> Leslie Daigle
> -------------------------------------------------------------------
> _______________________________________________
> urn mailing list

Kind regards,
  Alfred Hönes.


| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:                     |