W3C XML Protocol Working Group teleconference, 3 September 2003

1. Roll

------- Present 14/9 Excused Regrets Absent

2. AOB

------

DF: Number of WG member companies is diminishing, it is now 13 including
W3C.
DF: Move time of telcon earlier? Will poll by email.

3. Approval of minutes

----------------------

- July 30 telcon minutes
No objection to approving the minutes.

- Add MarkN's summary text in the f2f minutes, see
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Aug/0010.html
No objection to making the change

4. Review action items

----------------------

5. Status reports

-----------------

- Media type registration
MarkN: Have been told that we need IESG approval before publishing as RFC.
Asked the IESG to start the process. Problem is that the whole process is
murky.
DF: W3C should know about the tribulations of this process
DF: We should write a a factual statement about what has happened and send
it to W3C-IETF mailing list.

- Status of Usage Scenarios doc
Published (this item is left over from a previous agenda)

- XKMS WG response
DF: JohnI to look about how XKMS WG handled our comments to their Last
Call. We should send a response if OK, otherwise report back to XMLP WG.
DF: Does anyone have a problem with this approach?
Silence. No objection.

- Editor position for SOAP Optimized Serialization Requirements doc
DF: AnishK and TonyG both voluntereed. They will be the new co-editors for
this document.

6. Attachments

--------------

- Comments for XInclude 1.1
DF: XInclude 1.0 went back to WD. Not clear what the status of XInclude 1.1
is now. DF will investigate.

- MTOM document
DF: Pushback on regex proposal (Amy Lewis). She wants us to enumerate
specific media types rather than have a generic regex. Has Amy advanced any
new arguments?
MarkN: No new arguments.
DF: Any opinion?
Silence.
DF: Proposal to keep our generic regex.
No objection.
DF: MarkN to write to Amy that we didn't change our mind.

- XQDMTF meeting report
Noah: Open ended discussion about whether or not to do this. Next step to
draft a document to see what it would look like. This was done.
DF: Is there another meeting scheduled?
?: No, in the process of scheduling it.
DF: I will help you do this through email.

- ARTF on Attachment Requirements
DF: There was a meeting before the August break which was already reported,
and so there is no new TF meeting report. We have previously stated a
desire to be carefull to not write the requirement documents after the spec
doc, but rather to write them in small pieces and sequentially. So, is it
now time to go back to the requirements doc?
Anish: Do we intend to make both documents public at the same time?
DF: That sounds like a fine idea.
MarkN: Agree.
MarkN: Is there a schedule for MTOM draft publication?
DF: None for the moment.
DF: I will think about this.

- Use cases
DF: MarkN generated some use cases. How to move forward with that
MarkN: I think we wanted these use cases in the requirements document.
DF: Maybe ARTF could take the task of generation more use cases.
MarkN: Does everyone agrees with these use cases? Does they cover the space
we want to cover?
DF: We could send these to the ARTF to go faster
DF: Wait for any feedback on those use cases. Then try to work on them
during a telcon.
Anish: Pointed to use cases gathered during March f2f.
DF: I will put all this in agenda item for next week.

- Pro's and con's of different methods for determining usage of MTOM
binding
DF: What is the status of the discussion?
MarkN: Focus on handful of mechanism.
DF: Do the MTOM properties proposed by Gudge address those concerns?
Gudge: They are completely unrelated.
DF: Do we need to resummarize the summary list?
MarkN: Perhaps.
DF: The original idea was to have a consolidated list with pro's and con's,
and then make a choice. MarkN to make list for next week telcon. Then
evaluate each solution.

- Issue discussion
- 431:
DF: Two proposals from Noah and Gudge.
Noah: General view is the proposal written with general rule that you don't
know what will be optimized. Specific case is when intermediary has the
same binding for inbound and outbound messages, you can optimize if you
want, but it is up to the binding implementation.
Gudge: Noah's proposal is fine.
Noah & Gudge: Our proposals are not related. Noah's is about
intermediaries, Gudge's is a collection properties.
Noah: No conflicts between two proposals.
Gudge: Ok to put Noah's text into MTOM document.
DF: If no conflict, we can handle them independently. MarcH (raiser of
431), what is your opinion about Noah's proposal?
MarcH: Noah's proposal covers 431.
DF: It is proposed to resolve issue 431 by incorporating Noah's text into
MTOM.
Agreement, no objection.
DF: 431 is closed with Noah's text.

DF: Gudge, what to do with your proposal?
Gudge: The proposal could address 435.
DF: And is it a potential resolution to 432?
Noah: If use Must/MustNot, this could complicate intermediaries rules. Lot
of this stuff should be binding specific.
DF: Would like to structure the discussion, as Gudge's proposal is a dump
of many "possible" properties.
Gudge: The proposal is split into Global and Other properties.
DF: Issues are a better way to structure the discussion.
Gudge: Fine.
Noah: Related big picture thing. There is lots to say about sender. On the
receiver side only want to know about what was optimized (implicit in
intermediaries rules), not what could have been optimized. So discussion
can largely be structured around what the sender knows.
Jacek: Could go further, the sender only knows what it is going to
optimize. Or need to specify some mechanism on how the sender will decide
what will be optimized.
Noah: Do others agree about receiver side (only know what was optimized)?
General agreement.
DF: Go to discussion about 432 and 435.
Noah: There is more than 435, that is what the receiver knows other than
what was optimized (current response is nothing).

DF: Shall we deal with receiver side first?
MarcH: What receiver level?
Noah: Assumed that we were talking about properties, ie available at SOAP
level. Name a property which will indicate which elements were optimized.
MarcH: At abstract level can talk about this property. Does our binding
implement this property?
Noah: Any more than abstract would need to design an API.
Noah: Not sure if we have to say whether implementation should make this
property available.
Jacek: In favor to have the same property or same kind of property on both
sender and receiver side properties.
MarcH: Should we expect that every implementation would make available the
list of elements which optimized on receiver side, or is this
implementation dependant?
Noah: How do we know what was optimized? Could have multiple forms of
optimization. It may not be decidable on receiver side (eg: doing nothing
for short base64 pieces is the "best" optimization).
Jacek: What is your opinion, no property or not a MUST?
Noah: Should be a MAY of SHOULD and not a MUST for filling the property.
DF: Continue discussion by email. Need a seed for email thread. Noah, are
you OK to make a proposal?
Noah: Agree.

7. SOAP 1.2 Recommendation

DF: 6 issues against Recommendation. 4 against parts 1 and 2, 1 against
test collection, Anish to look at it. I'll contact Nilo for Part 0 one.
Then ask WG approval when we have all proposals in hand.