On 5/7/13 2:54 PM, Peter Waher wrote: > Hello Peter > > Thanks for your feedback. > > Regarding your concerns: > >> I'm not yet convinced of the need for this extension > > On what sense are you not convinced by the need of this extension? > The example you provide is of course a simple OPTIONS query, but most > HTTP communication include data somewhere. Data transport is not > available in XEP-0131.
I didn't say it was. All I said was, let's not define a new protocol that does exactly what XEP-0131 does, but with a slightly different syntax. IMHO *if* we want to tunnel HTTP over XMPP, we can do that, but the way to do that is exactly what I posted in my message: new <request/> and <response/> elements qualified by a new namespace, which in turn wrap SHIM headers. >> , but if we're going to proceed with it then I strongly recommend >> re-using the syntax from XEP-0131. > > Is it only the syntax of the headers that is the problem? Or is it > something else? > > XML-wise it is of course easy to switch from one syntax to another, > but there are several issues with XEP-0131 in this case that makes me > uneasy using it. These are: > > * As Dave Cridland points out, the SHIM headers and HTTP headers have > different semantic meaning. As I pointed out, Dave is wrong. :P > In the HTTP case, they are well defined > HTTP headers with specific meanings, that has to be forwarded to the > web server. XEP-0131 headers are defined as "Stanza Headers and > Internet Metadata". It is a bit unclear what this actually means. But > in the case of HTTP, they is neither Stanza headers nor meta-data, > but actual data that is being transported. What is wrong with the XEP-0131 representation of HTTP headers (and other headers) that makes it problematic to re-use here, wrapped of course by your new <request/> and <response/> elements qualified by the new namespace you care about. > * The XEP-0131 defines a discovery mechanism for SHIM. Search > features are not necessarily desired in the web server case. I didn't say they were. Wrapping, man, wrapping! > * Incorporating a new namespace for the headers makes it more > complicated, at the same time nothing is gained. That's called re-use. > However, if it is only the syntax that is of a concern, I can change > this, so that instead of a value-attribute, the value is written as a > simple value to the header-element instead. Would that work? Or is > there some other reason why you think the proposed syntax is bad? I don't like to define a new way to encapsulate the exact same information. Peter
