On Tue, May 7, 2013 at 9:35 PM, Peter Saint-Andre <[email protected]>wrote:
> On 5/7/13 2:04 PM, Dave Cridland wrote: > > > > > > > > On Tue, May 7, 2013 at 6:56 PM, Peter Saint-Andre <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 5/7/13 11:49 AM, Dave Cridland wrote: > > > Don't these headers and shim have different semantic meaning, > though? > > > > Not that I can see. Care to elaborate? > > > > > > SHIM is used to specify RFC 822 style freeform metadata on a message (or > > presence, though I've never seen that) stanza, using registered header > > field names, some drawn from a number of protocols, some specific to > XMPP. > > > > This is being used to encapsulate HTTP header fields, which (by > > definition) have names which may not be registered and semantics defined > > purely within RFC 2616, and transported inside an iq stanza. > > I disagree. XEP-0131 explicitly references RFCs 2045, 2616, 2617, 2822 > (needs to be updated to 5322), and 3261. That covers MIME, HTTP, email, > and SIP. And the SHIM registry includes headers from most or all of > those specs (and a few others). So SHIM is very much not limited to RFC > 822. > Right, you're saying what I said - SHIM draws a selection of header field names from a number of protocols. I didn't say they were limited to RFC 822; I said they were RFC 822 style - in the sense of the syntax and high-level structure - but not the semantics. To use SHIM, we'd need to have the SHIM registry have all the RFC 2616 header fields in perpetuity, and require that the RFC 2616 definitions are used. But XEP-0131 explicitly says these relate to the stanza, not some other abstraction, and for stanzas, the mail definitions make more sense. (An aside here is that we have a Content-Type SHIM field which has a definition as RFC 2045 *or* RFC 2616 - one wonders how one chooses). Now in principle, one could change XEP-0131 to allow unregistered headers, and apply the metadata to the parent element (here a request or response), however as Peter Waher says, it's not actually metadata here, but the request header - squinting a bit might make this work, but really, the header fields used here have very specific meaning defined purely for HTTP (so RFC 2616 and updates *only*). Synactically, I prefer XEP-0131, but the semantics do not seem a good match to me. I would prefer a <http-header-field name='Content-Type'>text/html; charset="utf-8"</http-header-field> to underline the difference, while using the XEP-0131 XML structure. Dave.
