> -----Original Message----- > From: Henry S. Thompson [mailto:[email protected]] > Sent: Tuesday, February 14, 2012 9:07 AM
> >> 11 It seems at best old-fashioned that the designer of a new access > >> token type, parameter, endpoint response type or extension error has > >> no better tool available than Google to help him/her discover whether > >> the name they have in mind is in use already. The same is true under > >> the proposed approach for any developer trying to determine what they > >> can use or must support. Is there some reason that mandated URI > >> templates, after the fashion of > > >> http://www.iana.org/assignments/media-types/text/ > > >> are not mandated for the registries, e.g. > > >> http://www.iana.org/assignments/access-token-types/bearer > > >> ? If there is a good reason, please use it to at least explicitly > >> acknowledge and justify the basis for failing to provide a way for > >> users and developers to use the "follow your nose" strategy > >> [1]. If there is no good reason, please include the appropriate > >> language to require something along the lines suggested above. If > >> you need a model, see [2]. > > > I'm confused - is this a request to use a full URI for all extension > > values? I thought the purpose of a registry was to deconflict the > > short names, and that URIs could be used for anything else. > > No, I appreciate that you want to use registered short names in the protocol, > that's just fine. My problem is that you have left users, developers etc. > with > no way to discover what shortnames have been registered short of a non- > trivial and error-prone informal search effort. > > What I'm asking for is support for probe URI prefixes for each family of > shortnames. So, just as today I use "text/n3" as the media type for my > Notation3 documents, I can check that this is a registered media type by > attempting to retrieve > > http://www.iana.org/assignments/media-types/text/n3 > > and I can see all the registered text types by retrieving from > > http://www.iana.org/assignments/media-types/text > > likewise I ought to be able to check e.g. the "bearer" token type by > attempting retrieval from (something along the lines of) > > http://www.iana.org/assignments/access-token-types/bearer > > and I should be able to see all the registered token types by retrieving from > > http://www.iana.org/assignments/access-token-types > > Hope this clarifies what I meant. > Not sure I understand what you are asking for, but what would the IANA instruction include to support this? EH _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
