W3C

XML Protocols Telcon of 26 April 2006

Agenda

See also: IRC log

Attendees

Present
BEA Systems, David Orchard (dorchard)
IBM, Chris Ferris
IBM, Noah Mendelsohn
Nokia, Mike Mahan
Sun Microsystems, Pete Wenzel
Tibco, David Hull (dhull)
W3C, Yves Lafon
Regrets
Oracle, Anish Karmarkar
Absent
Iona Technologies,
Sonic, Glen Daniels
Sonoa Systems, Vikas Deolaliker
Excused
Ericsson; Nilo Mitra
Oracle, Jeff Mischkinsky
Sun Microsystems, Marc Hadley
Chair
Mike Mahan
Scribe
David Hull

Contents


mike: Any thoughts on a prospective face-to-face

dhull: don't care

noah: Not clear that there's a compelling need, but if there is one, I'm not opposed.

chris: ditto

mike: Doesn't seem to be a clear need. Will keep agenda item around. If there's a clear logjam, will ask again.
... Approval of minutes ...
... any objection?
... approved with no objection
... review of action items. Chris: proposal for SC3. DONE.
... Yves; open issue for MBaker comments, send closing email. DONE. (issues list updated as well)
... Anish; collate definitive SC2 text from last meeting. DONE.
... Agenda item 7: SOAP 1.2 PER
... Summaraize 202/204 issue, dependency on SC1

yves: I appear to be only proponent of 204, but don't mind using 202, so group consensus would be 202.

mike: Code will be 202. Leads us to SC1 (202 semantics), which was hanging on this.
... One dangling thread on SC1, 202 and reliable messaging.

<noah> DH: Sometimes RM will want to send a 202 with something that's not actually a response

<noah> DH: If I want to send a bunch of messages one way from point A to point B

<noah> DH: The 202 could come back with acknowledgement headers in it. Muddies the waters compared to usual 202 being empty.

<noah> DH: This stretches our notion that 202 signals an empty reply

<noah> DH: So, WSRX (?) muddies the waters.

noah: Discussion has come up before. I'm also a bit hesitant. RX stretches HTTP to some degree. But from a "glass half-full" point of view ...
... Suppose a string of messages is going from A to B, reliably, with various acks. Less problematic case is when outgoing messages have RX headers. In that case, those headers are part of the HTTP "request".
... So ack to header is also a "reply". But the stretch is that there are two resources at once: the resource that is receiving the message and the reliability state of the messages (meta-resource).
... So I'm not happy with the stretch, but you can at least make the case for it when RX headers are in outbound msg.
... We have some draft text on 202. Does it say use 202 when there's not envelope?
... I.e., does it prohibit non-empty 202.
... Table 17, section 512 says 202 -> "no envelope is provided". This is not what people are planning on doing.
... Question is, does RX behavior abuse HTTP?
... But my point is that we forbid it (abuse or not)

dhull: If you send headers but no (i.e. empty) body, that's an envelope.

dorchard: There was much discussion in WSA. There were complains when the first version said "this is one way, no return envelope." People were adamant that an envelope be allowed in 202 response (regardless of its actual contents)

noah: Immediate issue is that our current draft forbids envelope with 202. Do we want this?

chris: In RX case there will be RX headers on the request message, so Noah's assumption above is met.

<noah> The draft of table 17 now says: The request has been accepted, but no response envelope is provided. Any further application processing is beyond the scope of this use of the 6.2 SOAP Request-Response Message Exchange Pattern***.

<noah> Proposed change:

mike: Proposals for fixing the sentence?

<noah> The request has been accepted, but either (a) no response envelope is provided or (b) an envelope is provided, and that envelope represents an interim response to the request. Any further application processing is beyond the scope of this use of the 6.2 SOAP Request-Response Message Exchange Pattern***.

dhull: "interim" is not quite right

noah: Yes, working on that. Normally we have to say what envelopes are processed in the model. Interesting question is, when envelope comes back with 202, we can say either "Envelope MUST be processed" or "processing is out of scope" (which would allow RX or WSI to spec what processing happens, beyond SOAP rec)
... Worried about slippery slope, having to answer more questions about what processing the 202 response means. OTOH, not sure this slope leads too far. But need to know what to say about processing the envelope.

?: About processing the response envelope?

noah: This envelope is not the "real" response

chris: Goes to "what constitutes a response?"

