Hello Thanks for all input on the HTTP over XMPP proposal. Following are my comments to Kevins suggestions:
> 2) http://xmpp.org/extensions/inbox/http-over-xmpp.html > Accept as experimental? > > Matt, Matt, Ralph don't object. Tobias and Kev have a fortnight to object on > list. > > [Kev subsequently doesn't object, but does note that the XML encoding needs > to take care not to cause illegal XMPP to be sent - e.g. the > document body could have jabber:client namespaced elements that are illegal - > 4.1.4 seems to benefit from a note here, as would 4.2.2. The note at the end of §4.1.4 has been expanded, as suggested: "Note: If using xml encoding of data, care has to be taken to avoid including the version and encoding information (<?xml version="1.0"?>) at the top of the document, otherwise the resulting XML will be invalid. Care has also to be taken to make sure that the generated XML is not invalid XMPP, even though it might be valid XML. This could happen for instance, if the XML contains illegal elements from the jabber:client namespace. If in doubt, use another encoding mechanism." OK? > 4.2.3 seems to claim that only EXI compression can counter the growth of > base64d data, which doesn't seem to be true. Changed the way this was explained, and expanded the explanation why EXI compression removes the otherhead otherwise added by base64. It's not meant to mean EXI is the only option available to reduce the size, just that it does, if in schema-aware mode. Beginning of §4.2.3 now says: "Base-64 encoding is a simple way to encode content that is easily embedded into XML. Apart from the advantage of being easy to encode, it has the disadvantage to increase the size of the content by 33%, since it requires 4 bytes to encode 3 bytes of data. Care has to be taken not to send too large items using this encoding. Note: The actual size of the content being sent does not necessarily need to increase if this encoding method is used. If EXI compression is used at the same time, and it uses schema-aware compression, it will actually understand that the character set used to encode the data only uses 6 bits of information per character, and thus compresses the data back to its original size." OK? > In the descriptions of 4.3.1, isn't the scheme 'xmpp' or 'http' rather than > 'xmpp://' or 'http://'?. I've corrected this so it appears as you suggest. > 6..3 - there is a minimum maximum stanza size defined for XMPP, which might > be worth mentioning here.] I've added then following note to §6.3 to illustrate this point: "Note: According to RFC 6120 [21] there is a smallest allowed maximum stanza size that all XMPP servers must support. According to §13.12.4 of that document, this limit is set to 10000 bytes including all characters from the opening < character to the closing > character." OK? I'll answer to Ralphs comments in a separate mail. Sincerely, Peter Waher
