Hi, Following inline some feedback. While a little late I hope it’s still useful.
On 08.10.2014, at 18:33, XMPP Extensions Editor <[email protected]> wrote: > 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? Yes. It aims to provide higher compression rations compared to general purpose compression like ZLib. > 2. Does the specification solve the problem stated in the introduction and > requirements? I hope so. I haven’t implemented it and the document itself doesn’t show how it compares to the currently available general purpose compression methods. Considering the constrained devices application scenario I would expect the compression ratios be as good if not better as general purpose compression and that the code required for this is as small in comparison as devices are not only constrained in battery energy but also in code storage size and processing power.. > 3. Do you plan to implement this specification in your code? If not, why not? I currently don’t have plans to implement this protocol as my current XMPP usage scenarios don’t include extremely constrained devices, where implementing EXI would have a benefit justifying the work to implement it. > 4. Do you have any security concerns related to this specification? I think using a more secure hash function would be beneficial for reducing code. Secure wireless constrained applications are likely to already include a high security cryptographic hash function. Using this hash function would avoid the need of implementing MD5 at all. Maybe, hash agility could also be useful in this case. So clients, I think this is the main deployment target for as constrained device, can pick the one already available. Servers which are likely to have more power can then simply use the same hash as the client. > 5. Is the specification accurate and clearly written? As Philipp already mentioned, the negotiation of the port inside the stream features as dedicated compression methods seems quite strange. I haven’t read it in all detail but except for some typos it reads okay. Typo: Once an EXI setup has been accepted by the server, and agreement is reched, the… : “reched” -> “reached” Cheers, Tobias
