XMLP WG telcon minutes, 2 June 2004

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]