W3C XML Protocol Working Group teleconference, 30 January 2002

Minutes of the XMLP WG telcon on 30 January, 2002.

1. Roll

Present Excused Regrets Absent

2. Agenda review and AOB

DF: Notes that Web Services Activity has been formed, and XMLP is now part
of WSA although no impact to our work.

3. Minutes of 23 January 2002 approved.

4. Action items

5. Status reports

-- Primer: DF reports on NiloM's behalf (see NiloM's email [17]) requests
reviewer of sections of primer, oisin accepts.  To mail by friday.
-- Editors: They are still awaiting feedback on their text proposals. DF:
next weeks telcon, we will put to wg which option by editors for section 2
-- TBTF: DF notes TBTF has recommended publishing an email binding in a
separate Note, and suggesting XMLP WG could take it up later.
-- ETF: HFN notes there are numerous action items, some still pending. DF
remins ETF to look at an email from DF on array types in xml schema lib
-- Conformance: OH reports that Jeff, Anish, and OH are working on this and
no more bodies needed.  Action: DF will write back re. offer from MS for
outsife help saying we have enough warm bodies.
-- Usage scenarios: Nothing to report

6. Issue 98: No discussion. No objection to closing the issue per PaulD's

proposal [5].

7. Issue 168, type of reference data. No discussion of ETF's proposal. No

objection to closing the issue per the ETF proposal [3].

8. Two issue resolutions proposed by TBTF.

Issue 58: must not preclude security binding.  GlenD sent message [18] with
proposal. No objection to closing issue with this proposal.
Issue 105: clarify message pattern. Noah: there is an implied
request/response in SOAP's rpc and http.  But there is no organized way of
saying how a response is handled.  Noah describes a response (not captured
by scribe).
DF: Can we agree to close issue, in the spirit of Noah's words?
Anish: is this related to issue 102?
NM explains relation and how 105 and 102 can be treated separately.
DF asks again if WG can agree to close 105, and asking NM to write the
words.
No one objects.
DF: issue 105 is closed, and NM will submit resolution text.

9. Issue 137.

DF: reiterates main discussion from last week, i.e. intermediaries may
modify headers but we did not decide whether a sender can assume by default
whether or not modifications might occur. We should decide what is the
default.
NM: HFN and I have been talking privately. The discussion has been about
who needs to know what is going on at an intermediary.  NM's point of view
is that  normally you follow the SOAP 1.1 rules. HFN's point of view is
that, it doesn't matter what the default is, it's the rules about making
changes that matter.  If you don't have a rule, then intermediaries can do
whatever they wish, like delete headers.  HFN points to many cases,
encryption is an example, where an intermediary can and should make
changes.  Imagine a case in which Noah sends a Purchase Order, and there
are lots of intermediaries.  HFN points out that the receiver doesn't want
to know about currency conversion. Control is maintained in the usual SOAP
way, using Must Understand headers.  If the sender wants to ensure an
intermediary does something, then a MU + header must be used. The
intermediary can break the rules if it thinks it can convince receiver.
Intermediary must include MU header on transformation that was done, and
the receiver then can decide to accept or disagree.
DF: So have we extended the semantic of MU in these sense that it now
represents "you understand something is prohibited but you can change it if
you document the change"?
NM: I would put in the spec the rules for what intermediaries can do. They
would state the default, and then say SOAP promotes a set of conventions
for over-riding the default. This wouldn't change the MU defn. It would
constrain specification of headers to redo this.  The MU header must
specify what changes were done.  Any downstream intermediary would do
similar??
DO: Can the original message be reconstructed?
NM: No, an intermediary just needs to describe changes.
DO: How are the changes described?
NM: Via Qnames and URIs, hence specs describe transformation
MarcH: I would prefer to disallow changing headers.
NM: So there would be no encrypting headers.
HFN: Then don't we duck the issue?
GD: Does the intermediary insert headers on any change?
NM: It only inserts headers when the default rules are not followed. If you
want to write a node that takes stock quotes and encrypts it, without
labelling, then
GD: This seems too prescriptive.
NM: Without such prescription, how do you know what's legal?
GD: You can't prevent people from being non-conformant
NM: Rules that prohibit removing headers, or changing headers, nothing
about
adding headers, soap 1.1 rules
??
NM: Under SOAP 1.1 rules, if a header is addressed to you then you must
remove it although you can re-insert it.
NM: There is one glitch to this in the context of the TBTF.  When looking
at multi-cast message patterns, where do you say anything about relaying
messages? Some people think it is said in a particular MEP. There is a
problem in the sense that depending on what the TBTF decides, the text
describing what HFN and I are proposing will land in different places in
the spec.
DF: So that we can resolve this issue sooner, I suggest writing text for a
particular section right now, and taking the risk that some of the text may
have to be changed at a later date.
Action to NM and HFN to propose text by EOB tuesday
CF: Example, intermediary that encrypts message and headers, produces
header that implies decrypt me.
NM: Encryption header then handles MU
NM: QName for spec defines what MU means
DF: If CF wants different wording, CF should suggest wording

