Minutes of XML Protocol WG f2f meeting

SAP Labs, Palo Alto, CA

Day 2, 31 July 2002

Based on IRC logs for 31 July, 1 August

Present:
Asir Vedamuthu, WebMethods
Yves Lafon, W3C
Martin Gudgin, Microsoft
Colleen Evans, Progress (scribe, p.m.)
Carine Bournez, W3C
Noah Mendelsohn, IBM
David Fallside, IBM (chair)
Volker Wiechers, SAP
Anish Karmarkar, Oracle (scribe, a.m.)
Herve Ruellan, Canon
Gerd Hoelzing, SAP
Ryuji Inoue, Matsushita
Kazunori Iwasa, Fujitsu
Mark Jones, ATT

Present by Phone (Partial):
Mark Baker, Idokorro
Glen Daniels, Macromedia

Excused:
Camilo Arbelaez, webMethods 
John Ibbotson, IBM 
Henrik Nielsen, Microsoft 
Jeff Mischkinsky, Oracle
Jean-Jacques Moreau, CanonResearchCentreFrance 
Paul Cotton, Microsoft 
Michah Lerner, ATT
Masahiko Narita, Fujitsu

Regrets:
Highland Mountain, Intel 
Pete Wenzel, SeeBeyond 
David Orchard, BEASystems
Paul Denning, MITRE
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:
Jin Yu, MArtsoft
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

