W3C XML Protocol Working Group teleconference, 16 July 2003

1. Roll call

Present 13/10 Excused Regrets Absent

2. Agenda review

3. Approval of July 9 telcon minutes

No objections, approved

4. Review Action Items

5. Status report

-- F2F meeting
DF: Agenda available.
DF reviews the agenda.
No comments, no questions.

DF: remember to register before Midnight ET, July 17.

-- Registration of media-type
MN: Nothing to expect before next week.

-- SOAP MTOM WD status
YL: No update. Pinged TBL and other W3C person, but no answer.
DF: good to have WD by EOW (in time for the f2f meeting).

-- XMLP WG activities during August
DF: Proposes to hold no telcons during August, as in previous years.
No objections, proposal accepted.

6. Attachments

- Att req TF
MJ: Met twice. Gone through all requirements and categorized. None
irrelevant. Abstract Optimization Feature, Concrete Implementation.
MJ: Working on a refactoring of the previous document. There will be
something by next monday (work by MJ up to friday, then by MN).
MJ: Possibly there are new requirements that needs to be identified and
added to the document. Will not be done for monday.
DF: That can be work for the F2F.
DF: F2F, 2 things to do. Discuss new requirements. Evaluate all the
requirements.
DF: Someone to go through the Disp-App emails to find any new requirements.


- Proposals for MTOM document (from JK and MH)
- Proposal from Jacek, "Media Typing"
JK: Gathered from PASWA section about Media Typing. Made it more
general. If this goes into MTOM document, then need to rename the document.
MN: Need to think about this more. Looks reasonable.
MJ: Title misleading. Should be changed even outside context of JK
email. Looks more as an attachment kind of framework.
JK: Would not necessarily use the word attachment. Think current title
is OK for current document.
MN: Agree with JK that current document is about Optimization. Whole
thing is an encoding issue, not about attachments.
MJ: About transfering data in an extra-envelope.
JK: Not necessarily, depends on the implementation.
MJ: At least part of the document is specifying an extra-envelope
packaging mechanism.
MN: OK to change title to an Encoding issue.
DF: Is PASWA not about mapping infoset to what is on the wire?
MJ: Recoding mechanism on the wire.
MH: Serialization better than Encoding.
DF: The term "Encoding" might be confusing, e.g. with respect to SOAP
Encoding.
MH: Encoding has other connotation. What it is really about is an
efficient serialization of an infoset.
JK: Plus Media Type, document would be about including arbitrary data
into XML. And serialization would be only a part (and not the more
important part).
DF: "Name the thing" would be a great F2F topic. One way to proceed is
to solicit suggestions beforehand, then consider the list at F2F meeting.
DO: Need pros and cons for each name.
DF: Somebody suggest a new name with pros and cons and solicit other
suggestions.

DF: Sense of WG that need more time for reviewing JK proposal? (No reply).
OK, we will revisit this at during F2F.

- Proposal from MH, Relation with SOAP 1.2 HTTP binding
MH: Initial concert, MTOM talk about "a" HTTP binding. Do not talk about
how to do it with the existing HTTP binding. Changed the text to achieve
this.
DF: What is the impact on the existing HTTP binding in the SOAP Rec?
MH: Not too bad. There are some extensibility points in the current HTTP
binding, like MIME type. Suggested a way of rewritting some parts of the
MTOM spec.
JK: I think I like this.
MN: Agree.
DF: Need to look closely what is the impact on the REC.
MH: No change to the REC.
JK: Impact to the REC is none, expect that we are adding value.
DF: YL and CB take MH proposal and figure out what impact it would have
on the REC.
YL: OK to work on that, hopefully for F2F.
DF: Other discussions, questions?
(No reply)
DF: Goes on the F2F agenda.

DF: Other things about MTOM document?
(No reply)

- Issue discussion
- 431, semantics of attachments and intermediaries
MH: Issue about general semantics of attachments and intermediaries and
about particular example. Some suggestions to split example and close
issue about it. Maybe could do this and reopen if needed.
DF: Opinions from the WG?
JK: Already suggested closing 431, because understanding it as covering
only example. Now can go either way: closing example issue (and
eventually reopening it), or keeping general issue.
MH: Document does not talk about intermediaries at all.
JK: HTTP binding does not speak about intermediaries and should not. So
MTOM HTTP binding should not either. However, MTOM abstract feature
should speak about intermediaries.
MH: Think we have to put something in there.
DF: It seems that the underlying issue is whether we need to speak about
the responsibilities of intermediaries.
(General agreement expressed)
MH: Modify the issue to say: "do we need to think about intermediaries".
DF: Log a new issue.

- 432, how does binding determine what to serialise as attachment
MH: Only discussion from Gudge.
JK: There was some more discussion about property, and that is related.
MH: 'Hint' is an implementation detail. No need to worry about that.
MN: Two kind of scenarios, is deserialize then reserialize, where to
start? Having a 'hint' is appropriate.
MH: List is an abstract thing.
JK: Property has the input of the optimization mechanism. Take some
input from the application, then modify it for creating the value of the
property. Property: input from us, not used by application.
MN: JK goes for the list of elements effectively optimized. Do we need 2
properties? Might be usefull to have a property which is a hint and
which is passed down the path.
JK: Realy need list of effectively optimized elements. Could be a
valuable extension to add a hint.
MN: Hop by hop, could have different properties. How do we communicate
it. Start with what is in the message and might extend it.
MH: "Candidate for optimization" property would be transfered with the
message?
MN: Could be in the message.
DF: Proposal to capture this.
JK: Can write a concrete proposal. Would be a proposal for resolution of
432.
DF: Position of this proposition regarding 435.
MH: Should tackle it.
JK: Proposal by EoW.
ACTION to JK to propose resolution for 432 (and maybe 435).

DF: At end of agenda. Are there other issues?
JK: Question about 435. On the receiver side "optimized elements list"
should be initial value of the "optimized" property or the value of
another property.
MN: Prefer slighly two properties.
JK: If modeled as one property, without any action by the application
would stay the same.
HR: Binding could change it.
JK: Will propose two differents versions.

DF: Other things?
(No reply)
DF: Meeting adjourned.