noah: Trying to stay mechanistic. Have to say something about processing of this envelope. Possibilities range from "always process response envelopes" (regardless of 202 or 200), or can say "200 MUST be processed, 202 processing out of scope"
... So 202 is allowed, but we don't say whether or how to process it. Look elsewhere if you want to know whether to run SOAP processing model on it.

dhull: more comfortable with "out of scope"

mike: proposed sentence is neither?

noah: Proposed sentence is preamble to either one.
... Can see putting these options in the 202 or elsewhere in the table.

dhull: "interim" is not good for true one-way case.

noah: "interim" comes from HTTP spec.

<noah> The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.

<noah> The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed.

<noah> The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

noah: Implies response is a status update (different thing from interim response)

dorchard: 202 means "not done". 200 and 204 mean "done".

noah: 202 is "I'm not committing". Could have used other status code for "done".

chris: "non-commital" doesn't say anything about done-ness.

dorchard: So it could mean "done"

noah: There are always race conditions, but generally 200 means done, 202 means "decline to say" means "pretty sure it's not done". Might not always be the case, but who cares?

dhull: 204 seems more appropriate for true one-way.

chris: What does "done" mean? Received or processed.
... No ack means resend, but no expectation of processing. 202 means "we accepted your message, will deal with it later". Doesn't matter how much later. So 202 is appropriate.

dhull: (much discussion of 202 vs. 204)

noah: Important point is will this work with HTTP infrastructure. It looks like our use of 202 will work with that. Mostly a happy accident, because we're stretching the model, but in places that probably won't be noticed much.
... From practical point of view, need to get on with it. 202 seems OK or at least less evil. But need to fix prohibition of envelope.
... And need to say when envelopes MAY, MUST or SHOULD be processed.

dhull: Agree. I may have been reopening closed issue.

mike: Moving on, is there cleanup of proposed sentence to be done?

noah: "partial" rather than "interim"

chris: You said "interim" does somewhat follow from text.

noah: That was original idea, but "interim" is too far from HTTP RFC.

chris: "not yet completed" probably suggested "interim"

dhull: maybe take out "represents ..." part entirely?

mike: Is it clearer with the motivating description

<noah> an evnelope, typically representing an interim or partial response, is provided

dhull: potentially misleading is worse than nothing
... "typically representing" is fine

<noah> provided -- any SOAP processing of such an envelope is beyond the scope of this Recommendation.

<noah> provided -- such envelopes SHOULD be processed using 2.6 SOAP Processing model.

mike: Can we pull together full proposal?

chris: Was going to suggest that instead of "interim processing" just note that the envelope in the response is related to request in some way. E.g., "represents information related to the request provided. Such envelopes SHOULD be processed ..."

dhull: This seems somewhat better yet.

<noah> Variation #1:

<noah> The request has been accepted, but either (a) no response envelope is provided or (b) an envelope, typically representing an interim or partial response, is provided -- any SOAP processing of such an envelope is beyond the scope of this Recommendation.

<noah> Variation #2:

<noah> The request has been accepted, but either (a) no response envelope is provided or (b) an envelope, typically representing an interim or partial response, is provided -- such envelopes SHOULD be processed using 2.6 SOAP Processing model.

mike: doesn't "response" imply "related to request"?
... Do we need to be explicit about intention of response message?

noah: There are two ways to state relation: either say "related" or call it a "response". Don't have strong preference.

mike: Chris's is broader than Noah's
... preferences?

dhull: Prefer Chris's, can certainly live with either.

dorchard: Prefer 2
... No strong preference

chris: Don't see my proposal numbered.

noah: Working on it.

<noah> Variation #Chris:

<noah> The request has been accepted, but either (a) no response envelope is provided or (b) an envelope representing information related to the request is provided -- such envelopes SHOULD be processed using 2.6 SOAP Processing model.

dhull: Two orthogonal choices (before and after dash)

noah: Concentrating on first choice.

mike: Preferences for this?

dhull: #Chris

noah: No preference at all

mike: Slight preference for Chris.
... Second part -- binding to processing model.

noah: MUST is also a reasonable proposal. Current choice is "SHOULD" or "we don't say".

<noah> -- any SOAP processing of such an envelope is beyond the scope of this Recommendation.

<noah> -- such envelopes SHOULD be processed using 2.6 SOAP Processing model.

<cferris> I prefer the latter and am leaning towards MUST

noah: Mostly a matter of hygeine. Only MUST NOT would be harmful. But we should make an explicit statement.

chris: Leaning toward MUST, researching what we say about normal 200 case.