[RRSAgent] RRSAgent has joined #xmlprotocol 
[GlenD] hi :) and hokey dokey 
[Yves] zakim, this is xmlp 
[Zakim] sorry, Yves, I do not see a conference named 'xmlp' 
[Yves] zakim, this will be xmlp 
[Zakim] ok, Yves 
[GlenD] silly time restricted conferences 
[Yves] yep :/ 
[GlenD] My apologies, btw, I haven't had time to finish wording on #219 yet. Looking at it now. 
[GlenD] The problem of course is defining what a module actually is.... 
[DavidF2F] DavidF2F has joined #xmlprotocol 
[Mark_J] Mark_J has joined #xmlprotocol 
[GlenD] How about: 
[GlenD] "The term "SOAP Module" refers to the set of syntax and semantics associated with implementing a
particular piece of functionality as SOAP headers, generally described in a Module Specification. 
[GlenD] (perhaps insert "and is" before "generally described") 
[herve] herve has joined #xmlprotocol 
[scribemjg] scribemjg has joined #xmlprotocol 
[carine] "piece of functionality" has been removed from text (issue 211) 
[carine] not sure it's a good idea to introduce it somewhere else 
[GlenD] hm 
[GlenD] ...associated with implementing a particular extension of the SOAP messaging framework...? 
[GlenD] yuk 
[anish_ca] anish_ca has joined #xmlprotocol 
[GlenD] I hope we say somewhere what "an extension of the SOAP messaging framework" means.... 
[GlenD] I guess we do in 3.1 
[carine] it's a SOAP feature :) 
[GlenD] yup 
[GlenD] The thing I'm trying to avoid is the necessity of a Module writer to come up with a separate URI for a
Feature which the Module implements in order to write the spec. 
[carine] wht not using "implementing a particular SOAP feature? 
[reagleHOM] reagleHOM has joined #xmlprotocol 
[reagleHOM] howdy 
[asir] asir has joined #xmlprotocol 
[reagleHOM] Yves, what was the URI to the issue again? 
[Gudge] Hi Joseph 
[GlenD] While one common pattern is going to be two specs - an abstract Feature spec and a concrete Module spec
which implements that Feature - I don't think that's necessary. 
[colleen] colleen has joined #xmlprotocol 
[Yves] joseph: http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x241 
[Yves] would you be around in the next hour or two? 
[Zakim] WS_XMLP(f2f)12:00PM has now started 
[noah] noah has joined #XMLProtocol 
[Zakim] +G_Daniels 
[Zakim] + +1.650.849.aaaa 
[Yves] zakim, code XMLPF 
[Zakim] I don't understand 'code XMLPF', Yves. Try /msg Zakim help 
[Gudge] zakin, aaaa is F2FRoom 
[reagleHOM] Yves, I'm sort of around... plan on lunch soon, what are you proposing? Do you have a call coming up?
[Gudge] zakim, aaaa is F2FRoom 
[Zakim] +F2FRoom; got it 
[Yves] we plan to tackle Glen's issue first 
[Yves] if yuo're around after lunch, it would be nice 
[GlenD] brb! (2 min) 
[GlenD] back 
[GlenD] it's a bit static-y, some people come through better than others 
[scribe_ak] Noah presents the changes to the AF doc 
[scribe_ak] Noah: key features - purpose it to allow someone to create bindings and not features 
[scribe_ak] Noah: changes made to terminology section: "secondary parts are also referred to as attachments" 
[herve] Noah's edited version is at:
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Jul/att-0160/01-SOAP_1_2_Attachment_Feature_Noah_Asir.htm 
[scribe_ak] Mark_J: do we define part at this point in the doc? 
[scribe_ak] Mark_J: does 'data stream' to skirt calling it encapsulation? Or what is the sum and substance of
everything that travel together? 
[scribe_ak] Noah: 
[scribe_ak] more discussion about 'data stream' between Mark and Noah....
[scribe_ak] DF: Suggestion - this doc should be published as WD. We should then take this WD to LC WD. 
[scribe_ak] Noah: Glen found typos in the abstract which were fixed. 
[scribe_ak] Asir: issue about consistent use of the word 'Message' 
[scribe_ak] Noah: I found the following sentence baffling in section 6: "Note that in some cases, an
encapsulation mechanism may also provide the functionality of the underlying protocol, but this is not a
requirement. 
[scribe_ak] Mark: suggested change - Note that in some cases, the underlying protocol may also provide the
functionality of the encapsulation mechanism 
[scribe_ak] DF: To wrap up - couple of more ed. changes. We pretty much agreed to Noah's changes. 
[scribe_ak] Asir: Last sentence in section 3 - it might be easier to replace it with "informally secondary parts
are referred to as attachments" 
[scribe_ak] Asir: removing the "also" would be useful as well. 
[scribe_ak] DF: is 'data stream' ok? 
[noah] noah has joined #XMLProtocol 
[scribe_ak] DF: suggestion - get all the changes that we discussed, incorporate those in another version tonight.
Tomorrow we will make a decision to publish the doc as a WD. We also send an email to the member ML that we are
going to do this. 
[scribe_ak] DF: if we get a 'yes' for publishing the WD, then Herve please work with Yves to get it published as
a WD 
[noah] zakim, who is here? 
[Zakim] On the phone I see F2FRoom, G_Daniels 
[Zakim] On IRC I see noah, colleen, asir, reagleHOM, scribe_ak, Gudge, herve, Mark_J, DavidF2F, RRSAgent, Zakim,
GlenD, HFN_away, MarkB, carine, Loggy, Yves 
[GlenD] "The term "SOAP Module" refers to the set of syntax and semantics associated with implementing a
particular piece of functionality as SOAP headers, generally described in a Module Specification. 
[scribe_ak] discussion on issue 219....
[Yves] attendance: 
[noah] Did we minute the possible concern that the SOAP Rec itself is inconsistent in the definition of the word
message? 
[scribe_ak] issue 219 - http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x219 
[Yves] Colleen Evans, 
[Yves] Mark Jones, Anish Karmarkar, Kazunori Iwasa, Ryuji Inoue, Noah Mendelsohn 
[scribe_ak] scribe - Noah, the concern was noted only for the AF doc, but it should be noted for the SOAP spec
itself as well 
[Yves] Asir Vedamuthu, Gerd Hoelzing, Herve Ruellan, Volker Wiechers 
[Yves] Carine Bournez, Yves Lafon, Marting Gudgin, David Fallside 
[Yves] GLend Daniels (remotely) 
[Yves] s/nd/n/ 
[scribe_ak] Glen: Modules are about headers. 
[scribe_ak] Noah: I agree with Glen. We talk about features and talk about Modules are being embodiment of
features. 
[scribe_ak] Noah: clearly an intermediary can do things that are not defined in the header, but it is not in the
architecture. 
[scribe_ak] Noah: Is it a weakness of our arch., but independent of modules. 
[scribe_ak] Mark: not ever module inserts a header (could consume one) 
[GlenD] +q 
[GlenD] q+ 
[scribe_ak] Glen: another comment - another example is that an intermediary at the boundary of an enterprize, and
can restrict what headers are allowed. 
[scribe_ak] Glen: we don't want to say anything about it. 
[scribe_ak] Mark: It seems strange not to say anything about it. We should at least ack. that such a thing may
exist 
[scribe_ak] Glen: I don't have a problem 'ack'ing such a scenario. 
[scribe_ak] DF: Glen when will we see the text? 
[scribe_ak] Glen: a few minutes. 
[Zakim] +Reagle 
[anish_ak] I won't be able to make it to the impl. con call at 10 
[anish_ak] nick scribe_ak 
[Yves] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x241 
[Zakim] -G_Daniels 
[scribe_ak] JosephR explains issue 241....
[scribe_ak] JosephR: problems - default namespace, xml:base when inserting/deleting fragments. 
[scribe_ak] Noah: My question is what is SOAP's responsibility in dealing with this. SOAP is a wire format. 
[scribe_ak] Noah: An intermediary can remove a header, but all it's children are removed as well. 
[scribe_ak] Noah: one exception is that SOAP allows one to do some things such as signing - an intermediary can
take in a soap message and encrypt/sign specific parts. So designer of such intermediary would be well adviced
to take your concerns into account. 
[scribe_ak] JosephR: I can accept the arg that this is out of scope for SOAP to specify, but some verbage/warning
about these issue would not hurt. 
[reagleHOM] http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/Overview#sec-Serializing-XML 
[reagleHOM] http://www.w3.org/Signature/Drafts/xml-exc-c14n.html#sec-Considerations 
[scribe_ak] DF: our mission was to allow people to build additional features. The general concern is that we
don't want our document to contain warnings for all possible scenarios. Is this a fundamental issue? 
[scribe_ak] JosephR: I understand your argument, but I think it is important to a lot of applications. 
[JacekK] JacekK has joined #xmlprotocol 
[Zakim] -Reagle 
[scribe_ak] DF: we will take it under advisement and we will provide you with a response. We think that we do
understand your concern 
[noah] I think we should note that Joseph's concern center on constructs such as default namespaces, xml base,
etc. and warnings that may be needed when inserting/deleting parts of the document 
[noah] zakim, who is here? 
[Zakim] On the phone I see F2FRoom 
[Zakim] On IRC I see JacekK, noah, colleen, reagleHOM, scribe_ak, herve, Mark_J, DavidF2F, RRSAgent, Zakim,
GlenD, HFN_away, MarkB, carine, Loggy, Yves 
[scribe_ak] Scribe: Noah - that concern has been noted in IRC. 
[scribe_ak] discussion of what to do with issue 241....
[scribe_ak] issue about should prefixes be made part of our infoset....
[noah] Right, the prefix issue is the one that Gudge and I have been asked to discuss, and that the WG will
bring up when David puts it on the agenda 
[scribe_ak] DF: proposal - we maintain status quo and do not make any changes to the spec. 
[scribe_ak] Colleen: should we put this in the primer? 
[reagleHOM] reagleHOM has left #xmlprotocol 
[scribe_ak] Mark: do we have an example in the primer where a header gets padded in the primer? 
[scribe_ak] DF: Any object to closing 241 by doing nothing? 
[scribe_ak] s/object/objection 
[scribe_ak] no objection
[scribe_ak] Action: Carine to send email to xlmpcomment and cc Joseph wrt issue 241 
[Yves] ACTION: Carine to send email to xlmpcomment and cc Joseph wrt ssue 241 
[scribe_ak] ===== beak until 10:45 PDT ===== 
[scribe_ak] DF: please look at Glen's text during the break. 
[scribe_ak] zakim, who is on the phone 
[Zakim] I don't understand 'who is on the phone', scribe_ak. Try /msg Zakim help 
[scribe_ak] zakim, who is on the phone? 
[Zakim] On the phone I see F2FRoom 
[DaveO] DaveO has joined #xmlprotocol 
[scribe_ak] === break is over, we are back === 
[scribe_ak] ==== Issue 263 ====
[scribe_ak] DF: since Gudge is not here, lets postpone 263 till he is back 
[scribe_ak] DF: I have the response for P3P's comments 
[scribe_ak] response at http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Jul/0155.html 
[scribe_ak] agreement on the text - modulo typos
[scribe_ak] ==== Issue 266 ====
[Yves] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x266 
[scribe_ak] DF: one option is to go back and allow mixed content in the encoding and the other option is to say
that this is optional and not meant to do everything. 
[scribe_ak] MarkJ: programming languages were the driving force for soap data model. 
[asir] asir has joined #xmlprotocol 
[scribe_ak] Asir: Mixed content is a XML concept and I don't see why we should put this in soap datamodel 
[Gudge] Gudge has joined #xmlprotocol 
[scribe_ak] Noah: we should not be too insensitive to this concern. I don't know how much of a problem this is. 
[scribe_ak] Noah: This might be a problem with Ruby. 
[scribe_ak] Gudge: I am concerned as to what the graph will look like with mixed content 
[scribe_ak] Noah: This might be a bigger problem, i.e, they may want attributes which soap encoding disallows. 
[scribe_ak] MarkJ: I don't see why soap datamodel should be applicable for all possible cases 
[noah] http://www.w3.org/TR/ruby/ 
[scribe_ak] Asir: Why is Ruby is concern? 
[scribe_ak] Gudge: Ruby allows one to annotate text/sub-part/sentence 
[scribe_ak] MarkJ: Ruby can be mapped to something like a "struct" 
[scribe_ak] general discussion about Ruby and soap encoding
[scribe_ak] Noah: Is Ruby the right example? 
[scribe_ak] Gudge: Ruby has attributes that we don't allow 
[scribe_ak] Gudge: we can come up with work arounds/mappings, but I18N may want mixed content as a first class
citizen 
[scribe_ak] Noah: concern - how much of a restriction is this? 
[scribe_ak] DF: 2 options - we go back to I18N and say we created soap encoding which is limited and we are going
to stick with it. It is not a generalized scheme. Other option is to go back to I18N and have more
discussion/negotiation and make sure that we got this right and understand if it is a
'lie-in-the-middle-of-the-road' issue. 
[scribe_ak] Gerd: We could say that this is not a part of our requirements. Is it part of our charter? 
[scribe_ak] DF: reads the relevant part of the charter
[scribe_ak] Noah: we could say something like - this is legitimate concern, but this has been implemented by
plenty of implementations and such changes cannot be handled by these implementation. Further more, SOAP is
designed to carry pretty much anything. 
[Zakim] +G_Daniels 
[scribe_ak] MarkJ: we could move this requirement to the next version. 
[scribe_ak] DF: Proposal - we close this issue by doing nothing and we write a carefully worded response to I18N.
[scribe_ak] DF: the response would contain something like - we have a specialized target for the encoding and the
implementations that exist in that environment. 
[scribe_ak] DF: we should also include the fact that soap encoding is optional and other encodings are possible. 
[scribe_ak] no objection from the WG
[scribe_ak] DF: issue 266 is closed 
[scribe_ak] ACTION: DavidF to draft a response for issue 266 and bring it back to the WG 
[scribe_ak] ==== Issue 267 ====
[scribe_ak] s/267/268 
[herve] herve has joined #xmlprotocol 
[scribe_ak] MarkJ: in this case, there is no recourse 
[scribe_ak] DF: does Ruby apply here again? 
[scribe_ak] Herve: in our spec inbound messages and outbound messages are not typed 
[scribe_ak] DF: why do we say property values are simple types? 
[scribe_ak] Noah: IMO this is a bug 
[scribe_ak] Gudge: the reason for using QNames is so that they are unique 
[scribe_ak] Noah: the reason for using types was so that we do not reinvent the wheel 
[scribe_ak] Gudge: Why don't we say "where appropriate properties should have a xml simple type" 
[scribe_ak] Glen: why should it be simple? 
[scribe_ak] Gudge: ok. remove 'simple' 
[Gudge] Proposal: Change second bullet to read 'Where appropriate properties should have an XML Schema type' 
[DavidF2F] DavidF2F has joined #xmlprotocol 
[Gudge] Proposal: And update our property tables to include a Type column 
[Gudge] Proposal: Change second bullet to read 'Where appropriate properties should have an XML Schema type' 
[Gudge] Proposal: Change second bullet of Part 2 5.1.1 to read 'Where appropriate properties should have an XML
Schema type' 
[Gudge] Proposal: And update our property tables to include a Type column 
[scribe_ak] DF: any discussion on the proposal? 
[colleen] colleen has joined #xmlprotocol 
[Mark_J] Mark_J has joined #xmlprotocol 
[scribe_ak] DF: proposal is to change the spec to what is in IRC and close issue 266 by saying that we do not
limit property types to xml schema simple types. 
[scribe_ak] DF: any objections? 
[scribe_ak] DF: issue 268 is closed. 
[scribe_ak] ACTION: Gudge to send a response for issue 268 
[scribe_ak] ACTION: editors to make the changes proposed for resolving issue 268 
[scribe_ak] ==== Issue 257 ====
[scribe_ak] DF: Nilo is going to fix all the ed. issue. For issue that lie in the grey area, he will bring it
back to the WG with suggestions. 
[scribe_ak] DF: issue 257 is such a issue, so we will not deal with it right now. 
[scribe_ak] DF: issue 259 is also editorial 
[scribe_ak] ==== Issue 267 ====
[scribe_ak] ACTION: editors to resolve issue 267 with ed. changed 
[scribe_ak] ==== Issue 269 ====
[scribe_ak] DF: suggestion - someone send an email to Martin to get a clarification as to what issue 269 exactly
is 
[scribe_ak] ACTION: Noah to send an email to Martin and get a clarification on issue 269 and 'cc' distapp 
[scribe_ak] ==== Issue 270 ====
[asir] asir has joined #xmlprotocol 
[asir] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Apr/0112.html 
[scribe_ak] Asir: the last 2 subissues in 270 are not covered in the URL that I posted to IRC 
[Glen-brb] You guys are lunching 12:30-1:30PDT? 
[scribe_ak] Asir: 2nd last subissue is editorial 
[scribe_ak] Asir: the last subissue is also editorial 
[Yves] glen: that's the original plan, we will soon know if the plan will be applied ;) 
[scribe_ak] ACTION: editors to take on the last 2 items in issue 270 
[scribe_ak] ACTION: editors to use the URL posted by Asir in IRC as the starting point for the editorial changes
to appendix A (issue 270) 
[scribe_ak] ==== Issue 263 ====
[scribe_ak] Noah: if we want to support prefixes then we will have to scan the complete spec 
[scribe_ak] Gudge: We only need to only support namespace decl. 
[scribe_ak] Gudge: we don't need to say anything about prefixes except xml 
[scribe_ak] discussion between Noah and Gudge about preserving prefixes....
[asir] http://www.w3.org/XML/xml-names-19990114-errata#NE05 - No other prefix may be bound to this namespace name
- applies to XML 1.0 
[scribe_yl] gudge: answering 263 can be only "prefix of lang must be xml:" 
[scribe_yl] markJ: what is the problem in saying that intermediaries should rpeserve the prefix? 
[scribe_yl] gudge: we will have to care with default declaration namespaces 
[scribe_yl] asir: return value in rpc struct needs prefix 
[MGudgin] MGudgin has joined #xmlprotocol 
[scribe_yl] noah: are the prefixes signed in dsig? 
[scribe_yl] option 1 : intermediaries preserv prefixes 
[scribe_yl] option 2 : prefixes are not significant, so no need say what to do with them 
[scribe_yl] straw poll: preservation 3 
[scribe_yl] straw poll: non-significant 4 
[scribe_yl] couldn't live with 1: 0 
[Gudge] Gudge has joined #xmlprotocol 
[scribe_yl] couldn't live with 2: 0.5 
[scribe_yl] decision: go with "preserve" option 
[scribe_yl] resolution B is above 
[scribe_yl] resolution A is acnkowledge prefix existence in infoset 
[scribe_yl] resolution C prefix of lang must be xml: per namespaces in XML errata #5 
[scribe_yl] the resolution of part2 is reason with multiple text elements with different xml:lang 
[scribe_yl] part 4: conneg is out of scope for us 
[scribe_yl] 2 solves the problem of xml:lang optional 
[scribe_yl] 263 is closed with the proposed resolution 
[scribe_yl] ACTION: Inoue san to send resolution text to xmlp-comments (Cc: martin) to close issue 263 
[scribe_yl] ====break for lunch======
[Zakim] -G_Daniels 
[MarkB] what time does work resume? 
[GlenD] GlenD has joined #xmlprotocol 
[DavidF2F] DavidF2F has joined #xmlprotocol 
[DavidF2F] resuming in a couple of minutes 
[Zakim] +GlenD 
[DavidF2F] DavidF2F has joined #xmlprotocol 
[DavidF2F] zakim, who is here? 
[Zakim] On the phone I see F2FRoom, GlenD 
[Zakim] On IRC I see DavidF2F, GlenD, Gudge, RRSAgent, Zakim, HFN_away, MarkB, carine, Loggy, scribe_yl 
[colleen] colleen has joined #xmlprotocol 
[Zakim] +MarkB 
[herve] herve has joined #xmlprotocol 
[scribe_ce] === back from lunch == 
[scribe_ce] ==== issue 219 ====
[DavidF2F] http://www.w3.org/TR/ruby/ 
[Gudge] zakim, who's talking? 
[Zakim] Gudge, listening for 14 seconds I heard sound from the following: GlenD (82%), F2FRoom (20%) 
[DavidF2F] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Jul/0163.html 
[scribe_ce] considering Glen's proposed resolution text at above URL 
[scribe_ce] Two parts. Discussion on first part re wording in 3.1 regarding modules. 
[scribe_ce] DF: would people be happy with these two proposed changes? 
[scribe_ce] Glen: concern regarding interpretation that two URIs or two complete specs required 
[asir] asir has joined #xmlprotocol 
[scribe_ce] VW: Should SOAP headers be SOAP header blocks in proposed text? 
[scribe_ce] follow on email from Glen at
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Jul/0163.html 
[scribe_ce] DF: close 219 with three proposed text changes proposed in Glen's email 163 
[scribe_ce] no objection
[scribe_ce] ACTION: Glen to send closing text on issue 219 
[scribe_ce] ACTION: editors to incorporate the text for issue 219 
[scribe_ce] ==== issue 230 ====
[scribe_ce] Glen: proposal to add line stating a feature has to have a URI 
[scribe_ce] Glen: applicable section is 3.1.1 
[scribe_ce] DF: proposal to take enumerated first bullet out of 3.2 and copy into enumerated list in 3.1.1
changing module to feature and possibly some other gramatical changes to make it fit. 
[scribe_ce] DF: any objection to closing issue 230 with that resolution? 
[scribe_ce] no objection
[scribe_ce] ACTION: Glen to send resolution text to xmlp comment for 230 
[scribe_ce] ACTION: editors to incorporate text changes for 230 
[asir] asir has joined #xmlprotocol 
[scribe_ce] == WS Arch comments == 
[scribe_ce] === issue 329 ===
[DavidF2F] http://www.w3.org/2000/xp/Group/xmlp-lc-issues#x329 
[Gudge] http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0087.html 
[scribe_ce] Noah: posted email with response to this issue 
[scribe_ce] DF: Is there a clarification that would be useful to add to the processing model? 
[Gudge] Section 2.6: http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#procsoapmsgs 
[Gudge] Bullet 3: If one or more of the header blocks identified in the preceding step are not understood by
the node then generate a single SOAP fault with the Value of Code set to "env:MustUnderstand" (see 5.4.8 SOAP
mustUnderstand Faults). If such a fault is generated, any further processing MUST NOT be done. Faults relating
to the contents of the body MUST NOT be generated in this step. 
[Gudge] mustunderstand faults are at http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#mufault 
[Gudge] <env:Header>
[Gudge] <flt:Misunderstood qname='abc:Extension1' 
[Gudge] xmlns:abc='http://example.org/2001/06/ext' />
[Gudge] <flt:Misunderstood qname='def:Extension2' 
[Gudge] xmlns:def='http://example.com/stuff' />
[Gudge] </env:Header>
[noah] noah has joined #XMLProtocol 
[scribe_ce] MarkJ: so we allow it, we don't prescribe it 
[scribe_ce] Noah: it's working as designed - only question is whether there's anything editorial to do. 
[scribe_ce] DF: Propose resolution to issue is to point to Noah's email, endorsing it. 
[scribe_ce] no objection
[scribe_ce] ACTON: Volker will send closing email for issue 329 referencing first part of Noah's email. 
[Mark_J] Mark_J has joined #xmlprotocol 
[scribe_ce] ==== Issue 330 ====
[Yves] ACTION: Volker will send closing email for issue 329 referencingfirst part of Noah's email. 
[Yves] ACTION 14= Volker will send closing email for issue 329 referencing first part of Noah's email. 
[scribe_ce] Noah: this particular layering of the approach is intentionally there rather than by oversight -
discussed at length in the WG a year or so ago 
[scribe_ce] DF: proposal to respond to issue 330 saying we are closing without action. Reference the second part
of Noah's xmlp comment email above. Add statement that design is explicit following discussion on concept
'mustHappen'. 
[scribe_ce] DF: mustHappen mechanism could be embodied in a header which would work along side the existing mU
mechanism in the spec. 
[scribe_ce] no objections
[scribe_ce] ACTION: Volker will send email to xml comments closing issue 330. 
[scribe_ce] ==== Issue 331 ====
[scribe_ce] Glen: we can pull out related text in 3.3 since it will be covered in the features 
[Zakim] -MarkB 
[scribe_ce] MarkJ: should 'in general' be deleted 
[scribe_ce] agreed 
[scribe_ce] Noah: take out URI bullet as it will be covered in features (make MUST under feature) 
[scribe_ce] MarkJ and Noah: redundantly do it here too 
[scribe_ce] Noah: an MEP as a feature must follow all the rules of the features (for example, must be named by a
URI)... 
[scribe_ce] Noah: delete first bullet in section 3.3, remove 'in general'. 
[scribe_ce] ACTION: Editors clarify that specifications for MEPs inherit requirements for features. 
[scribe_ce] ACTION 16 = Editors clarify that specifications for MEPs inherit requirements for features. Also note
text in 3.1.1 sub 4. 
[scribe_ce] DF: propose to close 331 by stating that per clarification of the spec and our resolution to issue
230, we now state that MEPs are identified by URIs 
[scribe_ce] no objections
[scribe_ce] ACTION: Gerd will send note to xmlp comment and cc mike champion to close 321 
[scribe_ce] ==== issue 332 ====
[scribe_ce] Gudge: we discussed, it's application defined 
[scribe_ce] Noah: we have work on attachments that could apply here...point out we're actively working on
something in this space. 
[scribe_ce] DF: proposal we close by responding that where external references are to attachments we actvely
have work ongoing. 
[scribe_ce] no objections
[scribe_ce] ACTION: Colleen will send note to xmlp comment closing issue 332 
[scribe_ce] MarkJ: do these responses go to WS-A as a whole or to individuals? 
[scribe_ce] DF: Just copy Mike Champion and he can gateway the WS-A mailing list. 
[scribe_ce] ==== issue 333 ====
[scribe_ce] Noah: appears what they object to where we QNames as content, e.g. fault code declared as a QName in
section 5.4.6. Just capitulate and make them URIs. 
[scribe_ce] Gudge: the TAG finding referenced in the email seems fine. Accepts it is reasonable to use QNames in
a string. 
[scribe_ce] MarkJ: does it make other things we've done (e.g., None) more consistent if we use URIs? 
[scribe_ce] DF: proposal is to close issue 333 by taking no action - maintain status quo. 
[scribe_ce] no objections
[scribe_ce] ACTION: Colleen will send email to xmlp comments cc Mike Champion closing issue 333, referencing
draft tag findings that it's okay to use QNames in this way. 
[Gudge] Tag finding conclusion is at http://www.w3.org/2001/tag/doc/qnameids.html#sec-archrec 
[scribe_ce] ==== issue 336 ====
[carine] it's related to issue 358 
[scribe_ce] Yves: Not just a SOAP context. Many implementations of proxies have this issue. 
[scribe_ce] MarkJ: is the issue that it should handle URIs of arbitrary lengths (rather than 2048 chars)? 
[scribe_ce] Yves: this indication is in the context of deployment of HTTP software. 
[scribe_ce] DF: encouraged to handle URIs of arbitrary length SHOULD in any case be able to deal with URIs 2048
chars in length. 
[scribe_ce] DF: proposal that we close 336 without changing our spec and we believe that the spec in its current
form provides the appropriate motivation for handling arbitrary length URIs 
[scribe_ce] no objection
[scribe_ce] ACTION: MarkJ to send email to xmlp comment and cc Mike Champion closing issue 336. 
[Zakim] -GlenD 
[GlenD] Good luck with the rest of the day, folks 
[Mark_J] Mark_J has joined #xmlprotocol 
[DavidF2F] DavidF2F has joined #xmlprotocol 
[scribe_ce] scribe_ce has joined #xmlprotocol 
[scribe_ce] DF: attachment feature doc updated draft sent to the WG this afternoon. Unless we get substantive
comments back, we'll send to w3c as a WD. 
[scribe_ce] ==== Issue 338 ====
[scribe_ce] DF: two questions in this issue related to state. Regarding the first, should they be separate
states? Or should the condition for init be modified? 
[scribe_ce] MarkJ: does this also apply at an intermediary? 
[scribe_ce] DF: when we designed these was it done to handle case of streaming, in which case we don't say
they're sequential or imply time constraints? 
[herve] herve has joined #xmlprotocol 
[scribe_ce] Noah: what are the criteria we apply about when state changes or not? 
[scribe_ce] DF: three proposals: (1) message exchange context initialized, control passed to local binding
instance (2) transition condition is the initiation of the transmission (3) status quo 
[scribe_ce] Noah: state is split because actions are on arcs? 
[scribe_ce] Yves: way to read the table: if condition, go to next state and perform the action 
[scribe_ce] MarkJ: boolean condition that gates your leaving a state 
[scribe_ce] MarkJ: precondition to go to requesting state is existence of the beginning of the message (in
streaming) 
[scribe_ce] DF: proposal transition condition in init state from 'unconditional' to 'initialization of message
transmission' 
[scribe_ce] Yves: counter proposal to maintain status quo 
[scribe_ce] Yves: streaming and timing issues, when we start to send a request, have errors, etc. 
[scribe_ce] MarkJ: two questions - what to put in the box and how to explain unconditional to those who don't
understand our usage of it. 
[scribe_ce] no objection to proposal for maintaining status quo in table 
[scribe_ce] ACTION: Asir to send email to xmlp comment and cc Mike Champion to close issue 338 by taking no
action. 
[scribe_ce] ==== Issue 342 ====
[scribe_ce] ! 
[scribe_ce] ==== Continue with second part of issue 338 ====
[scribe_ce] Noah: the first sentence is backwards 
[scribe_ce] Yves: state table indicates transmission failure goes to fail state 
[scribe_ce] discussion of three interpretations of problem scenario 
[scribe_ce] Noah: once responder has started sending a response, is it clear what to do if you later decide you
don't like the request (streaming scenario)? Is there something in state machine? 
[scribe_ce] Yves: go to fail mode and send fault 
[scribe_ce] Noah: but fault should be ruled out in this case because responder started sending a successful soap
response and in the middle aborted. 
[scribe_ce] change last bullet "A requesting SOAP node MAY enter the Fail state, and thus abort transmission of
the outbound SOAP request, based on information contained in an incoming streamed SOAP response. 
[scribe_ce] correction to proposed change above: change to "A requesting or responding SOAP node...."
[anish_ca] anish_ca has joined #xmlprotocol
[scribe_ce] MarkJ: responding SOAP node doesn't switch from sending response to sending a fault - just goes to
fail and requesting soap node doesn't issue a fault, just aborts and goes to fail.
[carine] responding SOAP node doesn't switch from sending response
[carine] to sending a fault - just goes to fail and requesting soap node 
[carine] oops
[scribe_ce] Noah: can you report a binding level error as a soap fault? 
[scribe_ce] Noah: if the answer is yes, do we have something in the MEP that the requestor gets to send out one
soap message, and the responder gets to send out one soap message. Neither can send 2 messages so if they've
already initiated one they can't start a fault 
[scribe_ce] MarkJ: table 20 has binding generated faults 
[scribe_ce] VW: 6.2.4 third paragraph "This MEP makes no claims about the disposition or handling of SOAP faults
generated by the requesting SOAP node during any processing of the response message that follows the Success
state in the requesting SOAP node's state transition table " 
[scribe_ce] MarkJ: table 20 binding generated faults are not SOAP faults. Suggests that binding level stuff isn't
going to result in a soap fault but rather a binding level fault. 
[scribe_ce] Noah: State diagram responds to the first question in the second part of issue 338 (responding node
sending a fault) 
[scribe_ce] DF: Proposal, no to first question in second part of issue 338. 
[scribe_ce] DF: proposal re second question in second part of issue 338 the situations in which a response
results in a soap fault generated from the requestor are already specified. 
[scribe_ce] Noah: generate a fault if and only if the 'normal' soap rules say generate a fault. Even if you
generate a fault, there no conformance requirements that say it needs to be transmitted (ref section y6.2.4) 
[scribe_ce] Noah: same case as if not streaming 
[Yves] wrt init state, see http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/0262.html 
[Yves] ACTION 21= Asir to draft email to xmlp comment to close issue 338 by taking no action. 
[carine] zakim, who's here 
[Zakim] carine, you need to end that query with '?' 
[carine] zakim, who's here? 
[Zakim] On the phone I see F2FRoom 
[Zakim] On IRC I see anish_ca, herve, scribe_ce, DavidF2F, Mark_J, asir, Gudge, RRSAgent, Zakim, HFN_away,
MarkB, carine, Loggy, Yves 
[Zakim] -F2FRoom 
[Zakim] WS_XMLP(f2f)12:00PM has ended 
[noah] noah has joined #XMLProtocol 
[noah] test 
[scribe_ce] ==== issue 342 ====
[Yves] wrt init state (issue 338 part 1) real URI is
http://lists.w3.org/Archives/Public/www-archive/2002Apr/0041.html 
[noah] Before table 17: The SOAP HTTP binding follows the rules of any HTTP application which means that an
implementation of the SOAP HTTP binding must understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the
exception that an unrecognized response must not be cached. 
[MarkB] right 
[Gudge] right what? 
[MarkB] was that a proposal? 
[carine] it seems to be already in the editors'copy 
[scribe_ce] Herves: reference paragraph before table 17 - missing in lc draft 
[scribe_ce] oops - Herve sorry 
[scribe_ce] Gudge: issue 224 resolved to remove the text - issue 342 is a dupe 
[MarkB] re 338 - it's moot because we just forgot to include text in the lc draft? 
[carine] s/remove/add 
[scribe_ce] df: proposal to close 342 as a dupe 
[scribe_ce] ACTION: Asir will send email to originator indicating this is handled as a dupe. 
[scribe_ce] ==== issues 348 and 349 go to Nilo ====
[scribe_ce] ==== issue 339 ====
[MarkB] oops, never mind 338 question, I meant 342. doh. 
[scribe_ce] Yves and Gudge: a binding generated fault not a soap generated fault 
[scribe_ce] df: inconsistency between tables 20 and 23 
[scribe_ce] Herve: two kinds of malformed message, one at the binding level and one at the soap level 
[scribe_ce] ACTION: Herve look at section 7.5.2 and come back tomorrow with interpretation / clarification for
the group 
[scribe_ce] ACTION 23 = Herve to look at 7.5.2 and come back tomorrow to the group with interpretation to
understand context of issue 339. 
[scribe_ce] ==== Issue 340 ====
[Yves] herve: see http://www.w3.org/2000/xp/Group/xmlp-issues#x196 
[Yves] issue 338 again http://lists.w3.org/Archives/Public/xml-dist-app/2002Apr/thread.html#197 
[MarkB] break time? 
[Yves] adjourned 
[Yves] so the break will be of several hours ;) 
[MarkB] cool 
[MarkB] talk to you tomorrow then 

