Dear Yusuke Thanks for your input.
I'll address your comments sequentially: > - Minimal client requirement > How small a client implementation should be? In what way would this affect the XEP? I see this as an implementation detail that can be left to product developers. > - Minimal server requirement > How small a server implementation should be? This is also an implementation detail left to product developers. > - Message Efficiency requirement > How small a message should be? This would depend on use case, overall IT architecture, etc. What's small to one application might be huge for another. > - Schema management (in a communication and in the whole system) > How do we manage schema and its variants? The XEP only defines that different versions of schemas with the same namespace must be handled. It also provides a small implementation note how this could be achieved on the server side. > - (maybe more axis should be there) A couple of interesting requirements arose as a response to input from Rumen and Takuki, regarding uploading pre-compressed schema files. Requirements on pre-set options for such pre-compressed schema files and what is supposed to be a minimum of requirements for the server. > server requirements >= client requirements. True. In effect, the entire process is client driven, since it is assumed the client is the weak link. > - Should a node accept plain text XML, in addition to EXI? With node, I assume you mean client? In this case, at least sufficiently to perform the negotiation. It's the client that decides. (This is noted in the XEP.) > - Should a node accept introduction of new schema-informed grammar? If node=client, then the client never receives schemas from the server. The client knows at compile time what namespaces it can interpret, and should provide those schemas. So, the only probable reason for not having a specific schema, is if something it does not understand is being sent. Why should the client provide logic and space for handling this? > - Should a node accept various set of options? Which option should be > selectable per session? Finally it's up to the client to decide. Takuki wrote a mail on the same topic where he proposed an order of the different options, whereby if a party knows how to handle a "difficult" option, it should be able to handle "easier" options. > Combination of client and server requirement could be something like the > followings: > > [Proposal just for communication efficiency] > - Server and client should accept various EXI options and dynamic schema > installation in addition to plain XML communication handler. It might be valid for the client to only support one particular set of options. However, the server should be able to understand all options for that EXI version. However, for embedded XMPP servers, the domain of allowable EXI options might have to be restricted. > [Proposal for extremely constrained clients] > - Client may implement only EXI-based, fixed schema set. The client may be > able to notify/upload the implemented schema set to its corresponding server. > - Server should implement both EXI and XML with dynamic schema installation > with appropriate limited set of options. This is the proposed solution. > Many other combination should be considered. Even binary-only servers could > be possible. Of course, interoperability between current XMPP implementations > will be lost without further consideration like Server-to-Server proxy. This proposal does not include a binary-only communication. It's a great idea, but should be made in a separate proposal. Also, the proposal does not discuss federation (server-server proxy), or how exi should/could be used there. It assumes the server decompresses exi received from the client, since different clients (or federated servers) use different options, which would make binary streams not compatible. Sincerely, Peter Waher -----Original Message----- From: Yusuke DOI [mailto:yusuke....@toshiba.co.jp] Sent: den 19 mars 2013 04:47 To: Peter Waher Cc: Peter Saint-Andre; XMPP Standards; Joachim Lindborg (joachim.lindb...@sust.se); Takuki Kamiya (tkam...@us.fujitsu.com) Subject: Requirement Clarification (Re: EXI extension proposal) Dear Peter and all, (2013/03/18 22:53), Peter Waher wrote: >> Is a mail with the subject 'Requirement Clarification' sent to the list? > > I've not received one. Oops, It seems to be sent to different list? Let me re-send one. --- I believe combination of XMPP and EXI should have great synergy and can extend the world of XMPP far more. However, because this space is very wide and I think it's better to clarify requirements on this combination, mainly towards IoT/M2M/sensor network use case of XMPP. Let me start with enumeration of problem spaces. - Minimal client requirement How small a client implementation should be? - Minimal server requirement How small a server implementation should be? - Message Efficiency requirement How small a message should be? - Schema management (in a communication and in the whole system) How do we manage schema and its variants? - (maybe more axis should be there) In this mail, let me start with client/server requirements. I think it is clear: server requirements >= client requirements. to make things work. Choice would be something like this: - Should a node accept plain text XML, in addition to EXI? - Should a node accept introduction of new schema-informed grammar? - Should a node accept various set of options? Which option should be selectable per session? Combination of client and server requirement could be something like the followings: [Proposal just for communication efficiency] - Server and client should accept various EXI options and dynamic schema installation in addition to plain XML communication handler. [Proposal for extremely constrained clients] - Client may implement only EXI-based, fixed schema set. The client may be able to notify/upload the implemented schema set to its corresponding server. - Server should implement both EXI and XML with dynamic schema installation with appropriate limited set of options. Many other combination should be considered. Even binary-only servers could be possible. Of course, interoperability between current XMPP implementations will be lost without further consideration like Server-to-Server proxy. Summary: I think EXI is so flexible and thinking about 'what we really want to do' will greatly help to cut down the huge problem space. Regards, // Yusuke DOI <yusuke....@toshiba.co.jp>
