Hi, Many thanks for a nice short document!
I've a few questions though and suspect that a quick re-spin might be needed, but let's see what the wg think about 'em first. (1) Why Informational? Everything else at that level seems to be specified in a standards track or BCP level RFC, and IETF Consensus is required. [1] I think you have to do this as standards track. Did I miss something? [1] http://www.iana.org/assignments/params/params.xml (2) Do you *really* want RFC or specification required for all registrations? I don't care, but there is a trend away from that at the moment since its been found to discourage registrations in a lot of cases. Perhaps expert review would be ok? No trying to push you one way or the other, I just wanted to check. (3) If answer to (2) is yes: Section 5.1 says "Specification Required" but section 3 said "RFC Required" and those differ. For example, an OASIS spec would not be ok if you say RFC required. I don't know if you care, but you need to be consistent. (Or else I've misread something;-) (4) Isn't the template missing the reference to the RFC or other specification that defines the URN? (5) I don't get section 3, sorry;-) Can you give an example of a class:id pair that'd be registered? Asking IANA to generate the id part seems odd. nits: s3: s/generally referred/generally known/ s4: Might be worth pointing at the security considerations section of draft-ietf-oauth-v2? I'd say that text would be good to have read to know about the security considerations for the use of these URNs, before you go making one up. Cheers, Stephen. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
