Web Services Addressing Working Group F2F -- 19 Jul 2005

<anish> Scribe: Katy

LC76

<mnot> Proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0136.html

Tony: Subsubcode to fault and associated detail

[subsubcode] indicates fault cause

Tony: Subsections for each of the subsubcodes and details will be added to section.

[all additional parts optional. Encouraged to add subsubcode even if not detail]

Mark: This sets direction for CR base nicely

Anish: Pointed out that we need a mapping for subsubcode in soap 1.1

Glen: Subsitute subsubcode with subcode throughout

Marc: propose - Put subsubcode in SOAP 1.1 fault code
... Subsubcode will contain all the information and dfine subcode, so subcode is not actually required

Paco: Information in subsubcode is enough to figure out the fault even if that is absent

David: Recursive subcode helps a lot in making fault codes do more work

Chair: Feeling in room that we might want to modify these in CR - perhaps add note to draft to indicate

David: Main ones are roles in cardinialities, display and identify soap/wsa action mismatch
... comfortable with proposal

jonathon: duplicate msgId - does the enture msgid hdr go there?

David: this is wsa:MsgID - should be updated to make clear
... not against having content of messageId in there

Tony: agreed - happy to drop wrapping duplicate messageid - just messageId as element (not dupl msg id as this info is implicit)

David: Makes DuplMsgId fault consistant with action id

Jonathan: Prefer drop all wrappers or none - prefer subelement solution better

chair: We can wrap all or wrap none

jonathon: set of faults not consistent at the moment going into CR

Tony: InvalidAddressingHeader already uses InvalidAddressingHeaderQName which indicates the root header so <replyTo> with subsubcode <missingaddrEPR> will give info needed

<marc> I like the generic set of detail elements plus subcodes

Jonathan: dif options:
... Each detaul element QName of fault with structure
... [OR Not dupl that QName in datail but common elements like what is the QName of the element in question]
... Standard way of saying (eg) "this happened in the faulTo"

David: Get rid of missing addressINEPR entirely and replace with detial element eg "problemHeader" for consistancy. Case in 5.3.4 would have missing addressinEPR subsubCode with problemheader

Jonathan: would be nice to have type (e.g. QNAme) for detail element

Marc: Do we need the duplicateMsgId echoed as it will be in fault/reply msg
... Duplication avoid where possible

Tony: but receiving fault processor might look in fault info only

Paul: Don't bother enumerating each of the error conditions - just have a bag of properties for use in each fault

David: Agreed this is the direction that we are going in
... Applied pattern to the various example, taking out a layer of wrapping in some example

jonathan: In principle agree but not sure of each case