<noah> I can live with MUST. I only went with SHOULD because of two reasons: reason 1 is that we're a bit mushy about what this thing is in the first place and reason 2 is that the MEP talks about procesing a response, and as Chris has argued >that< one will be delivered later if ever.

<noah> In short, when something is as messy and poorly justified as this whole use of 202 for RM, somehow SHOULD seems more in the spirit. That said, MUST is fine with me if you all prefer.

chris: Don't see any SHOULD or MUST process for normal response. Just says that messages are transferred, and that response is sent after successful processing. Response is only transferred, doesn't explicitly mention processing of response.
... So why say anything in this case?

noah: I'm falling pray to being comaptible with what should have been written, not what was. This is a bit of an odd case and guidance would be good, but proposed text acts as though rec was more careful than it was.
... Processing is fundamental to MEPs and should be there, but we blew it in the original. This is not a good place to innovate, unless it will help somebody. So I withdraw the proposal unless it will help.

dhull: So drop part after dashes and keep part before?

noah: Yes.

chris: Would have hoped that processing was there originally.

noah: Think of all the processing code we wrote but didn't need to do to conform :-)

chris: Would go with consistency with what we have, unfortunate though it may be. This would raise questions about things unsaid in rec.

noah: Can read part 1 to say that all receivers must run processing model. Same kind of mess we hit where we tried to figure out difference between message and SOAP message. Turned out the difference was made deliberately. Sorting this will require closer reading of whole spec.
... Some processing is required of all receivers. Other bindings may say more. Is there any doubt that there is a SOAP receiver here?

chris: No.

noah: Then we're probably done.

mike: So choice is explicit or consitent with previous.

noah: Can say "note that ...". Needed to do a bit of thinking. Convinced that rec defines the behavior, but might want to be more explicit to help the reader.
... Might say that node receiving an envelope, whether 200 or 202, is a SOAP receiver and so uses model in Ch2. Need to read rec carefully before drafting text.

<noah> Right, this would be below Table 17.

mike: Current proposal is to drop text after dashes but add explanatory text after Table 17?

noah: Yes. This seems consistent with our latest noodling.

mike: Need to take this offline and get proposed text, researched against rec? Noah?

noah: Yes, but may take until Monday or Tuesday.

ACTION: Noah to Draft proposed text after Table 17. [recorded in http://www.w3.org/2006/04/26-xmlprotocol-minutes.html#action01]

ACTION: Mike to Draft text for "before dashes" based on Chris's friendly amendment. [recorded in http://www.w3.org/2006/04/26-xmlprotocol-minutes.html#action02]

mike: Want to get 1.2 PER completed and ready for publishing. Just went through SC1, handled SC2 last week. Last issue is SC3. Can Chris introduce latest post to mailing list?

chris: Had lengthy discussion, but concluded we were on same page but using different words. Key aspect of proposals was people misreading "envelope", "message", "response" etc. Original proposal read "start of response envelope" avalailable.
... but "envelope" is just a property of the response message. All agree that whether envelope is present has nothing to do with when we start sending it. So change text from "response envelope" to "response".

dorchard: Seems to work for me.

dhull: Works for me.

mike: Agreed without objection

ACTION: Mike to Show the conclusions of SC3 to the mailing list. [recorded in http://www.w3.org/2006/04/26-xmlprotocol-minutes.html#action03]

mike: With these, will be in position to publish PER.
... Next week, finish this up. Apologies to DOrchard for lack of time for one-way proposal. Should have quorum for it next week.
... Anything else?

chris: Ask others about F2F

ACTION: Mike to Send query about F2F to members-only list. [recorded in http://www.w3.org/2006/04/26-xmlprotocol-minutes.html#action04]

Mike: Adjourned

Summary of Action Items

[NEW] ACTION: Mike to Draft text for "before dashes" based on Chris's friendly amendment. [recorded in http://www.w3.org/2006/04/26-xmlprotocol-minutes.html#action02]
[NEW] ACTION: Mike to Send query about F2F to members-only list. [recorded in http://www.w3.org/2006/04/26-xmlprotocol-minutes.html#action04]
[NEW] ACTION: Mike to Show the conclusions of SC3 to the mailing list. [recorded in http://www.w3.org/2006/04/26-xmlprotocol-minutes.html#action03]
[NEW] ACTION: Noah to Draft proposed text after Table 17. [recorded in http://www.w3.org/2006/04/26-xmlprotocol-minutes.html#action01]
 
[End of minutes]


Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/07/26 21:01:46 $