Hi Ira, before we send our detailed response for his excellent comments to Martin, I would like to set an accent here. > I agree that a separate draft for CBOR language tags would be preferable, to > raise the visibility of internationalization in other RFCs and in other SDOs. Frankly, raising visibility for internationalization requirements is not our job here. Making sure that these requirements are addressed in our documents is, and a nice side effect is that more people will learn about them in the process. We saw that we have a protocol that is likely to often have at least one, but rarely two constrained nodes talk to each other (hence the extended validation potentials for less-constrained nodes — but not every node has to validate on the fly!). We wanted to use existing tag 38 for this, but noted the lack of the indication of a writing direction. This was fixed, at considerable peril of delaying the process. Tag 38 does not have the intention to take over all forms of human-readable strings; as we noted, expressing the additional data that need to go with a Unicode string *is* an active subject of discussion among the experts (*). (Our spec immediately triggered discussion on how to solve this in an even more general way, which is a great discussion the results of which we cannot wait for.) > I suggest that CORE or other IETF WGs specifically focused on constrained > devices are the wrong places to write and publish such a language tag RFC, > because CBOR is certainly *not* primarily for constrained devices anymore. It is true that tag 38 can be versatile enough to be used outside the constrained protocol space (i.e., communication that has to arrange for the possibility of at least one constrained peer). But that was not the intention of this draft. The intention was to create a concise problem details format, and in the process we noticed that we have to fix up registered tag 38 a bit, because some of the content of the problem details format is human-readable. > I would prefer to see the separate RFC developed in the CBOR WG. I’d prefer to get this document published! We accelerated the work on this to get it done within the 3GPP rhythm, and are grateful for a lot of feedback that allowed us to make this a better document really fast. Opening up a debate about life, the universe, and internationalization at this time is not going to help with that. Or, in other words: There is indeed a good argument for bottom-up projects that cover a certain problem statement (but which still should be driven by requirements of actual protocols!), but this is not one of them. > In many IETF WGs (RATS, SACM, TEEP, etc.) and many other SDOs, CBOR > is being heavily used for the entire spectrum of computing devices (especially > routers and switches for telecom networks and servers for enterprise networks). > CBOR is simply a better mousetrap, IMO. I certainly agree with that. And I’m looking forward to doing the extensive work that will be needed to complete [1]. But not for the concise problem details specification. Grüße, Carsten (*) And, while not being one of the foremost experts here, I still have a chip on the table [1], which needs to be revived and could be a home for more considerations on human-readable text. [1]: https://datatracker.ietf.org/doc/draft-bormann-dispatch-modern-network-unicode/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