<scribe> ACTION: David/Tony to work on this over the break and clarify for each case [recorded in http://www.w3.org/2005/07/18-ws-addr-minutes.html#action01]

XML 1.1

Hugo: XMLprotocol WG considered XML 1.1 and decided to restrict SOAP 1.2 to XML 1.0
... We think this is a mistake to tie a particular version of XML due to potential future restrictions that this will cause
... Had a discussion re: XML schema for EPRs and it was decided to make XML schema normative and restricted to XML 1.0 because of the previous decision
... Now the team thinks that SOAP 1.2 should not be restricted to a particular XML 1.0 at infoset level.

<pauld> notes that since we made our descision, the schema working group published a note on using XML Schema 1.0 with XML 1.1: http://www.w3.org/TR/2005/NOTE-xml11schema10-20050511/

Hugo: By making XML schema normative in the Ws-Addressing schema we have added a restriction this is an unreasonable restriction because we define things abstractly
... so the only thing that we need to change to allow XML 1.1 to say that our XML schema is "normative to XML 1.1" (rather than "normative to XML")

Paul: WSDL working group had problems with this

<anish> i looked at the core spec and the schema types that we use are: xs:any, xs:anyAttribute, xs:anyURI

Hugo: component model of WSDL 2.0 is larger and more complex and wsdl referenced schema types throughout spec.

<pauld> WSDL 2.0 components tried to abstract XML Schema types which have an XML 1.0 symbol space

<anish> in the soap spec we use: xs:boolean, xs:unsignedLong (in addition to xs:any, xs:anyAttribute, xs:anyURI)

Hugo: Different in wsa because only xs type is xs:anyURI - could we drop this in the type and replace with "whose content is an IRI"?

anish: Currently we use boolean, unsignedlong in addition to xs:any

Hugo: boolean is in the SOAP - in any case is unlikely to change in xml 1.1

<Zakim> Marsh, you wanted to ask about consistent structure again...

chair: Concern is how do we structure language without restricting XML 1.1

chair: Can only use the schema for a validation tool for XML 1.0

Marc: would we also need to change all our pseudo schema to not use schema types

mnot: Terminology needs making more destinct - what's the relationship between schema and pseudo schema - do they both need to be normative. Perhaps more editorial

Marc: So we would have to change all the pseudo schema to not use complex types?

Hugo: 2 ways: 1. change psuedo schema xs:any to any and clarify what it means 2. xs:any is XML 1.0

umit: schemas will not be processable for XML 1.1

chair: not a problem that we don't support XML 1.1 - we just don't want to dis-allow it

Phillippe: Tying to xml 1.0 means that would need to re-write entire XML spec in order to cater for XMl 1.1.

Marc: Our SOAP binding spec is not bound to a specific SOAP binding (1.2)

<uyalcina> +1 to Paul. The cost is very high.

Paul: Allowing for XML 1.1 and XMl 1.0 means that we have to define types to enable union of XML types but the cost of this is not cheap
... if there was an XML schema which defined union types applicable for both xml 1.0 and xml 1.1 then we could use this

Paco: but perhaps the number of types is very small so not such a problem.

<dorchard> Is the WG seriously talking about supporting xml 1.1?

<Zakim> Marsh, you wanted to ask what the W3C's bottom line is.

Umit: Assume that processor only able to use 1.0 and will not be able to process xml 1.1 content and remain compliant with spec.

Hugo: no different from current

<Zakim> dorchard, you wanted to ask what was said?

Scribe missed Jonathans point for record, pls could you repeat thanks

<Marsh> What is the W3C team's bottom line position? Can we move forward in the process or is the Team objecting?

<Marsh> And, this was not a Last Call comment. It's too late to do anything. We're trying to finish the spec today and go to CR.

Chair: Would be nervous if ws-a team went to w3c with this does not cater for xml 1.1 unless we had considered carefully

Paul: We could state that we would like to move to 1.1 but requires schema from XML 1.1 to fold in errata - we shouldn't fix this in ws-a

<dorchard> Option: do nothing.

Hugo: Don't think that this is good solution as types in question are unlikely to change anyhow

<pauld> chad, question: how to support XML 1.1?

<pauld> chad, option 0: Status Quo

<pauld> chad, option 1: remove x:anyURI from core, schema is normative for XML 1.0

<pauld> chad, options 2: 1 + add text to the SOAP binding document

<pauld> chad, option 2: 1 + add text to the SOAP binding document

<pauld> chad, option 0: Status Quo + put books down our trousers

marc: option 1 means that we would need to remove all schema type references to more abstract references

<pauld> chad, option 0: Status Quo + rationalle

<pauld> chad, option 0: Status Quo + rationale

<pauld> chad, options?

<pauld> chad, option 1: remove xs:anyURI from core, schema is normative for XML 1.0

<Marsh> Option 3: Status Quo. No change to spec.

<Marsh> chad, Option 3: Status Quo. No change to spec.

Paco: Option 1: Need normative link between abstract names and actual schema (e.g. "IRI" and schema types "and in the case of XML 1.0 is xs:anyURI"

<pauld> chad, option 1: remove xs:anyURI from core, schema is normative for XML 1.0, link back to schema for XML 1.0 types

<pauld> chad, options?

<pauld> chad, drop option 3

<pauld> chad, options?

<pauld> rationale doesn't have to appear in the spec

<mlpeel> I prefer the status quo

<Marsh> STatus quo.

<yinleng> option 0

<dorchard> option 0

<Nilo> option 0

Strawpoll for option 0: 12 for option 1: 2 Abstain: 5

Chair: Group happy with status quo.

Chair: we need rational for the director for this

Chair: Can someone summarise position of WG wrt to 1.1

Jeff: This is a schema issue for us

Umit: 2 other working groups came to same conclusion and W3C should fix the problem at the source

Hugo: Schema working group recognised problem and has recommended the abstraction fix for this problem

Steve: but why is this done by each team rather than at core

Chair: Tom to write up text summarising the WS-A WGs position on XML 1.1 to represent group's decision.

<pauld> chad, new poll

<chad> new poll

LC76

Tony: Explained new proposal

David: Bag of subsubcodes that can be used for any fault detail element

Marc: Is mixed content by default

<dorchard> I'll dial back when I can.

<mnot> proxy?

Jonathan: Change problemEPRContent to ProblemHeader
... Cardinality rule - the role is important - which role is more important than how many times it's repeated.

David: call "ProblemCardinalityRole"

Tony: would like to retain ProblemHeaderQName as well as ProblemHeader

Umit: Where have attributes on wrapper elements gone

David: These were to enable more stuff under detail but we realised that weren't needed as can add multiple detail
... Error SOAPaction != wsa:Action. We need ActionMismatch containing both values

Marc: Problem cardinality - if I am playing two roles would fault contain 2 roles with relevant info?

David: yes

<mnot> LC76

<mnot> Common Detail constructs for new subcodes:

<mnot> <wsa:ProblemHeaderQName>xs:QName</wsa:ProblemHeaderQName>

<mnot> <wsa:ProblemCardinalityRole repeat="xs:int">xs:anyURI</wsa:ProblemCardinalityRole>

<mnot> (ProblemCardinalityRole + wsa:MessageAddressingHeaderRequried)

<mnot> Subcodes:

<mnot> - (of wsa:InvalidAddressingHeader)

<mnot> - wsa:InvalidAddress

<mnot> - wsa:InvalidEPR

<mnot> - wsa:InvalidCardinality

<mnot> - wsa:MissingAddressInEPR

<mnot> - wsa:DuplicateMessageID

<mnot> - wsa:ActionMismatch

<mnot> Detail for ActionMismatch:

<mnot> <wsa:action>anyURI</wsa:action>

<mnot> <soap:action>anyURI</soap:action>

<mnot> LC76

<mnot> Common Detail constructs for all subcodes:

<mnot> <wsa:ProblemHeaderQName>xs:QName</wsa:ProblemHeaderQName>

<mnot> <wsa:ProblemCardinalityRole repeat="xs:int">xs:anyURI</wsa:ProblemCardinalityRole>

<mnot> Subcodes:

<mnot> Of wsa:InvalidAddressingHeader:

<mnot> - wsa:InvalidAddress

<mnot> - wsa:InvalidEPR

<mnot> - wsa:InvalidCardinality

<mnot> - wsa:MissingAddressInEPR

<mnot> - wsa:DuplicateMessageID

<mnot> - wsa:ActionMismatch

<mnot> Detail for ActionMismatch:

<mnot> <wsa:action>anyURI</wsa:action>

<mnot> <soap:action>anyURI</soap:action>

<Marsh> I think we could rename wsa:ProblemCardinalityRole to wsa:ProblemRole

<Marsh> I think we could fold <wsa:action> into wsa:ProblemHeader, pair it up with wsa:ProblemIRI for soap action

Chair: Marc, is this enough information?

Marc: Think so

<Marsh> <wsa:ProblemAction soapActoin="...">action value</x>

Jonathan: rename ProblemCardinatiltyRole to ProblemRole

<mnot> three options:

<mnot> <wsa:action>anyURI</wsa:action>

<mnot> <soap:action>anyURI</soap:action>

<mnot> <wsa:action>anyURI</wsa:action>

<mnot> <soap:action>anyURI</soap:action>

<mnot> three proposals for actionmismatch syntax:

<mnot> <wsa:action>anyURI</wsa:action>

<mnot> <wsa:soapAction>anyURI</wsa:soapAction>

<mnot> <wsa:action>anyURI</wsa:action>

<mnot> <wsa:soapAction>anyURI</wsa:soapAction>

<mnot> 1

<mnot> 2

<mnot> <wsa:action>anyURI</wsa:action>

<mnot> <wsa:soapAction>anyURI</wsa:soapAction>

<mnot> 3

<mnot> <wsa:action>anyURI</wsa:action>

<mnot> <wsa:soapAction>anyURI</wsa:soapAction>

<mnot> 4

chair: straw poll resulted in option 3

marc: invalidcardinality seems confusing

Vote was for number 3

marc: InvalidCardinality - Return headers and they are targeted as roles (i.e. don't need role)

David: could we just send roles that the EP was playing - it would be nice to have a SOAPY way to identify the role that was being played at the time of error

Glen: don't see need for role

[in ws-addressing - could be in metadata]

David: How can you figure out why didn't get action because receiver was playing unexpected role?

Chair: This is outside remit of LC76

Marc: Proposal to delete ProblemRole

David: Think this is a driver for LC76

Vote 1 for in; Vote 6 for out

marc: Think we require further consideration regarding the usage scenario of this.

Lots of discussion about the use of ProblemRole.

Tony: We need a mechanism to resolve whether error is due to role.

Glen: Don't need to say more than header and how many recipient saw

Anish: Cardinality could be rolled in with MessageAddressingHeaderRequired

David: Perhaps this defining of the role in the error should not be at the WS-A level (should be at SOAP level) but don't want to lose the role info.

Paul: Although optional this is going to have an impact on test so will still impact workload

Marc: Must have 4 implementations for WS-A - do all need to include every optional feature?

Umit: As role is the be contentious issue, why don't we just mark as risk and move on

Chair: David - can you live with dropping problemRole?

David: yes, progress has been made with subcodes

Chair: we can always add it to section in CR at a later point

<mnot> Revised Proposal:

<mnot> LC76

<mnot> Common Detail constructs for all subcodes:

<mnot> <wsa:ProblemHeaderQName>xs:QName</wsa:ProblemHeaderQName>

<mnot> New Subcodes:

<mnot> Of wsa:InvalidAddressingHeader:

<mnot> - wsa:InvalidAddress

<mnot> - wsa:InvalidEPR

<mnot> - wsa:InvalidCardinality

<mnot> - wsa:MissingAddressInEPR

<mnot> - wsa:DuplicateMessageID

<mnot> - wsa:ActionMismatch

<mnot> Detail for ActionMismatch:

<mnot> <wsa:Action>anyURI</wsa:Action>

<mnot> <wsa:SoapAction>anyURI</wsa:SoapAction>

<mnot> * Add ednote that fault details may change, be added to based on implementation experience.

<mnot> e.g.,

<mnot> <subcode>wsa:InvalidCardinality</subcode>

<mnot> <wsa:ProblemHeaderQName>wsa:Action</wsa:ProblemHeaderQName>

hugo: should add editorial note requesting feedback based on implementation

David: registers gratitude to group for this and to long suffering editors for patience

Chair: Last call issues are all now closed.

RESOLUTION: LC76 resolved with proposal posted. ProblemRole not included. Editorial note to say that fault details may change based on impl experience

thanks Steve

Chair: How do people feel about voting on going to CR prior to seeing draft from Marc

People would like to see draft.

Chair: Vote will take place on Monday

<anish> do we have a diff between LC and current editors' draft?

TOPIC XML 1.1 (returning from prior to break)

XML 1.1

<TRutt> "This specification uses xml schema 1.0 data types to specify the contents of its soap headers. This was deemed necessary to define the contents with sufficient precision to foster interoperability. Future versions of this specification may be revised to incorporate schema definitions compatible with xml 1.1."

<anish> i know we have a changelog in the ed's draft, but i'm looking for a html diff

<marc> hugo can generate diffs once I'm done with the edits

<uyalcina> I propose adding a statement: The introduction XML 1.1 causes interoperability concerns in real implementations far out of proportion to the profferred benefits at the abstract level.

Anish and Umit registered discomfort with having a note.

Chair: Can capture rationale of group without adding anything to text.

RESOLUTION: No action agreed to at this point

What makes message WS-A

From emails if mu=1 on hdr then SOAP engaged.

umit: clarify how soap processing interacts with wsa semantics in case where some wsa headers are mu1 and some mu0

Tony: If WS-A only EP then ws-a is engaged by default.

<dorchard> I think there are 2 ways that wsa can be engaged at the receiver: 1) put an mU on the header; 2) put a wsdl decoration that says it's required.

<dorchard> ok, I'll dial in when I can

<RebeccaB> scribe - rebecca

XML 1.1

Phillippe: 90% sure going to get push-back from director if go to CR now

Phillippe: need way to use 1.1 without needing to define all the specifications

<RebeccaB> phillippe (xml schema 1.1

Phillippe: people will not want to rev the spec just to deal with 1.1

uyalcina: didn't we take a vote already on this?

mnot: phillippe just giving his perspective based on understanding how the process works

Phillippe: if not do something, we should have good transition story for diector on how we support 1.1 in future

Marc: Phillippe is saying it's pointless to continue unless we address this issue

mnot: if goes to director and he pushes backl, we lose

<marc> think we should consider an alternate approach

mnot: if he pushes back, and we're in hiatus thru August, we could be held back until end of september dealing with this

anish: what xml schema's plan?

Phillippe: no timeline on structures

<dorchard> If the director pushes back, that's his call. I'd rather not guess what he'll do.

Phillippe: they are currently actively working on versioning and instantiability

uyalcina: what happened to RECs?

anish: issue raised about soap 1.2 not supporting xml 1.1

anish: in process of asking for proposed editor recommendation - team says possible push-back

<Zakim> Marsh, you wanted to say Schema 1.1 is not the problem. XML 1.1 is the problem.

jonathan: problem not schemaq 1.1, problem is xml 1.1 - it's dead in industry, not being implemented

jonathan: would jump thru hoops to protect timelines, but this wouldn't help interop

<marc> anish tells me that jaxp 1.3 required support for xml 1.1

jonathan: suggest adding something in spec to support it and ask director to rescind xml 1.1

phillippe: Sun has more than one implementation - undertand Microsoft doesn't suppport, but that doesn't reflect everybody's opinion

<dorchard> formally, BEA systems doesn't support xml 1.1

jonathan: has no value on ground for web services

trutt: if add statement 'you should never use C1 control characters' then data types for 1.0 would flow for 1.1

trutt: that's only non-backwards compatible iswsue

<dorchard> but it's a big enough backwards compat issue.

trutt: I want precision of schema language

<dorchard> xml 1.1 is neither forwards nor backwards compatible. Shouldn't have been called "1.1", should have been "2.0" instead.

mnot: had straw poll earlier - status quo; hugo's proposal; abstentian - curious if this discussion around Phillipe has changed

mnot: phillipe's statement has changed people's opinions around this

mnot: has anybody changed their minds?

mnot: 3 or 4 people have changed mind

<dorchard> I haven't changed.

<uyalcina> I have not changed my mind, either.

phillippe: I would hate to come back and say director has pushed back on me.

<dorchard> so sorry.

<TRutt> i have not changed my mind

bob: what would be minimalist delta necessary to achieve satisfactory 1.1 support as far as director is concerned?

<dorchard> this is too hard: predicting what the director will/won't object to. If he wants to write the spec, he can do that.

hugo: my earlier proposal; phillipe concurs

dorchard: pushback from director is life, sometimes

dorchard: if he wants 1.1 support, he should have objected to charter

<mlpeel> +1 to dave orchard's comments

<Marsh> +1, to a timely LC comment at the least!

<uyalcina> +1 to David Orchard and JM!

dorchard: let director make changes if he desires, but let's not try to second guess him; let's move forward

<Nilo> +1

<Marsh> I like that, but I'm under intense schedule pressure.

mnot: phillippe has talked with Tim earlier

phillippe: I talked to Tim about that and we did talk with xml schema WG and Tim does have strong feelings about that

dorchard: Time is concerned, I'm also concerned, but that's not the point. ws-addressing shouldn't be the ones having their feet held to the fire on this

dorchard: we should move on and see what happens

umit: if phillippe is representing to the director the companies here, he should be told that we feel we are trying to solve problem that doesn't belong to us

pauld: has to be sorted out in generalized fashion but at cost to our schedule. all the options lead to a cost to our schedule

mnot: i'm hearing don't take the dependency here

trutt: is fix 'that' small that we could do it overnight and take a look at it?

<dorchard> we shouln't be trying to create schema 1.1 that deals with xml 1.1

mnot: hugo proposal - make schema normative for 1.0; make specific references abstract

<Zakim> dorchard, you wanted to say that XML 1.1 isn't mentioned in our charter. If timBl had wanted it in ws-a, then the charter should have said that.

dorchard: our charter doesn't say anything about xml 1.1; if AC wanted that they could have said something.

dorchard: this is wrong to be considering the day before moving on to CR

hugo: charter doesn't say anything about 1.0 either

jonathan: proposed compormise - add in Hugo's proposal, mark at risk, take to director and take out if he agrees

<pauld> hopes this won't form a 'substantive change'

mnot: only features can be marked at risk

jonathan: this IS a feature

jonathan: if important to add, then it must be a feature

mnot: how does it show up in spec if we mark it at risk?>

phillippe: we are not testing it, so why remove it?

mnot: hugo proposal approaching the table; idea of marking at risk; would like straw poll by company

marc: not interoperability issue - nothing proposed impacts interoperability - that

<RebeccaB> 's in binding and what we're discussing is at abstract level

marc: marking at risk is a little silly since we not adding something that will be tested anyway

mnot: would like straw poll

<RebeccaB> for or against status quo

PaulKnight: what is work involved?

<Marsh> +1 stop and move on.

<Nilo> for

<DaveO> this is

<Nilo> for=status quo and move on

<uyalcina> Dave, do you want the status quo or not?

<DaveO> status quo!!!

<Marsh> !!!!

poll: status quo = 5

poll: do something = 5

<DaveO> Maybe time for a formal objection..

poll: anstentain : 5

<RebeccaB> s/anstention/abstention

mnot: hugo to make proposed changes, show them to group and we will discuss later

mnot: motivated because it's better to have all the info possible

dorchard: we can't seem to progress

mnot: any other issues before moving to CR discussions?

mnot: need time to talk about formal objections - asking Glen to show his

mnot: time to talk about those, next steps in CR, time for Hugo (15 or 20 minutes)

mnot: anybody leaving earlier than 5:00 (a couple responded positively)

mnot: have 1-1/4 hours

mnot: 1/2 hour per objection?

mnot: want to make sure objections are heard and understood, with time for people to respond.

What Makes a Message WS-A

mnot: 15 minutes on 'what makes a message wsa?'

Katy: propose answer based on earlier discussion

Katy: if receiver can accept both wsa and non-wsa, case ambiguous

Katy: behavior should be based on whatever client intended behavior to be

Katy: client's intention expressed by existance of one or more wsa headers in message

dhull: if we're talking about client's intentions, we're off the deep end

dhull: out of scope

<dhull> advertising party sets the contract

anish: closely related issue not discussed before ; consensus emerging - if mU false, it's choice of receiver whether to engage wsa or not

<DaveO> If service says "send me ws-a" then it's clear. If service says "maybe send me ws-a" then it's unclear when to fault.

anish: if receiver chooses NOT to use wsa, how does it determine NOTG to process refparams shich are part of wsa?

anish: what is receiver supposed to do when it's not wsa-aware?

glen: disagree, but separate issue

glend: agree that thinking about client's intention is exactly backwards

glend: one thing needing change is not yet clear statement in pur spec that says if you process one of the wsa headers, then must follow all wsa rules

paco: is in scope of WSDL binding

paco: when have 'required', we have defined the monster so we must specify how the monster behaves

paco: if wsa headers exist, we need to define behaviors - it IS in scope, contrary to dhull's assertion

paco: regardless of mU if at least one header with wsa attribute, if something is not there you send back right exception

anish: are you saying that if wsa header is used, but not quite4 correctly, then it must be processed more leniently?

<Zakim> DaveO, you wanted to say that "if mU set then its clear" isn't quite enough

dorchard: what if not marked with mU and neither cleint nor service require, what happens when a faulty wsa arrives - fault or ignore? scenarios need clarifying

umit: I want clear semantics on when we engage and what we do

umit: general consensus that soap process model is key

<dhull> Disagree that mU has much to do with this.

umit: are we relying on mU or not? what is it bringing to us?

<DaveO> I guess there's another strange case, which is that a sender sends a ref param and invalid other ws-a headers. Should the ref param be ignored?

anish: paco said mU irrelevant - I don't agree

anish: worth figuring out for receiver if should engage wsa or not

anish: useing addressing soap header might be good idea

mnot: 20 minutes spent on issue

<RebeccaB> mnot sytraw poll - do we need to deal with this before taking core and soap specs to CR

umit: what's point of CR except to deal with bugs like this?

mnot: this looks like it will require a lot of discussion but can be dealt with in a sentence or two

hugo: can disambiguate in CR

mnot: ask group if should consider before CR or during CR?

dorchard: would prefer to deal with later, but problem if do while in CR and write test that has two different implementations - one faults and the other doesn't

dorchard: decide on which way to go in CR and add clarifying test at that point

dhull: when we test things in CRE, we are going to CR on core and SOAP bindings and therefore unconditionally have wsa engaged. if there is problem, should fault - otherwise out of scope

marc: soap binding conformance section already nails this quite well

<dhull> marc is at least mostly right on that

glen: larger soap issue - no externally visible way to tell how the endpoint will process something - therefor cannot lay requirement to process something unless 'required' specified

mnot: let go for now

<DaveO> Deal with it in CR. If it's not a CR test, then no harm no foul.

mnot: 10 minute break; return and discuss two formal objections

Formal Objections

mnot: first, understand nature of objections being made, double check for new info, then decide what to do about

mnot: if people's minds changed, take a look and stop for a sec; focus on understanding pro and con positions and if we as WG want to make response, take that to director

mnot: not spending time on contention

mnot: anish first

<RebeccaB> mnot cap at 1/2 hour

<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005May/0047

mnot: first objection about binding of refprops in soap

anish: objecting to mapping of abtrary refparams as soap header block

anish: serious security defect

anish: email makes 4 difffernt points - most important is safety and security problem; second is composability

anish: #1 - safety and security - sender responsible for including soap header blocks

anish: sender repsonsible for values and for the choices

anish: soap headers have well-defined contracytual obligations

anish: minter says header must go to destination

anish: it's echooing device with no restrictions on what goes in refparam and what gets echoed back

anish: different from cookie model

anish: never says what content should be that's echoed back

anish: unlike sopa headers for epr

anish: e.g. refparam with account

anish: #2 COMPOSABILITY - common with all ws-* specs; especiall in context of SOAP, there are soap modules that are independent of other soap models

anish: ws-reliability, context, whatever - so I can choose which ones I want to implement, put them together and implement my app

anish: but problem composing ws-security

anish: #3 - build processing logic with ws-addr, wss, but now every module must check to make sure use with other headers is allowed

anish: other tokens can sneak in thru refparam

glend: every piece of code is going to have to check if some set of headers exist

glend: one module used to do processing of own headers; now, with soap headers and refparams, modularization is broken

anish: depends on configuration - there areinteractions across modules that have to be handled at system level rather than module level

anish: 4th - validation of soap header block

anish: not every soap header block not required to allow extensibility

anish: what happens if don't know wsa but inadvertantly consume refparam?

anish: roles, versions, list of stuff to be concerned about

anish: make wsa to: and epr - corrects many probs

anish: define bag of refparams and put all in particular soap header block - scopes all refparams to block with specific semantics

anish: new info - addresses concern supporters of status quo had

anish: #2b - separate header block cannot target diff't refparam to different roles since all in one bag

anish: 2b proposes multiple bags

anish: indiv soap header blocks for separate refparams, so can target for separate roles

anish: proposals are starting point for looking for compromise solution

mnot: looked thru minutes of f2f in Melbourne

<mnot> http://www.w3.org/2002/ws/addr/5/01/18-ws-addr-minutes.html#i008

mnot: we discussed in number of place effect of targeting to intermediaries

mnot: later discussed specific proposal we talked about where refp are targeted

mnot: does Anish's proposal change anybody's mind?

anish: we didn't discuss this specific proposal - we talked about to: and targeting, but not this particular solution

anish: filing of objectikon may have changed people's mind since will be addressed by director

anish: personally believe this is new solution we haven't discussed earlier

<Marsh> I don't consider the proposal innovative. It's a small variation on a number of ideas we considered the first time rougnd.

mnot: we went back and forth on wrappers, putting refp attribute on headers

glend: I was in bad standing; were other notable people missing at this discussion?

mnot: hard won decision requiring a lot of work; wqant to see light at end of tunnel if we reconsider

umit: not clear when security was discussed WRT EPRs in general

glend: origin from much earlier message of mine

mnot: asked again and again for use cases and they were difficult to bring out of woodwork

<uyalcina> clarification: My question was about when security was discussed with respect to the timeline of when the decision was made

dorchard: our main coincern was security aspect - being hacked and bogus header block inserted into message - BEA's only concern at the time but in straw poll nobody else concerned

dorchard: BEA unconvinced about changing its mind - insufficient new information

<yinleng> +1 to DaveO from HP

dorchard: BEA position remains the same

jmarsh: Msoft liked attribute but nothing wrapper would provide that attribute didn't. attribute sufficient and we're in favor of it, but that's not sufficient new info

anish: responding to Dave's comment about attribute - it's important for wsa to coexist with nonwsa apps

anish: attr doewsn't help in that case

mnot: have people changed their minds?

<GlenD> The wrapper solution does not force the receiver to process referenceParameters at all unless it wants to. They are NOT in fact first-class headers in that case. The attribute solution, I think, is not a solution at all since non-WSA endpoints will still process those headers in exactly the same way as if the attribute was not there.

mnot: people who voted for isRefParam attr - would you change your vote?

<dorchard> BEA systems hasn't changed it's mind.

jmarsh: some of people on objection weren't members or in good standing when originally discussed - how can we make progress if revisit when members change?

<dorchard> Seems bogus. Lose an argument in the WG, then wait until enough people friendly to your position have joined and reask the question with only 50%+1..

mnot: poll : is new informaytion that would change the spec and therefore we should reopen issue?

<yinleng> HP has not changed

<mlpeel> Novell has not changed

<Marsh> No new information

poll: shall we reopen the issue?

<yinleng> No new information

<dorchard> prasad said no...

poll: in favor - 11 ; opposed - 9 ; abstain - 2

mnot: 2 of yea's in bad standing

<Marsh> we're extremely opposed to stretching this out for another couple of months.

<dorchard> seems like dead-heat = don't re-open. Need clear majority.

<Marsh> No consensus to reopen.

<marc> no consensus to proceed ;-)

<yinleng> I did raise an issue, but don't want to delay moving to CR

<marc> lets toss a coin

mnot: for: sonic; oracle; Arjuna: CA; Sun; Fujitsu; Tibco; Hitachi; SAP; ericsson; SeeBeyond

<Marsh> and keep tossing it until you get the results you want...

<marc> works for me

mnot: against: IBM; IONA; Nokia; BT; Novell; BEA; Miscrosoft; HP; WebMethods

mnot: abstain: Nortel; W3C

<dorchard> I'd like to toss a coin about whether to toss a coin.

<dorchard> And then have an STV on how many times to toss the coin

anish: think we should proceed and open issue since so many support it

<dorchard> why swap one formal objection for another?

mnot: agree that it's contentious, but given fact that this is scheduled focused working group, then have to go with status quo

mnot: if go down this route, might consume a couple of months working on it

anish: perhaps but w3c i\s about achieving consensus

jmarsh: already past shedule in charter and it needs to be delivered - affects product plans

anish: i'm worried about getting spec right rather than product plans

dorchard: worried about delivering to customers a member submission rather than a recommendation

<dorchard> For the record, BEA is pretty convinced that changing this issue will swap one formal objection for another and dramatically hurt the chances of the Rec getting into customers hands.

glend: if someone doesn't underswtand an extention, can behave in any way they want

<RebeccaB> (This is Glen's objection now being discussed)

glend: epr's a bucket of metadata being passed around and if someone extends in important way, then need way to say 'this is important'

glend: solution - add mustUnderstand attribute

glend: policy can be ignored with rules we have right now

glend: potentially bad - number of us feel this is simple thing to do

<dorchard> It's simple and obvious. It would be really hard to use the soap processing model to come up with a soap header block that refered to the EPR and said "you mustUnderstand that EPR".

mnot: when we go to director, this objection will be taken for consideration

mnot: Hugo's proposal for XML version independence

Hugo's proposal for XML version independence

<dorchard> I don't see Hugo's proposal.

<dorchard> Wow, i like the speed of dealing with this formal objection :-)

hugo: one way to do this is to make xml schema 1.0 normative

<RebeccaB> http://lists.w3.org/archives/public/public-ws-addressing/2005jul/att-0147/diff.html

<Marsh> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0147.html

marc: defining infoset representation for xml 1.0 serialization

hugo: discussion of edits made in doc

hugo: showed reference to schema type wherever elements mentioned

hugo: walked thru document showing instances of his editing

marc: more accurate to say element with same content model as this other element

hugo: believe changes are limited in soap binding doc

<dorchard> I fail to see how this helps. If SOAP 1.3 with XML 1.1 support emerges, then we'll have to have a new spec for that. SOAP 1.3 with XML 1.1 support *CAN'T* be backwards compatible with SOAP 1.2.

hugo: schema normative for serialization

hugo: meat of change is the normativeness of the schema

anish: does qname change?

marc: now not xs:Qname, just Qname

hugo: yes, production of Qname is different

<Marsh> That seems insufficient.

mnot: questions for hugo?

<Marsh> SHould perhaps be an enumeration of the expected QNames?

mnot: who supports status quo, who supports adoption of proposal, who abstains?

jmarsh: we had discussion & poll this morning!

<pauld> worries that qnames is where the difference would matter - is QName abstracted by the Infoset?

mnot: phillippe's argument was new info

<dorchard> sigh. BEA Systems supports the status quo

poll: who supports status quo?

<Marsh> Microsoft supports the status quo.

<mlpeel> Novell supports the status quo

<dorchard> I fail to see how this solves the problem of "what is a string or QName type".

<Marsh> That's implementation defined at the abstract level ;-)

<RebeccaB> support status quo : 8

poll: who supports Hugo's proposal?

<RebeccaB> supports hugo : 10

poll: who cannot live with the status quo?

<Marsh> One with Tim is a majority...

poll: who cannot live with hugo's proposal?

<Marsh> Sigh. Only thing worse would be 2 months more schedule slip...

<RebeccaB> who cannot live with either?

poll: whoi cannot live with ... = 0 on all alternatives

mnot: since 10 to 8, shoiuld consider Hugo's proposal in next ten minutes

<dorchard> Again, I don't see 2/3 of a WG voting for this. Maybe if it was 12-6 I could see re-opening..

<dorchard> The bar to "slip schedule" should be quite high. That's why BEA didn't lobby hard to re-open the EPR processing model, even though we're bothered by it.

mnot: salz amendment

mnot: "Note that all schema constructs in this document are to be taken as XML Schema 1.0 for XML 1.0 serialization" - stick this in spec instead of Hugo's proposal

<dorchard> So what does Phillipe say about Rich's proposal? Would that make a 0% chance of schedule slip because of this issue?

hugo: didn't understand from Rich's proposal is to just add note?

umit: add rich's statement, keep {any}, etc.

mnot: proposal to accept Hugo's proposal but take parenthetical statements and put them all in one place and say once only

mnot: hugo plus table at top proposal

mnot: do peole think this is best way forward at this point?

mnot: three people agree

<dorchard> no. I can't see how we do CR on this..

mnot: any objection to accepting proposal?

<dorchard> yes

<dorchard> BEA Systems objects because we are convinced this will increase complexity and reduce interoperability

<Marsh> me too. Battery died just as I said it.

mnot: roll call vote

<RebeccaB> fomal vote to accept propsal with modifications

BEA: no

BT: no

CA: yes

Ericsson: no

fujitsu: yes

hitachi: no

hp:

IBM: yes

IONA: abstain

<Marsh> Microsoft: no

Microsoft: no

Nokia: yes

Nortel: yes

Oracle: abstain

Novell: no

SAP: no

Sonic: yes

Sun: abstain

tibco: yes

W3C: yes

webMethods: no

tally: yes - 8; no - 8; abstain - 3;

<RebeccaB> Fujitsu changes to abstain

tally: yes - 7; no - 8; abstain - 4

RESOLUTION: no change to accommodate XML 1.1.

Candidation Recommendation Discussion

mnot: polled non-WG people about substantive changes to drafts - 2/4 said no

jeff: we might end up going back to last call

jeff: suprised about Mark's statement about going back to working draft rather than last call

mnot: features at risk - anybody think something should be marked?

mnot: we have one already

anish: we put in note in LC draft in LC section saying that this not adequately specified - we should decide to pull that out or not before going to CR

anish: section 3 of core - housekeeping thing

mnot: natural to take text out because feedback period is over

mnot: (to Marc) please remove it

mnot: CR exit criteria

mnot: do we want to link soap and core docs going to PR to the status of the WSDL document?

glend: yes!

glend: at least in last call

glend: wsdl part of markup is important part of testing

mnot: can have test case based on external docs at an early stage

phillippe: if depending on another spec, cannot move more than one step ahead of that spec

mnot: core and soap have dependency on wsdl

mnot: displaying interop across 4 implementations adedquate?

pauld: transport? other issues?

mnot: everybody think on that and we'll see how it goes

pauld: hoping to get more test cases

mnot: must nominate lock period - tell world period of time before we go to PR to give people period to implement

mnot: must give estimate time for implementation feedback

<pauld> looking to the async TF to provide usage scenarios

mnot: no minimum period of time

mnot: if able to make minor changes by next week, then take time off

<dorchard> I have to sign off now for a doctor's appt.

mnot: if take august off, no productive work on test suite until september

mnot: talk to test and q/a folks and get them involved

mnot: if meet in sep. for F2F, maybe close CR in November

<RebeccaB> mnot who not available in august (week by wekk)

mnot: any usefulness to first week after just going to CR?

mnot: (to PaulD) useful to have telecons to help testing?

mnot: anybody concerned about taking month of august off, assuming we go to CR?

mnot: looks like that's what we'll do

mnot: might have call on August 29th

mnot: maybe take quick poll on web to check availability - have a sporadic meeting maybe

phillippe: if we send something to director, the director has two weeks to answer

<RebeccaB> meeting over!

mnot: idea of having an interop event during CR period with external people

Web Services Addressing Working Group F2F

19 Jul 2005

Attendees

Contents

LC76

XML 1.1

LC76

XML 1.1

What makes message WS-A

XML 1.1

What Makes a Message WS-A

Formal Objections

Hugo's proposal for XML version independence

Candidation Recommendation Discussion

Summary of Action Items