I concur.
RFC 3553 does say the "colon character (":") is used to denote a very
limited concept of hierarchy" and the current text in -04 uses the
colon consistent with that limited concept of hierarchy. However, as
Mike already said, the intent of
http://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns is that it be a
general naming convention and not something that need be part of the
registry.
On Sat, Jun 23, 2012 at 12:41 PM, Mike Jones
<[email protected]> wrote:
> I'd rather that we did the review based upon the current draft rather than
> rolling back.
>
> Hannes, my point about three levels was that we can't necessarily know up
> front what the structure of URNs would be that might make sense to register
> in the future. I was using that possibility as an example to object to a
> strict two-level hierarchy. Sometimes a one-level name may make sense as
> well.
>
> I agree with you that Section 3 of http://tools.ietf.org/html/rfc3553 says
> about the colon character (":") defines a lightweight syntax for hexarchies
> to use when they make sense. I just think it's overkill to put the hierarchy
> in the registry, per se.
>
> I agree that in http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions
> we should add IANA considerations text saying that any new extensions for
> client assertions should be registered with the name client-assertion-type:*.
> Likewise we should figure out the right place to say that new grant types
> should be registered as grant-type:*. These would be naming conventions
> though - not something that's a part of the registry.
>
> Cheers,
> -- Mike
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Hannes Tschofenig
> Sent: Saturday, June 23, 2012 8:17 AM
> To: OAuth WG
> Subject: [OAUTH-WG] OAuth URN Registry Discussion Summary
>
> As you have seen I have responded to various mails and I believe I understand
> what people want.
>
> Some of you obviously have plans to write extensions (in other organizations
> outside the IETF, and as vendor-specific extensions). That's fine.
>
> You want something really lightweight (in terms of process) that does not
> require you to come to the IETF to write an RFC and get the entire working
> group excited about your hobby project. Clearly, this makes sense to me.
>
> So, the policy for adding new extensions has to be either 'Specification
> Required' or 'Expert Review' with the difference being about the information
> that goes into the registry. For the cases I have seen on the list it will
> not make a huge difference. It may make a difference for an organization
> where their final specifications are not publically available. Yes, these
> organizations still exist today....
>
> Then, there is the question about how the identifier that gets registered
> should look like. You seem to like the idea of concept of a structured
> identifier (since otherwise you wouldn't be using it in various working group
> drafts already, including the example in draft-ietf-oauth-urn-sub-ns itself!)
> but you don't like to call it hierarchy because you fear that you will not be
> allowed to do whatever you want. An unjustified concern.
>
> In that sense version -03 of the draft (see
> http://tools.ietf.org/id/draft-ietf-oauth-urn-sub-ns-03.txt) pretty much does
> already everything you want already do. As a policy it says "Expert Review"
> and it has the structure in the ID that you guys are using in your current
> drafts!
>
> There are two options to go forward.
>
> The first one is to roll-back to version -03.
>
> Another option is to take version -04 and add text that explains the <id> a
> bit further by saying that it may contain a structure and other documents
> populating the registry will define the detailed structure of the <id> part.
>
> In http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ we would then
> add a section to the IANA consideration section saying that any new
> extensions for client assertions needs to be registered under
> urn:ietf:params:oauth:client-assertion-type:
>
> The same for urn:ietf:params:oauth:grant-type: in some other document and so
> on.
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
