Dear Peter,
(2013/03/20 4:41), Peter Waher wrote:
- 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.
In general, this requirement should be reflected to decision of
mandatory items in a proposal. For example, 'all EXI options should be
supported in every client' makes client much larger than 'option
document option is only mandatory option'. A client may start
negotiation in EXI instead of XML may reduce the size of the
implementation furthermore.
I think your 'left to developers (no assumptions)' is a possible choice.
- 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.
Ah, I should say: 'how small message (compared to uncompressed XML
message) should be worth working on this topic?' In addition, any other
characteristics (such as implementation simplicity) could be goal of a
proposal.
- 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.
I see. I mean there could be different approach on different management
style. I'm trying to state the problem space we have.
- (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.
I believe it's good to have a default set of options.
For precompression and identification thing, you mentiond variation on
encoding in your proposal. For XML it has the same problem
(You may find 'canonical XML' interesting)
server requirements >= client requirements.
True. In effect, the entire process is client driven, since it is
assumed the client is the weak link.
I agree in general.
- 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.)
I mean this 'should' in context of specification. If client have choice
not to implement XML, I would say a node may (not 'should') use XML.
Your XEP seems for me (correct me if I'm wrong) clients and servers must
be able to speak XML to (at least) start the XEP-138 negotiation.
- 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?
Agree. I mean this is enumeration of decisions to clarify the problem
space. Even it seems to be clear I think worth clarify.
- 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.
Again, 'should' is in context of the specification. Letting everything
up to client's implementor could be a choice. However, a mandated
'greatest common divisor' option (as you stated in exchange of
compressed schema) works good for interoperability and I mean that is
the option a node 'should accept'.
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.
I agree your point but your statement is not for 'proposal just for
communication efficiency'.
[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.
I think XEP-138 based negotiation does not fit in this category. How do
you start XEP-138 based nego (and all other precommunication negotiation
like TLS, SASL, ...) in your proposal?
My proposal (I still don't have enough time to edit it, but I have a
time in few weeks) is to use alternate communication binding with
different port on SRV record on different service name (such as
xmppb-client).
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.
I agree.
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.
I didn't mean your proposal should cover this or that. I'm trying to
define and share the problem space first before digging into technical
details.
Best Regards,
Yusuke
