On Montag, 4. Februar 2019 20:17:24 CET Jonas Schäfer wrote: > This message constitutes notice of a Last Call for comments on > XEP-0335. > > Title: JSON Containers > Abstract: > This specification defines an element to be used for encapsulating > JSON data in XMPP. > > URL: https://xmpp.org/extensions/xep-0335.html > > This Last Call begins today and shall end at the close of business on > 2019-02-19. > > Please consider the following questions during this Last Call and send > your feedback to the [email protected] discussion list: > > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol?
I’m not 100% sure. When going for an implementation in aioxmpp, I realised that what I would be doing is very, very slim. This typically implies that the re-use value is rather low. Then again, it makes sense to have a standard container when you just need to tunnel JSON over XMPP, e.g. in PubSub or a MUC. For that, it’s probably good. > 2. Does the specification solve the problem stated in the introduction > and requirements? Yes. > 3. Do you plan to implement this specification in your code? If not, > why not? Yes. It’s cheap to do. > 4. Do you have any security concerns related to this specification? No. > 5. Is the specification accurate and clearly written? There is one problem I have with it. It is an unclarity which was also discussed in xsf@ the other day [1]. In section 4, there is: > The <json> element MUST only contain character data, and the data MUST > conform to RFC 4627 [3]. […] The data MUST be encoded as UTF-8 (though > officially unspecified, this is the de facto encoding for JSON today). I find this statement between confusing and misleading. XMPP uses XML 1.0. All character data in XML is a sequence of XML characters (which are a subset of the valid unicode code points) [2]. Thus, it is abstract "text", and not encoded "bytes". The quote from 335 above suggests that you have to encode the JSON using UTF-8, and stuff it into the XML as character data. This would lead to nasty double-encode issues, because the XML layer would encode the character data using UTF-8 before sending it over the wire as XML stream. What that quote *intends* to say is that JSON data encoded as Unicode (as per [RFC 4627]) is put into the XML character data (which will then, as per RFC 6120 and XML, be encoded using UTF-8 before being sent over the wire). I suggest to make this clearer by removing the misleading second sentence (including the parenthetical part) from the quote (which is the third sentence in the original document). Alternative wordings which are less unclear would be ok too. (As an aside: I think we should avoid going into XML implementation details such as which byte encoding is used on the stream in XEPs as far as possible, i.e. unless it diverges from what RFC 6120 describes. Otherwise, when you’re reading a spec and it states something which is just how RFC 6120 and XML work, you get confused as to whether you need to do extra steps when implementing it or not. We are lucky enough to work on top of a well-specified abstraction layer that is XML, we shouldn’t be breaking those abstractions in our documents.) In the same round, I’d also kill the "nor must it accept data in any encoding other than UTF-8 to avoid potential encoding mismatch attacks." statement in section 6. Again, the decoding is logically handled by the XML stream. Don’t break layers. It’s confusing. [1]: http://logs.xmpp.org/xsf/2019-01-11/#16:13:00 [2]: https://www.w3.org/TR/REC-xml/#charsets [RFC 4627]: https://tools.ietf.org/html/rfc4627
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
