Re: [Standards] Proposed XMPP Extension: HTTP File Upload
Hello, The HTTP upload mechanism hinges on the secrecy of the upload URL. Any client who receives it and accidentally publishes it can convey the document. I would like to point you to an alternative, namely MSRP. It is a straightforward protocol, similar in nature to HTTP but with a few desirable facilities extra: - mention both source and destination address, which may be of u...@domain.tld form - block-by-block uploads enable multiplexing streams - checksums on each block - the protocol is symmetric; either side can initiate a transfer - TLS may be used for encryption and server authentication and, possibly, client authentication Although I agree that HTTP is useful for resource sharing, it lacks the security facilities to separate independent downloaders which weakens the security model of this proposal in ways that MSRP does not. MSRP, as you may know, is the SIP answer to file sharing. I am willing to look for the time to write this up in a new XEP- -- but only if this is considered sufficiently interesting as an alternative to this list. -Rick
Re: [Standards] Proposed XMPP Extension: HTTP File Upload
Hello, I would like to point you to an alternative, namely MSRP MSRP is scary as an atomic war :) For my understanding, could you rephrase that in technical terms please? -Rick
Re: [Standards] File Transfer Roadmap
Hi Sam / others, I hope I'm not being ignorant by not having been in the MUC, but one issue deserves attention I think: When talking of file transfer, the issue of NAT traversal invariably pops up, and becomes a strong selection criterium for the mechanism to use. Please don't forget that file transfer between pre-negotiated endpoints is *much* easier in the case of transparant addressing, which we may assume when IPv6 is being used. A sound choice of mechanism should take IPv6 into account, or a separate mechanism might be preferred for IPv6, or perhaps a variation e.g. without NAT traversal techniques. To simplify the transition, ideally the same mechanism would be used for IPv4 and IPv6 of course. Cheers, -Rick
Re: [Standards] XEP-0322: EXI for constrained processing environments
Hi Dave, It's remarkable how small XML processors can be these days, but in any case, have you considered how encryption fits into this, or were you assuming a trusted network? Have not (as is common with XMPP). I can imagine that there would be applications of constrained environments, possibly on trusted networks or using ZigBee processors with hardware support for encryption. In general, I put up the desire of not wanting to get to EXI through fullblown XML to at least not block such applications. -Rick
Re: [Standards] XEP-0322: EXI for constrained processing environments
Hi Daniel, Thanks for the references; I had indeed missed discussion. I also noted that the Last Call seems to have been closed. I think you gave yourself the answer in the latter part of your mail mentioning that with a dedicated port one can start using EXI right-away. Is this approach not working for you? This means that the constrained elements could only communicate through their home server, for which a port was hard-configured, right? They could not perform SRV lookups for another domain and communicate with that. This might be a reasonable assumption, but it is good to be aware of such limitations. As for the EXI cookie, is it an idea to use a processing instruction and/or XML declaration that would be sent to the server? Please correct me if I am wrong but I think this has nothing to do with processing instructions. The EXI Cookie is an optional part of the EXI stream. In fact it is nothing more than a 4 byte magic cookie that serves to identify whether a stream is XML or EXI. Yes, you are right. I was not aware that $EXI was part of the EXI specification, and assumed it was invented by the XEP. Cheers, -Rick
[Standards] XEP-0322: EXI for constrained processing environments
Hello, I was happy to run into XEP-0322, explaining a path of integration for the compact XML representation of EXI. The fully specified path assumes starting off with fullblown XML and then switching to EXI; this is a scenario that would work when the viewpoint is saving bandwidth. Another usecase, where EXI serves the relative simplicity of a client, is not really dealt with under the usual clarity. I am thinking of constrained processing environments, such as clients on microcontrollers. These may want to use EXI to avoid having to deal with the full XML notation, and they would most certainly not be serviced if they have to go through an initial handshake based on XML. Although 2.4 gives some ideas and possibilities, its style sounds informative (ex. and e.g.) rather than normative, which means that there is non real certainty to be drawn. I am writing to emphasise that this should IMHO be cleared up before finalising this XEP. As for the EXI cookie, is it an idea to use a processing instruction and/or XML declaration that would be sent to the server? That would be in line with common XML syntax without adding the burden of XML parsing onto the (constrained) client. A few forms could be used, and in all honesty, may be better standardised as part of EXI than as part of XEP-0322 because it would occur everywhere EXI is used: ?xml version=1.0 syntax=exi? (illegal 1.0 syntax) ?xml version=1.0-exi? (illegal 1.0 syntax) ?xml version=1.0 exi=1.0?(illegal 1.0 syntax) ?xml version=1.1?(breaks with 1.0 requirements) ?exi version=1.0? (after ?xml...? -- upon recognition, respond with the same string, would otherwise ignored?) Ref: http://www.w3.org/TR/REC-xml/#sec-pi and http://www.w3.org/TR/REC-xml/#sec-prolog-dtd This approach would save from specifying another port, and it would be easy to send/process in a constrained environment. Adding NS negotiation might be possible along the same lines, but would already be more complex. Still, not having to build an XML processor to be able to switch to EXI seems like a really good usecase to me. I hope this is useful! Cheers, -Rick