======= SUMMARY OF DAY'S ACTION ITEMS ============
[RRSAgent] I see 23 open action items: 
[RRSAgent] ACTION: Carine to send email to xlmpcomment and cc Joseph wrt ssue 241 [1] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T17-19-36 
[RRSAgent] ACTION: DavidF to draft a response for issue 266 and bring it back to the WG [2] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T18-30-46 
[RRSAgent] ACTION: Gudge to send a response for issue 268 [3] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T18-44-55 
[RRSAgent] ACTION: editors to make the changes proposed for resolving issue 268 [4] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T18-45-52 
[RRSAgent] ACTION: editors to resolve issue 267 with ed. changed [5] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T18-50-19 
[RRSAgent] ACTION: Noah to send an email to Martin and get a clarification on issue 269 and 'cc' distapp [6] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T18-59-03 
[RRSAgent] ACTION: editors to take on the last 2 items in issue 270 [7] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T19-04-08 
[RRSAgent] ACTION: editors to use the URL posted by Asir in IRC as the starting point for the editorial changes
to appendix A (issue 270) [8] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T19-05-54 
[RRSAgent] ACTION: Inoue san to send resolution text to xmlp-comments (Cc: martin) to close issue 263 [9] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T19-41-00 
[RRSAgent] ACTION: Glen to send closing text on issue 219 [10] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T20-56-59 
[RRSAgent] ACTION: editors to incorporate the text for issue 219 [11] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T20-57-15 
[RRSAgent] ACTION: Glen to send resolution text to xmlp comment for 230 [12] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T21-00-58 
[RRSAgent] ACTION: editors to incorporate text changes for 230 [13] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T21-01-17 
[RRSAgent] ACTION: Volker will send closing email for issue 329 referencing first part of Noah's email. [14] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T21-18-37 
[RRSAgent] ACTION: Volker will send email to xml comments closing issue 330. [15] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T21-25-20 
[RRSAgent] ACTION: Editors clarify that specifications for MEPs inherit requirements for features. Also note text
in 3.1.1 sub 4. [16] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T21-33-14 
[RRSAgent] ACTION: Gerd will send note to xmlp comment and cc mike champion to close 321 [17] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T21-38-08 
[RRSAgent] ACTION: Colleen will send note to xmlp comment closing issue 332 [18] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T21-41-39 
[RRSAgent] ACTION: Colleen will send email to xmlp comments cc Mike Champion closing issue 333, referencing draft
tag findings that it's okay to use QNames in this way. [19] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T21-55-36 
[RRSAgent] ACTION: MarkJ to send email to xmlp comment and cc Mike Champion closing issue 336. [20] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T22-03-01 
[RRSAgent] ACTION: Asir to draft email to xmlp comment to close issue 338 by taking no action. [21] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T23-00-17 
[RRSAgent] ACTION: Asir will send email to originator indicating this is handled as a dupe. [22] 
[RRSAgent] recorded in http://www.w3.org/2002/07/31-xmlprotocol-irc#T23-51-24 
[RRSAgent] ACTION: Herve to look at 7.5.2 and come back tomorrow to the group with interpretation to understand
context of issue 339. [23] 
[RRSAgent] recorded in http://www.w3.org/2002/08/01-xmlprotocol-irc#T00-03-46