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

["Murray S. Kucherawy" <[e-mail]>]

Yes, that's my confusion, and your suggestion handles it nicely.  Thanks!


On Fri, Mar 29, 2013 at 9:03 PM, Peter Saint-Andre <[e-mail]>wrote:

> -----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-----
>