W3C XML Protocol Working Group teleconference, 20 February 2002

Minutes of XML Protocol Working Group Teleconference, February 20, 2002.

1. Roll call

Present Excused Regrets Absent

2. Agenda review, and AOB

3. Approval of February 13 Feb telcon minutes

Although minutes only just posted, WG does not object to their approval

4. Review action items


2001/11/27: Editors
Incorporate requirements from RDF, UML, XML Encryption, ... in requirements
doc
HFN: suggests that these issues already captured in issue #29
DF: P3P and XForms say reqirements from them have been met.
HFN: and these are already captured in Requirements document
DF: wonders if the same is already true for encryption
DF: we have asked previously through chairs@w3.org whether groups felt that
their req'ts had been met.
Gudge: what about RDF group?
DF: i'll tell you about that in a minute
DF: does XML encryption have any req'ts we need to capture anywhere?
DO: no, doesn't think that they have req'ts on us
DF: sounds as if those who sent us req'ts are done, and all others are
captured in i#29. Propose we close this action.
No objections.

2001/12/05: HenrikN &DavidF
Follow up on links to requirements from external WGs by monday noon EST.
DF: followed up with RDF group. DanB of that group is out sick, Eric Miller
will follow up instead.

2002/02/06: DavidO, davidF
Figure out the interactions between XMLE and XMLP
DO: XML encryption is going to register a media type, DO raised issue on
XML Infoset, any infoset and PSVI issues we have aren't applicable. There
is one issue about content type when xmlenc is used and decryption is
required to resolve it... I am not sure whether or not we're converging on
this (DO, SKW, Noah, others)
DF: is that the last issue with XMLE?
DO: yes
DF: so, you think on this issue we are headed for deadlock?
DO: 90% sure that's the case. suggest we see if there's any further
progress before bringing to W3C team

2002/02/13: StuartW
Incorporate MarkB's friendly amendment in the HTTP binding wrt issue 133
SKW: Done, but some feedback has been received. The gist of the feedback is
broadly not acceptable, they would like to see things done in more
REST-friendly manner. If we do things that have no side-effects we should
be using GET consistent with HTTP semantics.
DF: PC suggests TAG is picking up this more general issue in conjunction
with IETF, and so for time being we stay with our current binding.
SKW: fine, but it might still be issue with the one person
DF: propose we write back with summary of above and close the issue with
that.
No objections heard.
DF: that's what we'll do. Did your email reference TAG discussion?
SKW: no, but recent emails do reference it. Issue is closed, but there
remains some dissatisfaction on this issue.
DF: write back with summary, we're still going to keep it closed.
SKW: will send to DF before responding to PaulP (person who has been
driving feedback)

5. Status reports (12.20 + 5)

PC: sent note regarding status of test suite... 2 questions, (1) I gather
we're supposed to get revised document, and (2) what is vintage of
material? there has been no answer
OH: essentially, the new work we have taken on has to do with binding
framework. We took info from hugo's document, but that did not include
output of f2f. We are currently rolling this into more complete document to
be available for f2f.
PC: ??
OH: trying to collate all the info by this weekend. Answer to third part of
your qeustion, the doc will also contain everything that has been put
forward as well as round 2 of SOAP builders. We won't let anything fall
through the cracks.
DF: by when?
OH: by f2f (friday night)
Anish: comment on soapbuilders maetrial ... why are we including
soapbuilders tests taht are based on soap1.1?
DF: we went to soapbuilders because they had tests, some of which might be
applicable to soap1.2
Anish: propose we remove those tests from our document because they're
based explicitly on soap1.1.
DF: what am I missing here? We want a set of assertions and tests that
apply to soap1.2, if you can cut-n-paste them out of soap1.1 tests, that's
goodness isn't it?
Anish: the way they're written they have references to specific tests in
soapbuilders round 2. if you follow the link, the test is soap1.1.
DF: we need to take this off-line, we'll see what we have friday night.
Some people may not be able to read them in time for f2f...

6. A volunteer is needed to peruse the recent postings on our mailing lists

to determine whether any new issues have been raised. Gudge volunteers.

7. Issues, Group I

DF: these are all pretty straight forward, we should be able to assign
someone to each of these issues. It shouldn't take more than a few lines of
resolution text. Looking for volunteers to bring resolution texts to f2f.

