Based on IRC logs for 30 July, 31 July
Present: Asir Vedamuthu, WebMethods Yves Lafon, W3C Martin Gudgin, Microsoft (scribe, p.m.) Colleen Evans, Progress Carine Bournez, W3C Noah Mendelsohn, IBM (scribe, a.m.) David Fallside, IBM (chair) Volker Wiechers, SAP Anish Karmarkar, Oracle Herve Ruellan, Canon Jeff Mischkinsky, Oracle Gerd Hoelzing, SAP Ryuji Inoue, Matsushita Kazunori Iwasa, Fujitsu Mark Jones, ATT Jin Yu, MArtsoft Present by Phone (Partial): Paul Denning, MITRE Mark Baker, Idokorro David Orchard, BEA Excused: Camilo Arbelaez, webMethods John Ibbotson, IBM Henrik Nielsen, Microsoft Jean-Jacques Moreau, CanonResearchCentreFrance Paul Cotton, Microsoft Michah Lerner, ATT Masahiko Narita, Fujitsu Regrets: Highland Mountain, Intel Pete Wenzel, SeeBeyond [David Orchard, BEASystems] Oisin Hurley, IONA [Mark Baker, IdokorroMobile, Inc.] Stuart Williams, Hewlett-PackardLabs Marc Hadley, SunMicrosystems Amr Yassin, Philips Jacek Kopecky, Systinet Nilo Mitra, Ericsson Glen Daniels, Macromedia Murali Janakiraman, RogueWaveSoftware Don Mullen, TIBCOExtensibility Michael Champion, SoftwareAG Yin-Leng Husband, Hewlett-Packard Bob Lojek, Intalio Ray Whitmer, Netscape Absent: Mario Jeckle, Daimler Chrysler Andreas Riegg, Daimler Chrysler Brad Lund, Intel Eric Newcomer, IONA Simeon Simeonov, Macromedia Marwan Sabbouh, MITRE Vidur Apparao, Netscape Yasser alSafadi, Philips Patrick Thompson, Rogue Wave Dietmar Gaertner, Software AG Miroslav Simek, Systinet Frank DeRose, TIBCO Lynne Thompson, Unisys Nick Smilonich, Unisys [scribenrm] ===ACTION ITEM RESOLUTIONS === [scribenrm] Don Mullen: 210 still pending [Anish] Anish has joined #xmlprotocol [scribenrm] Henrik FN: 221 still pending [scribenrm] (note HFN is on vacation...should we reassign?) [scribenrm] David Fallside to Contact Mark Baker: DF says he's tried, no response, still pending [scribenrm] HFN & Stuart Williams: regnerate last sentence of section 2 of Att. Feature Doc...transfering to Herve [scribenrm] ACTION: Herve...to pick up action that had been to HFN and Stuart to fix last sentence, section 2, AF doc [scribenrm] Paul Denning: resolve issue 226 with Paul Prescod. Action is discharged. [Mark_J] Mark_J has joined #xmlprotocol [scribenrm] David Fallside: implementors meeting setup...action is complete [scribenrm] Glen Daniels: propose text for 219 pending [scribenrm] Stuart Williams: text for issue 220...action is complete [scribenrm] =========END SCRIBING OF ACTION ITEM RESOLUTIONS================= [scribenrm] . [scribenrm] =============BEGIN REVIEW OF ATTACHMENT FEATURE DOCUMENT================ [Zakim] +PaulD [DavidF_CA] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0204.html [mitrepaul] pretty good [scribenrm] David V. (hereafter DF) invites Noah to summarize his email...Noah reads email. Main concerns [scribenrm] (1) Features must describe the responsibilities of > bindings < [scribenrm] (2) Current text implies that each embodiment of the feature must describe a representation [scribenrm] RESOLVED: general agreement on the direction...we will take on this approach and text for part 6 as far as it goes but... [scribenrm] ...additional changes are needed to match in other part of the document [scribenrm] ACTION: Herve to update the document with changes as understood so far [scribenrm] Noah informally agrees to assist, if time permits, in drafting rest of required changes. [scribenrm] for wg review [Gudge] Is it http://www.w3.org/2000/xp/Group/2/07/SOAP-AF/aftf-soap-af.html ? [herve] Yes, this is the one. [scribenrm] Some discussion of whether the term attacment is OK. [scribenrm] Agreement that terminology is: "part" covers the envelope, "attachments" are the non-envelope data, "part" covers both. [scribenrm] (Per Mark Jones) [scribenrm] Noah: question to Gudge...do we know whether HFN will be OK with the resolution? [scribenrm] Gudge: if DIME is possible, then yes [scribenrm] Asir: question about why we're doing this as an abstract feature at all [scribenrm] Noah: you get interop from the actual embodiment in a binding [scribenrm] DF: we agreed earlier to take the abstract feature approach [scribenrm] DF: Herve: concern has been expressed that to date properties have either been global or in a message exchange context...the AF document doesn't observe that limitation [scribenrm] (oops) that last entry was Herve, not DF [scribenrm] Some discussion of whether this issue is significant, how much consistency our architecture requires, etc. [scribenrm] DF: was this issue formally raised? [scribenrm] ACTION: Herve to find a description of the feature property issue, so that we can all review the issues. [scribenrm] DF: There were 3 options for publication of this document. There was agreement on the phone on option 3 >>if we can get there<< [scribenrm] option 3 was to position AF as a "Recommendation Track Document", which is a formal status at W3C leading to rec. [scribenrm] Mark Jones: BTW were we to be back in WD (we hope not) we could put this into adjuncts. Agreed. [scribenrm] DF: if we get this together this week, we could possibly publish as a WD before the August quiet time. If we're lucky, we might get clearance to make it a last call document. [scribenrm] Noah: (some lack of clarity on whether that would be last call leading to CR or PR) [scribenrm] DF: Last call might run through August [scribenrm] DF: I propose, unless there is objection now, to tell all concerned that we are proceeding with option #3. Agreed? [scribenrm] DF: schedule is TBD, but we should try to get WD done before disappearing for Aug. [scribenrm] Mark Jones: by doing this we are committing ourselves to stick around to see the process through on this. [scribenrm] DF: yes [scribenrm] DF; I've spoken with Joseph Reagle regarding copyright concerns... [scribenrm] DF ...the text we took came form an Internet Draft. Some of the earlier text came from a document that was in the form [scribenrm] ...of a standards track documented, but that was never submitted and so the copyright statement in it does not apply. [scribenrm] ...the text we actually took had no explicit copyright, except an implicit IETF one that prohibits anything [scribenrm] ...that would impeded dissemination of the text. I (DF) believe nothing we would do would violate that. [scribenrm] DF: we believe that we can put the W3C copyright on our version [scribenrm] ---End discussion of publication issues ---- [scribenrm] Asir. Does section 1.3 rule out things like MIME? [scribenrm] DF: no, it just motivates one of the problems that SOAP has without this feature. It doesn't obligate you to use the feature to do this. [scribenrm] Asir: I'm still not convinced [scribenrm] DF: can you propose a change? [scribenrm] Colleen: modify the solution statement to make clear that you have the option to solve these problems [scribenrm] ACTION: Asir, propose a revision to last paragraph (i.e. not removing point #3) in section 1 of the AF section. [mitrepaul] I will dial back in when I see you resume on IRC. [scribenrm] DF: in response to question from Noah: Herve, as editor of AF, has discretion to consider the minor comments that Noah made in his email (I.e. we discussed the main comment on section 6, discretion is for the others) [Zakim] -PaulD [scribenrm] =========END DISCUSSION OF ATTACHEMENT FEATURE =========== [scribenrm] Break [scribenrm] We're back.... [MarkB] MarkB has joined #xmlprotocol [Zakim] +??P2 [scribenrm] MarkB: we're just restarting after a break...are you dialed in on the phone? [MarkB] zakim, ??P2 is me [Zakim] +MarkB; got it [MarkB] hey, yup I'm dialed in [scribenrm] zakim, who is here [Zakim] scribenrm, you need to end that query with '?' [scribenrm] zakim, who is here? [Zakim] On the phone I see ??P1, MarkB [Zakim] On IRC I see MarkB, Mark_J, Anish, RRSAgent, DavidF_CA, herve, asir, Zakim, scribenrm, Gudge, mitrepaul, HFN, caribouCA, Loggy, Yves [scribenrm] =====BEGIN DISCUSSION OF ISSUESS========= [scribenrm] * Issue 219: definition of SOAP module. [scribenrm] DF: Glen had said he'd write text....not done? [scribenrm] DF: will check whether he's going to dial in...ask him to draft text on 219 first [scribenrm] * [scribenrm] * Issue 220: Remove contradiction from SOAP binding def [scribenrm] * [Gudge] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0211.html [scribenrm] DF: Stuart has proposed resolution... [scribenrm] Noah proposed minor revision to Stuart's: http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0212.html [scribenrm] Stuart then responded with several alternatives in: http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0217.html [scribenrm] We have chosen one of Stuart's variants: [scribenrm] ""The processing of SOAP envelopes in accordance with the 2. SOAP Processing [scribenrm] Model MUST NOT be overridden by binding specifications." [scribenrm] AGREED: Issue 219 closed with text from Stuart [caribouCA] s/219/220 [MarkB] yah [scribenrm] ACTION: Editors, update text with ""The processing of SOAP envelopes in accordance with the 2. SOAP Processing [scribenrm] Model MUST NOT be overridden by binding specifications." [scribenrm] ACTION 5: Editors, update text for resolution of issue 219...see minutes of PA F2F [scribenrm] ACTION 5 = Editors, update text for resolution of issue 219...see minutes of PA F2F [scribenrm] * [Yves] s/219/220/ [Gudge] ACTION 5 = Editors, update text for resolution of issue 220...see minutes of PA F2F [MarkB] i concur with Noah. It's ok as worded. [MarkB] np [Zakim] +DOrchard [scribenrm] * Issue 227: Do we need to say what the HTTP binding does if you don't use the WebMethod Feature [scribenrm] * [scribenrm] Noah: well, I think the design is fine as it stands. We know that some of the others (such as Stuart and probably Marc Hadley) who disagree are not here to represent themselves. [scribenrm] DF: do you know what their position would be. [DaveO] DaveO has joined #xmlprotocol [Zakim] +PaulD [scribenrm] Noah: well, Stuart put out a big summary of everyone's positions. Glen and Mark Baker more or less agree with me. I think that Stuart and probably Marc H. [scribenrm] ...believe that a binding must always indicate how to use it without any of its features. [MarkB] prefer the first [scribenrm] DF: go around the room. Option 1 is the bindging has to say which features it uses, and it can make some of them mandatory OPtion 2 is all features must be optional, and you must say how things work when any or all of them are missing. [mitrepaul] I think Stuart would want to make WMF MUST implement, but MAY use it. if not used, then specify default (e.g., GET) [scribenrm] I think that aspect of Stuart's position is understood. [mitrepaul] implementation vs use? [scribenrm] DF: Proposal...(1) we accept that bindings can specify that features are mandatory (2) we sweep the spec to ensure that's clear (3) leave web method as a mandatory feature of the http binding...i.e. that applications must supply a value for the property...and to make sure the spec is clear on that point. [MarkB] does "must supply a value" imply a default? [mitrepaul] My reading is no. Unless we say that. [scribenrm] Clarification: mandatory in the sense that bindings can mandate that applications (nodes, whatever) must conform to the features spec, supply values for properties per the features spec, etc. [MarkB] ah, ok, *application* must supply ... that's ok [scribenrm] DF: answer to MarkB...only if the feature spec says the value defaults. [MarkB] good, thanks [scribenrm] Asir: I think we need consider 228 right now... [mitrepaul] are wee going to say that WMF defaults to GET? [MarkB] woohoo! [scribenrm] scribenrm has joined #XMLProtocol [scribenrm] test [scribenrm] * [scribenrm] * Issue 228: does the webmethod feature say what it should about different combinations of MEPs and methods are supported [scribenrm] * [scribenrm] Some discussion which I did not manage to log. [Yves] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#webmethodstatemachine [DavidF_CA] DavidF_CA has joined #xmlprotocol [scribenrm] Noah: proposal: Replace last paragraph with "Bindings implementing this feature MUST employee a Message Exchange Pattern with semantics that are compatible with the web method selected. For example, the (link to response only) pattern is compatible with GET. [herve] herve has joined #xmlprotocol [scribenrm] MarkB says: I'd prefer to see it wordsmithed, but it's ok. [scribenrm] Jeff and Asir say they're OK with this. [scribenrm] AGREED: Issue 228 is closed. [scribenrm] ACTION: Editors put resolution text for 228 into spec. [scribenrm] * [scribenrm] * Returning to Issue 227 [scribenrm] * [scribenrm] ACTION: Yves Lafon send xmlp comment on 228 [Gudge] Suggested Remedy [Gudge] ---------------- [Gudge] In the first row of Part 2 Table 15 [1], replace "According to the [Gudge] webmeth:Method property (typically POST or GET)." with [Gudge] "When the webmeth:Method property is present in the Message Exchange [Gudge] Context, HTTP Method is set according to the value of the webmeth:Method [Gudge] property (typically POST or GET). Otherwise, the HTTP methods used is POST [Gudge] if the message exchange pattern in use is the 6.2 [Gudge] Request-Response Message Exchange Pattern ie. context:ExchangePatternName is set to [Gudge] http://www.w3.org/2002/06/soap/mep/request-response/ or the GET if the [Gudge] message exchange pattern is 6.3 SOAP Response Message Exchange [caribouCA] 1) we accept that bindings can specify that [caribouCA] features are mandatory (2) we sweep the spec to ensure that's [caribouCA] clear (3) leave web method as a mandatory feature of the http [caribouCA] binding...i.e. that applications must supply a value for the [Gudge] Gudge has joined #xmlprotocol [caribouCA] property...and to make sure the spec is clear on that point. [Mark_J] Mark_J has joined #xmlprotocol [Anish] Anish has joined #xmlprotocol [mitrepaul] i227. p2/6.4.3 "A node sending a request message MUST provide a value for the webmeth:Method property." the "node" MUST, but application (within the node) may not need to know about WMF. SOAP processor can supply a default? [mitrepaul] I'll cut and paste now. [mitrepaul] I'm having a little trouble [Gudge] 18:32:31 <scribenrm> DF: Proposal...(1) we accept that bindings can specify that features are mandatory (2) we sweep the spec to ensure that's clear (3) leave web method as a mandatory feature of the http binding...i.e. that applications must supply a value for the property...and to make sure the spec is clear on that point. [Gudge] 18:33:42 <MarkB> does "must supply a value" imply a default? [MarkB] yep, I got my answer 8-) [scribenrm] DF: This is the proposal for 227. Any objection to closing issue 227 with this proposal? [scribenrm] AGREED: Issue 227 closed as proposed. [scribenrm] You betcha.. [scribenrm] ACTION: Colleen will to sweep spect to make sure spec is clear that bindings can require use of features. [MarkB] yep [scribenrm] ACTION: Mark Jones to write XMLP comments on issue 227. ALso make clear that it is possilble for a binding to choose to make all features optional. Make sure to include Stuart W., Marc Hadley, MarkB, Jean-Jacques Moreau and Jacek Kopecky [mitrepaul] p2/7.4 "An implementation of the SOAP HTTP Binding MUST support the following feature: [MarkB] Re 221, have folks seen this issue (which I don't see on the issues list); http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0047.html [MarkB] nope [scribenrm] * [scribenrm] * [scribenrm] * Issue 221 [scribenrm] * [scribenrm] Minutes of July 10 telcon say "PI's should not be forwarded." [MarkB] no [mitrepaul] DF: how do implementations handle PI's? [mitrepaul] If PI is not forwarded, then a fault MUST be generated with code of xxx [mitrepaul] NM: PI in middle of header vs PI before/after header [mitrepaul] DF: soap receiver must ignore PIs [MarkB] bring them back! http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0047.html [MarkB] I don't like them, but there's a good practical reason for them, as Simon describes there [mitrepaul] How about a PI Feature with a property set to whether it forwards or faults [scribenrm] Long discussion...(both before and after Mark's comment).... [scribenrm] Noah: note that PI's are specifically a mess relative to the semantics of SOAP. For example, the PI in question might have document scope (stylesheet), might have been relative to a header that was just removed by the intermediary. It's a mess. [mitrepaul] DF: if forwarded, behvior is undetermined. Send PI (XSL) for GET issue to WSA or TAG? [scribenrm] Anish: why do we need to say anything. We say, SOAP receivers must ignore PI's. Doesn't that cover it? [MarkB] Yup, it's a complete mess. Just a useful one for xml-stylesheet & GET. [scribenrm] We had a proposal up to say intermediaries should not forward, if not forwarding must fault, somequestion what to do if it decides to forward. [mitrepaul] speaker-x? if you fault on PI, then you didn't ignore it [Gudge] s/speaker-x/Jeff Mischkinsky [scribenrm] Anish: alternative...say nothing, except maybe clarification that the PI's MUST be ignored at the receiver, therefore [scribenrm] ...we're discussing this.. [mitrepaul] NM: Does ignore mean we can forward it? [mitrepaul] gudge: puke on PI [mitrepaul] NM: avoid adding a layer, walk a dom tree to see if PI is there [scribenrm] thanks for helping with the scribing, I appreciate it! [mitrepaul] I'm glad the audio is good for a change (for a f2f) [scribenrm] DF: Anish, are you saying "SOAP senders may forward PIs"? [mitrepaul] DF: nothing said about PIs and soap senders; should we say something like senders may fwd PIs [Gudge] A SOAP message SHOULD NOT contain processing instruction information items. A SOAP receiver MUST ignore processing instruction information items in SOAP messages that it receives. [mitrepaul] s/ignore/do not act on/ [Gudge] How about 'A SOAP sender SHOULD NOT send messages containing PIIIs.' [mitrepaul] DO: PI heritage not applicable in SOAP world [scribenrm] DO: maybe we should just come really close to removing them. [mitrepaul] NM: would words on PI be a substantive change that force another LC [scribenrm] Noah: we've come as close as we can without going all the way, and we're still confused [Gudge] A SOAP message MUST NOT contain PIIIs. A SOAP receiver that receives a message containing a PIII MUST fault with a fault code of env:Sender [scribenrm] DF: Yves...if we remove the "PI" feature do we go back to last call? [DaveO] +1 [DaveO] :-) [scribenrm] Yves: I presume not [mitrepaul] DO: exception for stylesheet PI? [MarkB] I'd be happy with an exception, so would Simon I believe [DaveO] q+ [mitrepaul] Does it imply we add a layer within a SOAP processor to check for PIs; ignore means soap processor does not need to check. [scribenrm] Noah: Proposal "A SOAP message must not contain PIIIs. SOAP receivers (including intermediaries) receiving a message with a PIII should fault with a fault code of env:sender. [Gudge] well, the argument is about what 'ignore' means [mitrepaul] SOAP applications should not rely on PIs [DaveO] q- [scribenrm] The must in the above proposal by Noah is actually a capital MUST [Gudge] and that text replaces the text with 'ignore' in it [mitrepaul] Are we forcing soap implementations to check, or are we telling soap application developers not to send them because soap processor behavior along message path is indeterminate [Gudge] we don't want to force people to check [mitrepaul] i agree [scribenrm] Noah: the spirit of this is...in principle, any PIII is an error. We don't want to slow down high performance SOAP implementations just to make sure that all bogus messages are detected...so that's why the fault detection is a SHOULD not a MUST. [Gudge] we want people to realise that PIs are NOT part of the SOAP processing model [scribenrm] Plus 1 (take that, Zakim) [MarkB] -1+2 ! [mitrepaul] i think zakim just choked :) [MarkB] mu [scribenrm] Noah: ammended proposal. As above, but with a note saying "Whenever possible, receivers should detect PIs and fault. The above rule says SHOULD (as opposed to MUST) only to allow for implementaitons in which performance considerations outweigh the desireability of detecting erroneous messages." [scribenrm] Anish: yes, but what is the semantic of an intermediary that does not fault. [Gudge] is there anyone who CANNOT live with MUST NOT and SHOULD? [scribenrm] DF: we have four options (1) Must not contain, should not fault (2) same, but with Noah's note above (3) MIUST not contain, MUST fault (4) Status quo [scribenrm] DF: Yves, does (3) take us back to last call? [scribenrm] Yves: no, I don't think so. [MarkB] Ow. I'd have to go with #4. [asir] I'll go with #4 [DaveO] I'd go with #2 [MarkB] (or any of the other 3 with an "except for xml-stylesheet" amendment 8-) [scribenrm] DF: option (1) above should say MUST not contain, SHOULD fault (as opposed to SHOULD NOT fault) [MarkB] done! [MarkB] me [scribenrm] Preferences (1) count = 0 (2) count = 11 (3) count = 1 (4) count = 4 [scribenrm] DF: Anyone object to accepting option #2 [scribenrm] Asir: I do [scribenrm] Do we need to go back and get a new resolution? [DavidF_CA] note this is a straw poll and is not a binding vote [scribenrm] No, but I would like my dissent recorded.. (...and it's here in the minutes...) [scribenrm] DF: any objections to resolving 221 with option 2 [mitrepaul] option 2 is okay for me [scribenrm] AGREED: Issue 221 resolved with agreement that messages MUST not contain PIIIIs. Receivers (including) intermediaries SHOULD respond to messages containing EIIII faults. INclude note (see minutes) indicating that exceptions are essentially only for performance reasons. [scribenrm] Accepted with dissent recorded from Web Methods (Asir) [scribenrm] THe fault in the above is env:sender [scribenrm] AGREED (corrected): Issue 221 resolved with agreement that messages MUST not contain PIIIIs. Receivers (including) intermediaries SHOULD respond to messages containing PIIIIs with a env:sender fault. INclude note (see minutes) indicating that exceptions are essentially only for performance reasons. [MarkB] but we decided to punt something to WSA, right? [MarkB] k [scribenrm] DF: No we didn't [scribenrm] DF: well, actually let's consider that a separate issue [scribenrm] ACTION: editors to make change with respect to 221 (agreement that messages MUST not contain PIIIIs. Receivers (including) intermediaries SHOULD respond to messages containing PIIIIs with a env:sender fault. INclude note (see minutes) indicating that exceptions are essentially only for performance reasons.) [scribenrm] ACTION: Rewasa to send response to xmlp comments on resolution of issue 221 [MarkB] aren't you guys hungry? [DavidF_CA] y [scribenrm] ACTION 11 = iwasa to send response to xmlp comments on resolution of issue 221 [DaveO] I went and got lunch already... [scribenrm] With the my apologies to Iwasa for having misspelled his name in the original [scribenrm] ================================================================================== [scribenrm] Lunch break: reconvene at 1:50 PDT [MarkB] I won't be able to return after the lunch break, unless there's a pressing need for me to be there. [Zakim] -DOrchard [Zakim] -MarkB [Zakim] -PaulD [DaveO] Hmm, can we bring up Web Method again? :-) [DavidF_CA] DavidF_CA has joined #xmlprotocol [DavidF2F] preparing to start afternoon session [DavidF2F] issue 230 [Mark_J] Mark_J has joined #xmlprotocol [Anish] Anish has joined #xmlprotocol [scribemjg] =============================== Afternoon Session ==================================== [scribemjg] Issue 230: http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x230 [scribenrm] scribenrm has joined #XMLProtocol [scribemjg] Postponed pending arrival of Glen Daniels on dial-in [scribemjg] Issue 240: http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x240 [herve] herve has joined #xmlprotocol [scribemjg] Comments from P3P WG [scribemjg] Mark Baker discussed with Lorrie Cranor ( of P3P WG ). P3P WG do not feel they have the expertise to define normatively how to put P3P policies into SOAP messages [scribemjg] One suggestion is to forward the request for P3P policy in SOAP messages to the WS-Architecture [scribemjg] General feeling is that someone needs to do the work, but it's probably not going to be P3P or XMLP [scribemjg] </MarkBaker> [scribemjg] <DavidFallside>Our response is going to be, we are not going to define a header for P3P, the work should be done somewhere else</DavidFallside> [scribemjg] <Noah>The requirement seems fairly simple, and I beleive it is possible to do what P3P want</Noah> [scribemjg] <Noah>Essentially, we have met the requirement</Noah> [scribemjg] <Noah>We could work WITH P3P or other WGs to help them define headers ( such as the one P3P want )</Noah> [scribemjg] <DavidFallside>We should draft an e-mail to P3P saying we've met the requirement and that from that POV Issue 240 is closed.</DavidFallside> [scribemjg] <Noah>We respectfully disagree that XMLP WG is required to define a header for P3P</Noah> [scribemjg] <MarkBaker>Don't we need to do a little bit more than just say 'It is possible'</MarkBaker> [scribemjg] <WG>General agreement with Noah's stance</WG> [scribemjg] ACTION: David Fallside to draft e-mail to Lorrie Cantor/P3P along the lines discussed above [scribemjg] As part of response to P3P we will send this to WS Coordination for resolution/delegation to appropriate WG [scribemjg] </Issue240> [scribemjg] <Issue number='241' uri=' http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x241' > [scribemjg] <Noah>What level is this comment at? Infoset level? Binding level?</Noah> [scribemjg] <Asir>Is Joseph asking us to mandate C14N</Asir> [scribemjg] <DavidFallside>Someone could define a binding that mandated C14N</DavidFallside> [scribemjg] <DavidFallside>Is the issue really inserting other XML documents into SOAP messages </DavidFallside> [scribemjg] <MarkBaker>We have mustUnderstand/role etc. that appear on headers. How does an intermediary 'see' the attributes if a header is encrypted</MarkBaker> [DavidF2F] is joseph on w3t irc? [Mark_J] Gudge -- s/MarkJones/MarkBaker/ above [Mark_J] Actually, that's s/MarkBaker/MarkJones/ [scribemjg] <Asir>Looking at the encryption spec ( link [2] ) surely it's up to the serializer to serialize the infoset correctly</Asir> [scribemjg] </Issue> [scribemjg] <Issue number='242' uri=' http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x242' > [noah] Gudge says (earlier): look carefully, we don't use the [prefix [noah] Gudge says (earlier): look carefully, we don't use the [prefix] property on our element info items [noah] ...prefixes in SOAP are an issue only for serializers, such as the HTTP binding. [scribemjg] <DavidFallside>Inappropriate text regarding exit criteria appears in Part 0, Usage Scenarios, Test Collection. Our exit criteria are based on feature implementations</DavidFallside> [noah] Noah: wow, no kidding. I never read it that way. I'm tempted to request we open an issue to at least make this clear. [noah] DF: Noah and Gudge...take it offline, see how far you can get. [scribemjg] <MarkJones>Reason we defined testable assertions was for implementers</MarkJones> [scribemjg] <DavidFallside>Close 242 with. 'No, we are only expecting implementation evidence for Part 1 and Part 2</DavidFallside> [scribemjg] ACTION: David Fallside to write all necessary e-mails for Issue 242 resolution [scribemjg] <Issue number='243' uri=' http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x243' > [scribemjg] <Noah>Do they really mean part 1? Everything in Part 1 is mandatory</Noah> [scribemjg] <Yves>In HTTP there are no implementations that implement all the MUSTs</Yves> [scribemjg] <WG>We need at least two interoperable implementations</WG> [noah] Relating to the earlier discussion of namespaces and canonicalization, http://www.w3.org/TR/xml-c14n#DataModel says: [noah] "XML canonicalization REQUIRES that the XML processor retain sufficient information such that the QName of the element as it appeared in the original document can be provided." [noah] (the context makes very clear that this is saying: prefixes cannot be rewritten) [noah] Of course, this doesn't settle the question of prefixes in soap, just is a datapoint regarding c14n [scribemjg] <DF>Joseph is asking for at least two complete implementation or Part 1 that interoperate</DF> [scribemjg] <DF>If we end up with features that are not implemented, maybe we remove those features from the spec</DF> [scribemjg] <Noah>Need to be careful. Given implementation may only be receiver side or sender side</Noah> [scribemjg] <Herve>We only need one 'super-implementation'</Herve> [scribemjg] <DF>Now wondering what MUST means. Only applies if you play a particular role. If you are a sender you MUST NOT send PIs. If you are a receiver you SHOULD fault. But you may only be one or the other</DF> [scribemjg] <MarkJones>Maybe I only produce client software</MarkJones> [scribemjg] <DF>Proposed Resolution: We intend to take no action. We find the notion of COMPLETE is not well-defined. We will proceed on the basis of implementations of single features</DF> [scribemjg] <Noah>Go a little further. We understand the spirit. But different Senders and receivers have different responsibilities so COMPLETE is relative. We undertake to ensure that multiple implementations do interoperate</Noah> [scribemjg] ACTION: Noah to draft response to Issue 243 and send to WG for approval [scribemjg] </Issue> [scribemjg] <Issue number='246' uri=' http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x246' > [scribemjg] <MarkJones>Intermediaries can look at whatever they like</MarkJones> [scribemjg] <Noah>Things which have SOAP semantics, QNames, soap:role etc are used to determine who gets to do what</Noah> [scribemjg] <Noah>How do we specify a 'global' error that everyone in the message path sees</Noah> [scribemjg] <Anish>what about an intermediary that only encrypts certain QNames</Anish> [scribemjg] <WG>General discussion about what it means to 'look at' or 'act on' given body content</WG> [scribemjg] We could either 1. Allow faults in headers. 2. Special case faults so that intermediaries can process them [scribemjg] <Noah>We ( or someone ) could define an 'IWrapFaults' header</Noah> [scribemjg] <DF>Options: [scribemjg] 1. Status Quo [scribemjg] 2. Allow faults in headers [scribemjg] 3. status quo + fix in some future version [scribemjg] 4. special case faults in body [scribemjg] and what intermediaries can do with such a fault [scribemjg] 5. Remove intermediaries [scribemjg] 3a. Fix it if we have to go back to LC for some other reason [scribemjg] </DF> [scribemjg] <Anish>can someone clarify 2</Anish> [scribemjg] <DF>Faults can only appear in the body right now. We could design something that would allow faults to appear in headers</DF> [scribemjg] Result: 1 - 2, 2 - 0, 3 - 5, 3a - 3, 4 - 0, 5 - 1 [Anish_ca] Anish_ca has joined #xmlprotocol [scribemjg] <DF>Proposal: We resolve issue 246 as follows: We recognise there is a potential problem but it is not by itself significant enough to warrant another last call. If we decide to go back to last call we will reconsider the design for fault handling in body and/or headers. [scribemjg] </DF> [DavidF2F] DavidF2F has joined #xmlprotocol [scribemjg] <DF>Proposal: We resolve issue 246 as follows: We recognise there is a potential problem but it is not by itself significant enough to warrant another last call. If we decide to go back to last call we will reconsider the design for fault handling in body and/or headers. [herve] herve has joined #xmlprotocol [scribemjg] </DF> [Mark_J] Mark_J has joined #xmlprotocol [scribemjg] We recommend that any future version of SOAP consider this issue if it is not resolved by a second last call [scribemjg] status='closed' [scribemjg] ACTION: Volker to send resolution text to xmlp-comments and commentator [scribemjg] </Issue> [scribemjg] === Short break === [DavidF2F] ACTION 15= Volker to send resolution text on issue #246 to xmlp-comments and commentator [scribemjg] <Issue number='249' uri=' http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x249' > [scribemjg] <Asir> Suggests robustness principle doesn't apply to our spec!</Asir> [scribemjg] In some cases, the use of XML technologies allows the flexibility for expressing semantically equivalent statements in a variety of different ways. In order to obtain robust and interoperable implementations it is essential that SOAP [scribemjg] implementations take into account the Robustness Principle as expressed by [RFC 1123] and [RFC 793]: "Be liberal in what you accept, and conservative in what you send". [scribemjg] The robustness principle is applied in several instances within this specification. For example, section 5.2.2 SOAP role Attribute specifies that senders SHOULD NOT send but receiver's MUST accept certain values of the role attribute. [scribemjg] <Asir>It also applies to the media type</Asir> [scribemjg] straw poll: Remove 1.2.2 - 9 Keep 1.2.2 - 0 [scribemjg] resolution of issue 249: Remove section 1.2.2 from the spec [scribemjg] ACTION: Editors to remove section 1.2.2 [scribemjg] ACTION: Mark Jones to write e-mail to xmlp-comments and commentator [scribemjg] <Issue number='250' uri='The robustness principle is applied in several instances within this specification. For example, section 5.2.2 SOAP role Attribute specifies that senders SHOULD NOT send but receiver's MUST accept certain values of the role attribute. [scribemjg] doh! [scribemjg] Issue 250 [scribemjg] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x250 [scribemjg] General feeling that the definitions are inline [scribemjg] <Noah>Can we add text clarifying that these are role names</Noah> [noah] noah has joined #XMLProtocol [noah] This specification defines the following role names which have special significance in a SOAP message (see ref to 6.2) [noah] This specification defines the following role names which have special significance in a SOAP message (see ref to 2.6) [scribemjg] Proposal: Close issue 250 with above text [scribemjg] replace 'With the exception of the three SOAP roles defined above' with 'With the exception of the three SOAP role names listed above' [scribemjg] Issue 250 closed [scribemjg] ACTION: Editors put text into section 2.2: This specification defines the following role names which have special significance in a SOAP message (see ref to 6.2) [scribemjg] ACTION: Gerd to send mail to xmlp-comment and commentator closing issue 250 [scribemjg] <Issue number='251' uri=' http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x251' > [scribemjg] Issue 251 closed as a non-issue [scribemjg] ACTION: Gudge to send mail to xmlp-comments and commentator closing issue 251 [scribemjg] <Issue number='252' uri=' http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x252' > [scribemjg] Closed: Duplicate of issue 241 [scribemjg] </Issue> [scribemjg] ACTION: Carine to update issues list accordingly ;-) [scribemjg] ACTION: Yves to send closing text for issue 252 to xmlp-comments and commentator [scribemjg] <Issue number='254' uri=' http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x254' > [noah] I have sent the draft text to Joseph Reagle for 243 [scribemjg] Could say 'we have asked semantic web the same question' [scribemjg] Could say 'you can use RDF as a serialization given we allow multiple encodings' [scribemjg] Noah: Could say that soap encoding is result of considerable experience in implementing XML based RPC systems [scribemjg] and that we don't have such experience with RDF [scribemjg] <MarkJones>Maybe we don't have an answer because SW know that RDF is not as focussed as SOAP ENC</MarkJones> [scribemjg] Proposal: Close issue 254 with text along the lines of; SOAP encoding is optimized for various applications and has implementation standing in the community. We do not believe that RDF should replace SOAP encoding [scribemjg] Issue 254 is closed with the above resolution [scribemjg] ACTION: Asir to send closing text for Issue 254 to xmlp-comments and commentator [scribemjg] Meeting is extended 30 minutes to 5:30pm [Zakim] -F2Froom [Zakim] WS_XMLP(f2f)12:00PM has ended [scribemjg] <Issue number='263' reason='http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x263'> [scribemjg] http://www.w3.org/TR/REC-xml-names/#ns-decl [scribemjg] Gudge: Not our job to tell people how to serialize xml:lang [scribemjg] Discussion about prefixes in general [scribemjg] Actually 4 issues [scribemjg] 1. put a SHOULD in use of xml:lang [scribemjg] 2. prefix for xml:lang [scribemjg] 3. multiple reason elements [scribemjg] 4. language negotiation [scribemjg] s/2/3 [scribemjg] s/3/ [scribemjg] 2 [scribemjg] all pass the 8-ball test ( will not send us back to LC ) [scribemjg] proposal: Add text to 5.4.2 saying 'The reason element SHOULD carry an xml:lang attribute' [scribemjg] Issue 263.1 - closed with above resolution [scribemjg] proposal: allow reason element to have children which themselves have xml:lang [scribemjg] proposal: allow multiple reason elements each with xml:lang [scribemjg] proposal: allow reason element to have child elements called text. Each text element MUST have distinct xml:lang attributes [anish_ca] anish_ca has joined #xmlprotocol [scribemjg] Issue 263.2 - closed with above resolution [scribemjg] 263.1 is now moot [Mark_J] Mark_J has joined #xmlprotocol [scribemjg] 263.4 - closed. No longer critical with multiple text values. More sophistitcation can be achieved using headers [scribemjg] oops, sorry, not closed yet! [Yves] almost closed [scribemjg] above is proposal [herve] herve has joined #xmlprotocol [scribemjg] 263.4 is closed [scribemjg] 263.3 - proposal: Add text to 5.4.2: 'and has a [prefix] property with the value 'xml' [scribemjg] 263.3 - proposal: Respond with 'No, the serialization of xml:lang is defined elsewhere' [Zakim] Zakim has left #xmlprotocol [scribemjg] Adjourned ==========SUMMARY OF DAY'S ACTION ITEMS============= [RRSAgent] I see 23 open action items: [RRSAgent] ACTION: Herve...to pick up action that had been to HFN and Stuart to fix last sentence, section 2, AF doc [1] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T16-31-00 [RRSAgent] ACTION: Herve to update the document with changes as understood so far [2] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T16-52-10 [RRSAgent] ACTION: Herve to find a description of the feature property issue, so that we can all review the issues. [3] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T17-11-25 [RRSAgent] ACTION: Asir, propose a revision to last paragraph (i.e. not removing point #3) in section 1 of the AF section. [4] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T17-38-53 [RRSAgent] ACTION: Editors, update text for resolution of issue 220...see minutes of PA F2F [5] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T18-12-22 [RRSAgent] ACTION: Editors put resolution text for 228 into spec. [6] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T18-52-59 [RRSAgent] ACTION: Yves Lafon send xmlp comment on 228 [7] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T18-53-27 [RRSAgent] ACTION: Colleen will to sweep spect to make sure spec is clear that bindings can require use of features. [8] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T18-58-54 [RRSAgent] ACTION: Mark Jones to write XMLP comments on issue 227. ALso make clear that it is possilble for a binding to choose to make all features optional. Make sure to include Stuart W., Marc Hadley, MarkB, Jean-Jacques Moreau and Jacek Kopecky [9] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T19-00-38 [RRSAgent] ACTION: editors to make change with respect to 221 (agreement that messages MUST not contain PIIIIs. Receivers (including) intermediaries SHOULD respond to messages containing PIIIIs with a env:sender fault. INclude note (see minutes) indicating that exceptions are essentially only for performance reasons.) [10] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T20-05-05 [RRSAgent] ACTION: iwasa to send response to xmlp comments on resolution of issue 221 [11] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T20-05-59 [RRSAgent] ACTION: David Fallside to draft e-mail to Lorrie Cantor/P3P along the lines discussed above [12] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T21-21-53 [RRSAgent] ACTION: David Fallside to write all necessary e-mails for Issue 242 resolution [13] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T21-43-21 [RRSAgent] ACTION: Noah to draft response to Issue 243 and send to WG for approval [14] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T22-05-51 [RRSAgent] ACTION: Volker to send resolution text on issue #246 to xmlp-comments and commentator [15] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T22-47-54 [RRSAgent] ACTION: Editors to remove section 1.2.2 [16] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T23-26-42 [RRSAgent] ACTION: Mark Jones to write e-mail to xmlp-comments and commentator [17] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T23-26-58 [RRSAgent] ACTION: Editors put text into section 2.2: This specification defines the following role names which have special significance in a SOAP message (see ref to 6.2) [18] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T23-40-29 [RRSAgent] ACTION: Gerd to send mail to xmlp-comment and commentator closing issue 250 [19] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T23-40-50 [RRSAgent] ACTION: Gudge to send mail to xmlp-comments and commentator closing issue 251 [20] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T23-42-48 [RRSAgent] ACTION: Carine to update issues list accordingly ;-) [21] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T23-44-27 [RRSAgent] ACTION: Yves to send closing text for issue 252 to xmlp-comments and commentator [22] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T23-44-56 [RRSAgent] ACTION: Asir to send closing text for Issue 254 to xmlp-comments and commentator [23] [RRSAgent] recorded in http://www.w3.org/2002/07/30-xmlprotocol-irc#T23-58-08