10. Issue 176, intermediaries modifications to lexical format of a message.

NM: Our Infoset orientation means we don't have to worry about some things.
Comments, PIs may be deleted yet still maintain the canonical
representation.
DF: What about changing between "true" and 1?
NM: ?? very deep, value space comparison
MH: What about whitespace?
DO: The canonicalization spec has avoided the true versus 1 question.
HFN: utf-8 versus utf-16 in c14n.
NM: I am leaning towards mandating character for character transmission.
You can freely mess with PIs, comments, whitespace around and between
blocks, but not in blocks themselves.  Element begins with qname, this is
inviolate.
DF: Perhaps we can phrase this simply as "blocks are inviolate".
NM: PIs are not associated with anything. They don't have to be added or
deleted based upon headers nearby.
DF: We seem to be staggering towards disallowing lexical changes within
blocks, but allowing changes elsewhere in the envelope.
NM: All these different rules could drive either data driven or
document/order driven processors crazy.
DF: It's a mess.  Let's move to email.
Scribes notes are incomplete here.

11. Issues from WD.

-- Resolution of conflict between sections 4.1.1 and 4.3
HFN: The encoding style attribute applies to the content of an element, not
the element itself.
MH: The encoding style section says it's owning element as well as content.
NM: Encoding on an envelope would make message into struct, when that's not
reasonable. An encoding attribute on a body could be right.
DF: The summary question is: should the encoding attribute be allowed on
the body element or not?
WG participants unanimously agree the encoding attribute should be allowed
on the body.
DF: The editors will make the appropriate chnages.
-- What are desired semantics of URI? See [13]
Scribe's notes do not record discussion.
WG participants unanimously agreed to remove the offending sentence
mentioned in [13].

12. Issue 179, one-way messaging in SOAP 1.2.

MH:  SOAP supports one-way messages.  Does that mean that every binding
supports a 1 way MEP?
HFN: Related to NM's discussion on MEPs, I am not sure we have to say in
the framework how to define MEPs.
NM: There seem to be 2 issues here: 1) degree to which MEPs are in the
framework, distinguished feature, responsibilities of author of MEP, that
every transmission is part of an MEP; 2) vestigal remains of notion that
SOAP is a 1-way model, do we need to say anything about that?  NM answers
himself: let's change it.  Here's how to write MEPs, and we give you two of
them, and transport bindings can implement whatever they want.
HFN: I think we can say that MEPs may be implemented as a binding or as a
module, without going into the TBTF debate. MEPs are at the same level or
different levels than binding.
NM: In the TBTF discussion there is a view that bindings shouldn't mess
with headers.  So there are limits to what a binding can do to things
expressed in headers.  We should put this discussion on hold.  This is a
tricky feature.
NM: the aspect is ??
DF questions whether bindings must support all MEPs
DF: Postpone one aspect of this until TBTF comes back on features.
    
[3] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0385.html
[5] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0374.html
[13] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0335.html
[17] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2002Jan/0107.html
[18] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0407.html