MG takes #142
HFN: 101 is already done
DF: with respect to #36, we decided to postpone until we produced test
collection. We need someone to write the two sentences we will use when we
produce a test collection.
OH takes #36
Amir takes 41
JohnI takes 51
PaulD takes #54
GlenD takes #56
JI: does it cause process problems if an issue originator closes his/her
own issue?
DF: no, because the resolution must be approved by the larger WG.
SKW takes #67
MarcH takes 154
JJM takes #61
Don Mullen takes #82
Gudge: 110 is in progress, editor's copy has some of it done.
HFN: notes he has already sent in a proposal for #17
DF: notes he will edit the f2f agenda to reflect the volunteers and their
proposals.

8. Issue 176, canonicalization/rewrite of headers

DF: RS, please summarize...
Rich Salz: 2 sets of discussion threads regarding proposal. The first is to
nail down what can be done to message by intermediaries, the second is
about ordering/sorting. We probably don't need ordering, probably need to
identify header blocks by id.
RS: discusses basic approach behind SM-C14N... goal is to be able to
reconstruct same byte stream as sender had
DF: is there still contention on the issue?
RS: if we reissued the proposal without ordering, we could get consensus
HFN: on nailing down what intermediaries can/cannot do, there has been some
discussion on mail list today.
RS: intent is to provide a scheme for interop, there would be no mandate to
use it in "SOAP" but in XML-DSig...
MarcH: has same usefulness as HTTP binding. Don't have to use HTTP binding,
but if you want, here it is.
DF: what SOAP mandates or disallows intermediaries from doing. If we define
a scheme that is optional, that's another question. Is that the point you
were making earlier?
RS: what sm-c14n says is "here's how to get a consistent byte stream..." it
is useful to work on these two at the same time.
DF: what can we learn from this excersize regarding what intermediaries
can/cannot do?
RS: if they can rewrite headers in arbitrary order, has impact on digesting
mechanism. When we come at this from infoset vs bytestream POV... the
discussion is good.
HFN: 137 and 175 are on agenda for f2f, don't they cover this?
MarcH: aren't these dupes and can't we close them with same resolution?
HFN: thinks so. We should have proposal for f2f regardless of discussion on
c14n.
DF: should we order the discussion to discuss 137 and 175, followed by 176?
HFN: yes, but still can happen in parallel
CF: raises issue of infoset v byte stream, where does this go as it only
relates to bindings that use XML1.0 serialization?
HFN: c14n covers all threee issues. It should be captured by mechanism if
we propose such a mechanism.
DF: okay with this?
RS: yes
DF: keep the discussion going, and keep eye on 137, 175
HFN: should have something by f2f, whether people can read it in time
remains to be seen -- apologies for last minute

9. Issues Group II

