This discussion is completely out of hand now. None of the discussion items being discussed below are properly addressed by the concise problem details document. If you want to change the way CBOR tags are registered, please write a draft and submit it to the CBOR WG. In Germany we have articles in the constitution that cannot be changed, even with a qualified majority. You seem to want to introduce such an article to an RFC, and that is unprecedented. If the IETF decides to deprecate Tag 38, that is the decision of the IETF. Of course it would not be bright to do this if there isn’t a clear replacement in sight. But writing text into this specification that the specification cannot be deprecated is the wrong way to go about this. Shouldn’t we add that text to TCP, too? Or anything else that we think is a great idea at the time of approving the document? Tag 35 is a good example because this is a tag that has turned out to be problematic, not providing the level of interoperability in practice that we thought it would in 2013. So we didn’t want to include it in RFC 8949, which is an Internet Standard (which is supposed to have interoperability throughout). But we didn’t want to “unregister” it either (shades of port 465). Tags are registered in the CBOR tags registry under “specification required”; we do have a stable specification in RFC 7049; so we were all set. If Tag 38 ever gets the same status that Tag 35 has, we have a good way to handle that. Do I think this is likely? Absolutely not. Should we try to cut off that possibility by unprecedented “this cannot be changed” text (which we can always ignore anyway)? No. Grüße, Carsten -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
