An in that case you can request specific values or other such things in the registration template. One generally also provides a rationalization for that specific value or range as part of the request. This is similar to what I have done for the CBOR content-type registry requests in the COSE document.
The general idea is to discourage point squatting so that there is not a problem with having the same value in the registry used for two different things both of which are in the wild and then you need to figure out how to deal with it. One can also, if there is justification, request an early code point assignment in cases where it is known that implementations are waiting for the assignment to be made and need to get to market. I don’t know that any such need exists at this point, but the case might be made in the future for doing this. The point is, if you let IANA do its job then things will generally work more smoothly. From: COSE [mailto:[email protected]] On Behalf Of Mike Jones Sent: Sunday, July 31, 2016 2:37 PM To: Jim Schaad <[email protected]>; 'Justin Richer' <[email protected]>; 'cose' <[email protected]> Subject: Re: [COSE] Adoption of RSA and alternative algorithms Even so, given that we want specific identifiers to be allocated in specific numeric ranges, it seems less error-prone to include the suggested values to register in the specification. If there are actual conflicts at registration time, these suggested values would obviously be changed anyway. In my experience, both IANA and the RFC Editors are happiest when as much as possible is in final form when they begin to process the documents. Obviously either way would work. -- Mike From: COSE [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Sunday, July 31, 2016 1:34 PM To: Mike Jones <[email protected] <mailto:[email protected]> >; 'Justin Richer' <[email protected] <mailto:[email protected]> >; 'cose' <[email protected] <mailto:[email protected]> > Subject: Re: [COSE] Adoption of RSA and alternative algorithms You misunderstand the process. The RFC editor replaces the TBDs with the IANA assigned values just before Auth48 From: COSE [mailto:[email protected]] On Behalf Of Mike Jones Sent: Sunday, July 31, 2016 12:34 PM To: Jim Schaad <[email protected] <mailto:[email protected]> >; 'Justin Richer' <[email protected] <mailto:[email protected]> >; 'cose' <[email protected] <mailto:[email protected]> > Subject: Re: [COSE] Adoption of RSA and alternative algorithms The problem with this, unless I misunderstand the process, is that it will result in an RFC containing TBD# for the assignments, rather the actual numbers, which is less useful to developers. I think it would be better for the RFC to contain the assigned numbers. From: COSE [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Sunday, July 31, 2016 12:30 PM To: Mike Jones <[email protected] <mailto:[email protected]> >; 'Justin Richer' <[email protected] <mailto:[email protected]> >; 'cose' <[email protected] <mailto:[email protected]> > Subject: Re: [COSE] Adoption of RSA and alternative algorithms Or better, go through the normal IANA registration process to get them From: Mike Jones [mailto:[email protected]] Sent: Sunday, July 31, 2016 12:02 PM To: Jim Schaad <[email protected] <mailto:[email protected]> >; 'Justin Richer' <[email protected] <mailto:[email protected]> >; 'cose' <[email protected] <mailto:[email protected]> > Subject: RE: [COSE] Adoption of RSA and alternative algorithms Thanks for the info, Jim. Since the numeric assignments are wrong, the first thing to do for either draft would be to incorporate correct ones. -- Mike From: COSE [mailto:[email protected]] On Behalf Of Jim Schaad Sent: Sunday, July 31, 2016 11:58 AM To: Mike Jones <[email protected] <mailto:[email protected]> >; 'Justin Richer' <[email protected] <mailto:[email protected]> >; 'cose' <[email protected] <mailto:[email protected]> > Subject: Re: [COSE] Adoption of RSA and alternative algorithms From: COSE [mailto:[email protected]] On Behalf Of Mike Jones Sent: Sunday, July 31, 2016 11:27 AM To: Justin Richer <[email protected] <mailto:[email protected]> >; cose <[email protected] <mailto:[email protected]> > Subject: Re: [COSE] Adoption of RSA and alternative algorithms Responses inline… From: COSE [mailto:[email protected]] On Behalf Of Justin Richer Sent: Friday, July 29, 2016 7:04 AM To: cose <[email protected] <mailto:[email protected]> > Subject: [COSE] Adoption of RSA and alternative algorithms Hi all, hope that everyone is recovering from Berlin. As discussed in the meeting last week, the working group is considering additional work on RSA and other algorithms in the COSE messages framework. These would be published in a document separate from the core draft that is now on its journey to RFC-land. The chairs would like to gauge the sentiment of the working group on a number of items related to this proposed work. Please respond with your answers to the list. 1) Do you think it’s necessary or worthwhile to define RSA and other additional algorithms in the COSE messages framework? A) Yes, we should do an RSA/other-algs document B) No, we shouldn’t do an RSA/other-algs document C) Yes, but not right now D) I need more information (please ask what you want to know) E) I don’t give a flying rat whether this gets done or not A) Yes, we should do an RSA document now. These are needed now. Other algorithms can come later and be registered then. 2) If the work is adopted, where should it be done? A) Here in COSE (we’ll keep the group open for this item) B) In other working group (please specify where; note that ACE is a possible option) C) I need more information (ask what you want to know) D) I don’t give a flying rat where this happens A) Here in COSE (we’ll keep the group open for this item) 3) If the work is adopted, which draft is a good starting point? A) Jim’s draft: https://tools.ietf.org/html/draft-schaad-cose-alg-01 B) Mike’s draft: https://tools.ietf.org/html/draft-jones-cose-rsa-00 C) Some other draft (please tell us which one it is or offer to write it yourself) D) I need more information (ask what you want to know) E) I don’t give a flying rat which document we start with B) Mike’s draft: https://tools.ietf.org/html/draft-jones-cose-rsa-00 because it already has the numeric assignments in place and doesn’t have any other algorithms besides the RSA algorithms The numeric assignments are wrong as I have reordered the set of algorithms after the fork occurred. Jim We’re going to keep this thread open for two weeks at the AD’s request, and the chairs will try to make a consensus call at the end of that time period. Thank you, — Justin & Kepeng, your COSE chairs \. - - . ' _ , -`. ' _,' _,' ' ,-' _/ ' ,-' \ _/ ' ,' \ _' ' ' _\' ' , _,-' \ _________ \,_,--' \ \\_______\ <smb://_______/> \ \\+=+=+=+\ <smb://+=+=+=+/> \ \\=+=+=+=\ <smb://=+=+=+=/> \ \\+=+=+=+\ <smb://+=+=+=+/> \ \\=+=+=+=\________ \ \\+=+=+=+____----)) \ \`---------.)))\\ \ ||+=+=+=+=+=\\ /\\ \ ||___________\\/ \\ \ ||------------\\ ejm \|| \\
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