Asir: ETF has proposed resolutions for 180, 78
HFN: 175 we can dupe as 137
DF: unless there are objections, we'll make them one and the same
No objections heard
DF: with regard issue 59, did we receive feedback from i18n group?
OH: no, we should close the issue and move on
Several people express support for this course of action.
DF: is there a reason that they'd want us to do otherwise?
YH: looking at character model, at least utf-8 and utf-16
DF: our requirement 609 is about requiring support of a large set of
character encodings, maybe if we mandated one encoding only it would reduce
complexity.
PC: recalls discussion being other way round, he doesn't think this is
operable when XML1.0 didn't do this??. do any of our proposed bindings want
to restrict it?
DF: are there any restrictions such that an encoding MAY be considered in
bindings?
PC: if I used another encoding would I need to use a separate binding?
??: it might have a known specific sub-binding that restricted character
set
DF: sounds like we're largely agreed we shouldn't restrict character
encodings.
MG: why say anything?
HFN: thinks this is addressed in binding framework.
DF: could someone check on whether there is something on encoding?
PC: agrees with Gudge any words we use reflect what the original issue was.
MG: can't find anything
HFN: section 6.2 (reads...)
CF: from SOAP's perspective, this is a non-issue because we've gone to
infoset based specification.
DF: so that would explain why this issue exists. I propose we say "we do
not mandate any particular character encodings because we are based on
infoset", is this sufficient to close the issue?
PC: I'm using foobar encoding, why doesn't someone understand me?
Jacek: everyone is aware of encodings, especially those who use funky ones.
XML1.0 handles this for us.
PC: agrees
HFN: we have mechanism for negotiating other encodings
DF: so do we take the proposal and add Jacek's note to the end of it to
create our resolution?
Jacek: accepts assignment to draft resolution
HFN: do we want to close it now?
DF: no, we need to see the text first
DF: issue #181, asks JJM for a summary
JJM: 
MG: search on text, doesn't appear in section 2
JJM: no, but its different what it says in two sections
DF: do you propose to put role info into fault actor element, and add extra
info into fault actor?
MG: why not just replace what's there now?
JJM: section 2 talks about roles, not nodes. Section 4 doesn't mention
roles at all, just nodes. You know some node faulted, but you do not know
about the role. There seems to be an inconsistency.
MG: similar, but target of source header block that's source of the problem
Jacek: modeled for actor attribute, we've renamed this and faultactor
should be faultrole and made clear that its the role named in that element.
Some want to indicate which node faulted because '.../next' is not
sufficient to know who faulted. We should add faultrole with same meaning.
JJM: has this text changed from issue 181?
MG: can't tell
MarcH: thinks its still the same. Issue is deeper because we don't talk
about nodes outside an abstract concept, we can only talk about roles.
HFN: are you saying we are going to talk about roles? There is an email
from Chris which agrees with what Jacek is saying. ?? are these orthogonal
issues? We have nodes have uri, may be same as role... might not be same as
where message flows.
MarcH: struggles with how we identify nodes. Is it just some URI? Without
meaning associated with node id, it is useless info.
DF: would you send back fault saying ".../next" faulted?
MarcH: that's all you can do...
SKW: thinks role and node might be useful info with orthogonal qualities
DF: argues with Jacek's suggestion
MarcH: we're going to open a can of worms around message path because we
don't flesh it out.
HFN: exactly the way you find out about name of role... unspecified you can
stick in any value you like.
MarcH: you could think you're multiple URIs
SKW: a useful URI is next destination in a binding (immediate destination)
MarcH: if we have faultnode, it represents another abstract URI
SKW: these are useful distinguishing roles
MarcH: how do you know who you are?
DF: would you make it mandatory for a concrete location?
MarcH: prefer we call it faultrole, defer til we get around to routing...
we don't have enough framework on which to hang this
JJM: has a proposal to do what Marc says: a role can identify what a node
does and ... first sentence (look at issue 11) if we remove first two
sentences, and only had second maybe that's enough? And don't discuss
message path.
MarcH: that would be the shorter resolution to this
DF: you mentioned an email, was there indeed a proposal?
CF: yes, in the part of the thread where it was suggested to add faultnode.
This received some positive comments and thread ended
DF: would like proposal written up that we can debate on email. We need to
have something to point at and discuss.
MG: I will have something by friday
DF: lets put a stake in ground. Gudge and Henrik to propose something by
EOB Friday

DF: #182 fault code restriction, Marc can you summarize?
MarcH: some new text appeared when we did the re-write about which faults
can be generated. It doesn't seem right. The proposed resolution is to
remove restriction.
HFN: +1
DF: is proposal summed up on issue list? 
CF: +1
SKW: little wary of MUST. Agrees with exactly one, but not with whether a
fault MUST be generated. Proposes "if processing is unsuccessful, at most
one fault MAY be generated by the node. ..."
HFN: has concerns on two levels. At one level is that we ensure that we
fault. This is different from saying what one might want to do with a
fault, etc. That is an entirely different problem.
JJM: is HFN's concern addressed by processing model?
HFN: you need to know when you have to fault.
CF: this is really about removing restriction that seems inconsistent with
respect header processing and cardinality, not whether a fault MUST be
generated.
DF: thinks he agrees with SKW, and generate no more than one fault.
CF: it is about cardinality
SKW: +1
DF: HFN, do we say anything about MUST elsewhere? SKW, could you take AI to
rewrite proposal to address cardinality?
SKW agrees
DF: all of the remianing issues have been addressed, in the sense that we
have something for moving each one along.
We will take these up at f2f.

TTFN, see some of you in Cannes next week.