log of 4/4/02 TBTF call IRC minutes

I'll send out separate cleaned up draft of noah's proposal
wording later today.

Cheers.

Chris

[11:25] <Henrik> 10.4.16 415 Unsupported Media Type
[11:25] <Henrik>    The server is refusing to service the request 
because the entity of
[11:25] <Henrik>    the request is in a format not supported by the 
requested resource
[11:25] <Henrik>    for the requested method.
[11:26] <Gudge> ????
[11:26] <Henrik> 14.1 Accept
[11:26] <Henrik>    The Accept request-header field can be used to 
specify certain media
[11:26] <Henrik>    types which are acceptable for the response. Accept 
headers can be
[11:26] <Henrik>    used to indicate that the request is specifically 
limited to a small
[11:26] <Henrik>    set of desired types, as in the case of a request 
for an in-line
[11:26] <Henrik>    image.
[11:26] * Henrik gudge, don't worry ;)
[11:26] * Gudge decides to leave well alone ;-)
[11:40] <chris> there's also 406
[11:40] <chris> 10.4.7 406 Not Acceptable
[11:40] <chris>    The resource identified by the request is only 
capable of generating
[11:40] <chris>    response entities which have content characteristics 
not acceptable
[11:40] <chris>    according to the accept headers sent in the request.
[11:40] <chris>    Unless it was a HEAD request, the response SHOULD 
include an entity
[11:40] <chris>    containing a list of available entity characteristics 
and location(s)
[11:40] <chris>    from which the user or user agent can choose the one most
[11:40] <chris>    appropriate. The entity format is specified by the 
media type given
[11:40] <chris>    in the Content-Type header field. Depending upon the 
format and the
[11:40] <chris>    capabilities of the user agent, selection of the most 
appropriate
[11:40] <chris>    choice MAY be performed automatically. However, this 
specification
[11:40] <chris>    does not define any standard for such automatic 
selection.
[11:40] <chris>       Note: HTTP/1.1 servers are allowed to return 
responses which are
[11:40] <chris>       not acceptable according to the accept headers 
sent in the
[11:40] <chris>       request. In some cases, this may even be 
preferable to sending a
[11:40] <chris>       406 response. User agents are encouraged to 
inspect the headers of
[11:40] <chris>       an incoming response to determine if it is acceptable.
[11:40] <chris>    If the response could be unacceptable, a user agent 
SHOULD
[11:40] <chris>    temporarily stop receipt of more data and query the 
user for a
[11:40] <chris>    decision on further actions.
[11:40] *** Disconnected
[11:40] *** Attempting to rejoin...
[11:40] *** Rejoined channel #xmlprotocol
[11:40] *** Topic is 'TBTF chat'
[11:41] <chris> 10.4.7 406 Not Acceptable
[11:41] <chris>    The resource identified by the request is only 
capable of generating
[11:41] <chris>    response entities which have content characteristics 
not acceptable
[11:41] <chris>    according to the accept headers sent in the request.
[11:42] <chris>  Unless it was a HEAD request, the response SHOULD 
include an entity
[11:42] <chris>    containing a list of available entity characteristics 
and location(s)
[11:42] <chris>    from which the user or user agent can choose the one most
[11:42] <chris>    appropriate. The entity format is specified by the 
media type given
[11:42] <chris>    in the Content-Type header field. Depending upon the 
format and the
[11:42] <chris>    capabilities of the user agent, selection of the
[11:42] <chris>    capabilities of the user agent, selection of the most 
appropriate
[11:42] <chris>    choice MAY be performed automatically. However, this 
specification
[11:42] <chris>    does not define any standard for such automatic 
selection.
[11:42] <chris> maybe I used the wrong response code?
[11:43] <chris> 406 says that the origin server should include an entity 
body that tells the UA what types are allowed
[12:01] <marc> do we need to come up with a format for the entity body ?
[12:01] *** Gudge is now known as GudgeAway
[12:02] <chris> I don't see why we cannot just use Accept. I realize it 
is a "request" header, but what I don't understand is why it can't be 
used in a response as long as we say what it means and how it is used
[12:02] <Henrik> but that would be redefining HTTP which I would rather not
[12:03] <chris> no, I'm not so certain that it is. Is there a boundary 
between HTTP defined headers and application defined headers?
[12:04] <chris> I can include application-defined headers and HTTP just 
ignores them, right?
[12:04] <Henrik> right but believe me, negotiation in HTTP is a *huge* 
rathole
[12:05] <chris> but we're talking about negotiation at a level just 
above HTTP proper... the binding
[12:06] <chris> Noah:
[12:07] <chris> Henrik:
[12:07] <chris> we have mechanism in HTTP for failure mode for request
[12:08] <chris> response, can put in mechanism in HTTP for requsting 
response type (Accept)
[12:08] <chris> to go beyond, we have to say in order for you to talk 
about these (s+a, etc.) you have to give them a URI
[12:08] <chris> it depends on the framework you describe
[12:09] <chris> could be oob, etc. we don't have to mandate the means
[12:09] <chris> we have basic notion that you send 
application/soap+xml... I can stick other stuff in and it fails gracefully
[12:09] <chris> we don't have to go the last mile to say how new
[12:09] <chris> we don't have to go the last mile to say how new 
features are negotiated oob
[12:09] <chris> could be wsdl, phone call, etc.
[12:10] <chris> Noahs:
[12:11] <chris> conforming impls of this binding MUST be capable of 
sending/receiving using application/soap+xml whose use is described here.
[12:11] <chris> s/whose use/whose proper use/
[12:11] <chris> (or in ID baker soap_xml
[12:13] <chris> conforming bindings MAY send requests and responses 
using other media types providing that such media types are suitable for 
the transfer of SOAP XML Infoset
[12:15] <chris> side note: we've lost the ability to do what SOAP 1.1 
binding said which was you could send SOAP message and get back a GIF or 
some media type that wasn't a SOAP Infoset
[12:15] <chris> henrik: reason we dropped this because there was a 
strong tunneling view of SOAP... people wanted SOAP in and SOAP out
[12:16] <chris> noah: define different MEP that was almost one way w/r/t 
SOAP (send SOAP and get non SOAP response)
[12:17] *** GudgeAway has quit IRC (Connection reset by peer)
[12:18] <chris> s/suitable for/provide for/
[12:20] <chris>  conforming bindings MAY send requests and responses 
using other media types providing that such media types
[12:20] <chris> provide for the transfer of the SOAP XML INfoset
[12:21] <DavidF> for at least the transfer of the SOAP INfoset
[12:21] <chris> conforming nodes MAY, when sending requests, provide an 
HTTP Accept header such headers SHOULD indicate an ability to accept at 
minimum application/soap+xml
[12:22] <chris> and MAY additionally indicate willingness to accept 
other media types that provide for the transfer of a SOAP XML Infoset
[12:23] <chris> s/SOAP XML Infoset/SOAP message/ (which includes SOAP 
XML Infoset
[12:27] <chris> chris, marc, henrik, noah seem to agree in principle on 
this (noah, henrik, less than ideal) jjm and highland also in agreement
[12:28] <chris> ACTION: chris send above to dist-app
[12:28] <chris> david: we can noodle on this in email and try to wrap
   up by next TBTF call.
[12:29] <chris> Monday 11 EDT
[12:29] <chris> 90 minutes
[12:31] <chris> optionality of feature still missing... needs noodling
[12:31] <chris> highland to set up call details
[12:31] <chris> adjourned

Received on Thursday, 4 April 2002 12:37:02 UTC