Re: [apps-discuss] AppsDir review of draft-saintandre-urn-example

Peter Saint-Andre <stpeter@stpeter.im> Sat, 30 March 2013 04:03 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4060421F8D16; Fri, 29 Mar 2013 21:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkBjf31etQLM; Fri, 29 Mar 2013 21:03:42 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F17E21F8D12; Fri, 29 Mar 2013 21:03:42 -0700 (PDT)
Received: from [192.168.1.2] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 966E240D4A; Fri, 29 Mar 2013 22:13:11 -0600 (MDT)
Message-ID: <5156641B.70302@stpeter.im>
Date: Fri, 29 Mar 2013 22:03:39 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <CAL0qLwbEgtAVbY-DK3O_e3qcKXTHdJAgeC4P86VK5sK7Wn06sQ@mail.gmail.com>
In-Reply-To: <CAL0qLwbEgtAVbY-DK3O_e3qcKXTHdJAgeC4P86VK5sK7Wn06sQ@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: The IESG <iesg@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>, draft-saintandre-urn-example.all@tools.ietf.org
Subject: Re: [apps-discuss] AppsDir review of draft-saintandre-urn-example
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Mar 2013 04:03:43 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/29/13 8:57 PM, Murray S. Kucherawy wrote:
> I have been selected as the Applications Area Directorate
> (appsdir) reviewer for this draft.  (For background on appsdir,
> please see 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>
>  Please resolve these comments along with any other Last Call
> comments you may receive.  Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> Document: draft-saintandre-urn-example Title: A Uniform Resource
> Name (URN) Namespace for Examples Reviewer: Murray S. Kucherawy 
> Review Date: March 29, 2013 IETF Last Call Date: not known IESG
> Telechat Date: not known
> 
> Summary: This document is ready for publication as a BCP, modulo
> the minor point I bring up below.
> 
> Major Issues: None.
> 
> Minor Issues:
> 
> I understand that it's appropriate to do this; we have examples for
> other namespaces, so it makes sense to have one here too.  But I'm
> having trouble seeing how this will be used.  I'm willing to chalk
> it up to my unfamiliarity with URNs in general.  Citing your
> example in Section 4, doing something XMPP-related using this
> technique would mean "urn:example:xmpp:foo", but that's an
> example-space URN, not an XMPP URN. Wouldn't one rather register
> example namespace within the existing XMPP namespace for doing
> things like that?  I realize that would mean every existing URN
> namespace would have to go through this exercise, but it seems like
> it might be a better fit at least for the case mentioned above.

Ah, I see the source of confusion. We already have urn:xmpp, so what
I'm saying is don't generate urn:example:xmpp:foo as a way to avoid
dealing with the authority for urn:xmpp regarding issuance of
urn:xmpp:foo. You seem to be suggesting that each authority might want
to have its own namespace-specific example space so that folks in the
relevant community could generate things like urn:xmpp:example:foo. I
have no objections to such practices, but they're really out of scope
for this specification (it's not within the remit of this document to
recommend whether namespace authorities ought to have their own
particular example spaces). Does that make sense? Would it be
appropriate to add a sentence about that? For example, under Community
Considerations:

  Naturally, authorities for particular namespaces (say, the 'xmpp'
NID) might want
  to define their own sub-spaces for examples (say,
urn:xmpp:example:*); however,
  such policies are outside the scope of this document.

> Nits:

> In Section 1, you might also make reference to the RFC that
> reserves some of the IP address space for examples.  It might be
> RFC2606 or some other; apologies for not digging up the reference
> myself, but I'm sending this from a place with no net access.

Sure, that would be RFC 5737.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRVmQbAAoJEOoGpJErxa2pg/gQAI7M1qDwPaN53hvAJP/xjuxx
OH9trFQ1RaRBtrFCJL8oCPf2RDpGGE25KbbJakxprD88uP3G3dOBJ5ky4iI3uThm
7Rq7KYza+8NDk28lEJjX/nF1fdvDAK7dwhWQc+Uh+oNE7yQgnm4j0x3fla6mpixS
pm3FzoI2avazlasYRPGD0oyLa7ibn/DpSiCq3e6k0BLBg8o/nmekEfFG4e0txpBo
2W92yIC8pSROFHM3RBw71dF2fzy9OzA7sWmnsqFd/ACEmGeWFJOkLu5oywTyqjgj
CT/o4ghorvC7vTcmek/+YHbZoe8G1XhfHEDq+Uoo1vDswExIBXG9V3aoCes1RJr5
jm2/yC1CJ6oXLzlbWw1uR1sOu96eRxcf14T8st26q+9aXdN1GBifvJ7j4nBmfmMw
v4I9Jy5kLXYoreqvEVYrzep/D9fJslmsSiMxhWLE1wj/vIhTLv5IaCGLjsSW+nht
j/GIR8S5eEqW72vRoi++7llgmvUjOQp2emJg3KrRiv9x460RsQvSF7VwtqISZd4V
ZFwN0y0TlsTngJsCA8IAwi0ybeNttfhKWRSuAWIPtSraxn6z9+hB3/pwrt0tuMM1
xMHjj0bdo7OHt8IOTmzQz/mf0EGVzBFcx4WIZiQrv/+qZreNFRgtN+Mn/jeYCrIl
LMRtsT4S07I7JIoKI3Ch
=uhQE
-----END PGP SIGNATURE-----