Hello Matt (again) and Council members. Seems I sent the last mail (below) too quickly, and started to think a little, with regards to IBB. I have a set of questions/reflections:
The IBB requires an open iq-stanza (with response and possible handshake) and a closing iq-stanza (with response) for each transfer. For streamBase64 I see no problem in converting to IBB for transport. I agree that IBB is better suited for this, as it is already defined. But for normal chunked transfer, this seems very impractical. This may result in hundreds of additional messages that needs to be sent for a simple API-transaction, invoking a set of calls, etc. Or a normal web page (containing links to much embedded content). Note that chunked transfer is often used when content size (Content-Length) is not known, and the server decides to start transmitting anyway to maintain buffers small. This is often the case as I mentioned for dynamic content, not necessarily large, for instance in results to API calls. To add such a large extent of messages for each response will decrease performance radically without much gain. I therefore wanted to ask if it is possible to leave the chunkedBase64 encoding as it is, and only convert streamBase64 to IBB? I believe the overhead of messages merits a separate handling in this case. The chunk message contains a last attribute also that is a convenient way to avoid the last close iq stanza in IBB. This saves a lot during small transfers. Consider a relatively small HTTP GET with a response of 3 chunks. Using IBB it would require at least 2+2+3+2=9 messages (http get+reponse+ibb open+ibb open response+3 chunks+close+close response), while as it is now, only 5 messages are required. The streamBase64 part is different however, as it is probable that very few (probably at most one) stream is active from a client at a given time. Having the additional open and close commands here gives no visible additional cost in terms of messages. What is the opinion of the council: Is the use of IBB so important in this case that a performance degradation is preferred in the chunked case? Or is it sufficient to use IBB only in the streamBase64 case, and leave the chunkedBase64 case as is? Sincerely, Peter Waher -----Original Message----- From: Peter Waher [mailto:peter.wa...@clayster.com] Sent: den 22 maj 2013 22:19 To: XMPP Standards Subject: Re: [Standards] Comments on "HTTP over XMPP" Hello Matt. Thank you for your input. I'll answer them one at a time: > I have some comments regarding the Proto-XEP "HTTP over XMPP": > > * I don't think the use of <iq type='get'/> is appropriate here, as per the > guidelines in RFC6120 § 8.2.3. At a minimum, the unsafe methods (e.g., > DELETE, POST, PUT, et al) ought to be <iq type='set'/>, although a strong > argument can be made that all ought to be <iq type='set'/>. I've changed to type='set' for all methods, to avoid complications. > * This protocols seems like an appropriate place to use [SHIM]. SHIM is already used. The newer version has not been copied to the inbox however. I've attached the new version. A special note has been added (§6.2) addressing semantic differences between SHIM, and how headers are using in HTTP, and in this XEP. > * I note that "Response formats" seem to be useable in requests. I would > consider changing the term to something a little more generic. This has also been changed in the new version, but not published to the inbox yet. The new term is "Encoding formats", found in §4.2 in the new document. > * Are there any concerns about what data transfer mechanisms/resposne formats > an entity is expected to accept? This document seems to imply all entities > MUST understand all of them, and I'm not sure that's a reasonable implication. Not explicitly. Each entity is supposed to understand it only to a certain point: It is required for instance to know how to handle a stream, or more explicitly, how to close one. Or clean up current streams if a client goes off-line. But when it comes to file transfer (sipub), or Jingle, it's still an active choice of the client to continue with the actual negotiation and request transfer. > * It would seem to me that the actual data transmission of chuckedBase64 and > streamBase64 are better implemented as [IBB], or use Jingle with [XEP-261] > IBB candidates. I will rework the specification so that it uses IBB instead of chunkedBase64 or streamBase64 encoding types. Will send you an updated version with this hopefully tomorrow. Sincerely, Peter Waher
