Based on IRC log
1. Roll Present 13/10 BEA Systems, Mark Nottingham Canon, Jean-Jacques Moreau Canon, Herve Ruellan IBM, Noah Mendelsohn IBM, David Fallside Microsoft Corporation, Martin Gudgin Nokia, Michael Mahan Oracle, Anish Karmarkar SAP AG, Gerd Hoelzing SeeBeyond, Pete Wenzel Sun Microsystems, Marc Hadley Sun Microsystems, Tony Graham W3C, Yves Lafon Excused BEA Systems, David Orchard IBM, John Ibbotson Microsoft Corporation, Jeff Schlimmer Oracle, Jeff Mischkinsky SAP AG, Volker Wiechers Regrets IONA Technologies, Suresh Kodichath 2. Agenda review and AOB [scribe] AOB: clarify F2F - based upon LC comments, we may have a F2F between LC and CR; otherwise, after CR. [scribe] noah - dates? [[scribe] chair - expect LC in the next few days; review period will be ~ 3 weeks, so jun21; earliest F2F would be jul5 or following week [scribe] noah - notice may be required [scribe] chair - ack. We've previously agreed that this would be open; these dates are not hard and fast. [scribe] chair - if period between LC and CR is three weeks, CR would be mid-July; jul19? [scribe] chair - CR has no minimum time required, but I think a month would be appropriate. That would take us to mid-August for ending CR. [scribe] chair - If we had a F2F then, it would be around the last week of August. 3. Approval of 26 May 2004 minutes, approved - no objections. 4. Action items Changes to status of action items published in agenda. [scribe] - AI to MTOM editors (re: XML 1.1 decision) DONE - Herve [scribe] - AI to send REC19 closing e-mail DONE - Anish [scribe] - AI to collect media type doc comments DONE - Anish [scribe] Mail to i18n - no objection to sending. [Yves] ACTION: Tony to send email to i18n (http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004May/0067.html) 5. Status Reports [scribe] Media type registration [Gudge] markn - after last weeks call I got a message from the area director saying the IESG had an objection [Yves] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004May/0065.html [Gudge] markn - IESG requested two changes. One change is about language regarding the action parameter being used for security purposes. Most security people agree this is not a reasonable approach [Gudge] markn - suggestion is to stike this language [Gudge] markn - second change, confusion whether BNF in RFC2396 as to whether an empty string is allows for action parameter. Media type should be explicit. [Yves] comments at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8198&rfc_flag=0 [Gudge] markn - suggest we remove the sentence about using the action parameter for firewalls [Gudge] noah: Is this what we talk about as SOAPAction? [Gudge] markn/gudge: yes [Gudge] noah: motivation was to allow some indication of intent of message in situations where parsing the XML payload is impractical [Gudge] markn: I think we should keep the parameter ( and the motivation ) [Gudge] yves: would rather drop parameter. But OK with keeping it. [Gudge] noah: This applies where there was explicit trust between some entity and the eventual SOAP engine. In any case where the entity ( firewall ) say an action it didn't like it could reject the message [Gudge] noah: This also required SOAP engine to check that HTTP header and XML matched [Gudge] markn: Preference to use the language from noah for motivation. And note in security considerations that using the action parameter as the only input to security is 'unwise' [Gudge] noah: Go further and recommend that SOAP engines check that the action paraemeter and intent of message match [Gudge] markn: Take to e-mail and I'll take a stab at language? [Gudge] markn: I think we should explicitly disallow empty action parameter [Noah] +1 [Gudge] chair: does this go in the HTTP binding? [Gudge] marc: The HTTP SOAP ACtion feature doesn't say anything about empty string. [Gudge] marc: Is empty string a valid xs:anyURI? [Gudge] gudge: Yes, because an empty string is a valid relative URI [Gudge] markn: This is being clarified in RFC2396 [Gudge] marc: not OK to disallow empty string at this point [Gudge] markn: can we say action parameter SHOULD be an absolute URI ( and hence not empty string ) [Gudge] noah: Where is the line for how far we can go before we get caught up in process that would take us back to CR. [Gudge] markn: We do have a conflict because Section 6.5 text just says xs:anyURI [Gudge] markn: but the media type says absolute URI [Gudge] noah: Someone who did there own binding could support the feature and allow relative URIs. It's just our HTTP binding that requires absolute [Gudge] noah: what if we fix the rec [Gudge] noah: to match the media type [Yves] +1 [Gudge] chair: proposal is for action parameter MUST be absolute and MUST NOT be empty [Gudge] no objection to above proposal Chair: proposal is carried without objection [Gudge] ACTION: MarkN to draft new registration text incorporating proposal for action parameter MUST be absolute and MUST NOT be empty [Gudge] ACTION: Yves to draft errata text for Part 2 Section 6.5 per proposal for action parameter MUST be absolute and MUST NOT be empty [scribe] XMLP/WSD Task Force / Media Type Document [scribe] Anish: submitted for publication [scribe] Chair: do we need to reply to Glen Daniels? [scribe] Anish: I don't think this is related to the media type document. [scribe] Chair: this is a separate WSD issue. [davidF] glen's question at http://lists.w3.org/Archives/Public/xml-dist-app/2004May/0052.html [scribe] Noah: I've read it, don't have much to say. [scribe] Anish: I thought it was OK. They're proposing that they specify a feature which corresponds to our optimisation. [scribe] Mark: Where is it layered into the stack? [scribe] Noah: I think it's in the SOAP binding. [scribe] Noah: "This would go in your SOAP binding. If your underlying protocol didn't support this feature, you'd get a fault." [scribe] Marc: What's the semantic of required=false? [Noah] Specifying the feature with required="false" would indicate to a user [Noah] that MTOM/XOP serialization is supported by the service, but not [Noah] required. [scribe] Anish: They need to clarify this not only for this feature, but all features. [scribe] Chair: This should go to e-mail. [scribe] LC Status [scribe] Chair: We have finished the updates on the LC boilerplate. [scribe] Yves: The LC documents should be ready; the only remaining ones are the WG notes and the attachment feaure. [scribe] Yves: I will draft a publication request today, and hope to have everything finished tonight. [scribe] Yves: The end of Last Call will likely be end of June, at worst, supposing a pub date of end of this week or early next week. [scribe] Chair: MTOM, XOP and Representation header are going out as LC drafts; the FAQ is going out as a WG Note; the Use Cases & Requirements are going out as a WD. [scribe] Chair: The Attachment Feature is going out as a WG Note, with a statement regarding its status. [scribe] Chair: I've been in touch w/ Nilo about the Primer; he'll have a new version for review around jun26. [scribe] Chair: MikeM should be helping him. 6. Attachments (skipped) 7. SOAP 1.2 REC Maintenance [scribe] issue 23 - AI pending [scribe] discussion postponed [scribe] issue 21 - proposed resolution from Marc; http://lists.w3.org/Archives/Public/xml-dist-app/2004May/0056.html [scribe] Marc: Noah and I agree that order is most signifcant to least significant; discussion is about how best to express that. [scribe] Noah: I assumed that this was the ordering. [scribe] Noah: In reading this, the whole status of array size is in question; when you read the rest of the REC, it says nothing about dimensions at all. [scribe] Noah: We're talking about items "distinguished by position"; there's nothing that talks about multiple dimensions, either here or in the serialisation. [scribe] Noah: It does say you must/should have this arraysize attribute. In the original text, it talks about the dimensions and order; reading the text Marc came up with, I realised this has never been clean. [scribe] Noah: It would have been coherent to change the data model; now, the best thing we can do is to say that arraysize is a hint. [davidF] noah's text ... [davidF] "The arraySize attribute SHOULD be used [davidF] when it is desired to [davidF] to suggest a mapping of SOAP compound [davidF] values distinguished by position to [davidF] fixed size or multi-dimensional program [davidF] array data structures. By convention, [davidF] the mapping is established such that the [davidF] array's dimensions are represented by [davidF] each item in the list of sizes [davidF] (unspecified size in case of the [davidF] asterisk). The number of items in the [davidF] list represents the number of dimensions [davidF] in the mapped array. The subscript that [davidF] changes most slowly appears first, with [davidF] others if any following in order; the [davidF] asterisk, if present, MUST only appear [davidF] in the first position in the list. The [davidF] default value of the arraySize attribute [davidF] information item is "*", suggesting that [davidF] by default arrays are to be mapped to [davidF] program structures of a single dimension [davidF] with unspecified size." [davidF] marc's text .... [davidF] "The array's dimensions are represented by each item in the list of [davidF] sizes (unspecified size in case of the asterisk). The number of items [davidF] in the list represents the number of dimensions in the array, [davidF] dimensions are listed in order from most significant to least [davidF] significant. The asterisk, if present, MUST only appear in the first [davidF] position in the list. The default value of the arraySize attribute [davidF] information item is "*", that is by default arrays are considered to [davidF] have a single dimension of unspecified size." [marc] I just added: "dimensions are listed in order from most significant to least significant" to the existing text [scribe] Gudge: It seems to me that the arraysize stuff is just a hint for interpreting the serialised data. [scribe] Mark: Sounds like a hint. [scribe] Chair: It seems that there's a leaning towards calling it a hint, which Noah's text expresses best. [scribe] Chair: We need need to see a tightened piece of text before including it in the errata. [scribe] Chair: In principle, we've agreed that a tightened version of Noah's text is the direction we'll go in. [scribe] ACTION: Noah to tighten up issue 21 text by end of week [scribe] Simple Authentication Feature [scribe] http://lists.w3.org/Archives/Public/xmlp-comments/2004Jun/0000.html [Yves] http://lists.w3.org/Archives/Public/xmlp-comments/2004May/0018.html [davidF] ACTION 6= Gerd to propose resolution to of simple authentication feature Rec issue, for next week telcon [scribe] Media Type Registration [scribe] Mark: We need to update the media type registration in the REC once the IETF draft is published. [davidF] ACTION yves to create media type registration Rec issue and note that it should be decided after registration is complete with IANA [scribe] Meeting adjourned. [Zakim] leaving. As of this point the attendees were Mark_Nottingham, David_Fallside, Gudge, Marc, Noah, M.Mahan, [Sophia], Yves, +1.503.830.aaaa, TonyGraham, jjm-home?, anish, Canon, [RRSAgent] I see 6 open action items: [RRSAgent] ACTION: Tony to send email to i18n (http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004May/0067.html) [1] [RRSAgent] ACTION: MarkN to draft new registration text incorporating proposal for action parameter MUST be absolute and MUST NOT be empty [3] [RRSAgent] ACTION: Yves to draft errata text for Part 2 Section 6.5 per proposal for action parameter MUST be absolute and MUST NOT be empty [4] [RRSAgent] ACTION: Noah to tighten up issue 21 text by end of week [5] [RRSAgent] ACTION: Gerd to propose resolution to of simple authentication feature Rec issue, for next week telcon [6] [RRSAgent] ACTION: Nilo to provide updated Primer for review, by June 26 [7]