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. > , 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. 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. * The XEP-0131 defines a discovery mechanism for SHIM. Search features are not necessarily desired in the web server case. * Incorporating a new namespace for the headers makes it more complicated, at the same time nothing is gained. 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? Sincerely, Peter Waher
