WS-Addressing WG Face to Face meeting -- 2 Mar 2006

<Nilo> scribe:Nilo

<Jonathan> http://www.w3.org/2002/ws/addr/testsuite/report/

agenda approved, with test status update included

Feb 20 minutes approval postponed to tomorrow

test results from Jonathan: 5 implementations tested, results shown, basically a sea of green

a few optional features have no implementations; so they are at risk

Bob would like to get PR text completed today and wants everyoe to work towards that

AI review - all AIs completed

Umit concerned about lack of WSDL implementations affecting the WSDL binding

Bob says that we have a choice re WSDL binding - choice of 1) making doc a Note or 2) changing the number of implementations needed to progress it

proposed issue 1

<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2006Feb/0000

DH thinks this is a potentially editorial change and can be done after we have agreed to the other changes to this text. He proposes discussion be deferred until later

Umit: how is SOAP1.1 text affected?

proposed issue 2

<Jonathan> http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2006Feb/0002

jonathan: two action values - one for addressing-specific faults, another for application-level ones

Hugo: concern with the term "generic SOAP faults"

general consensus re the action value for the addressing-specific faults

with one addition: add a reference to the section on the Faults section

<bob> The [action] property below designates WS-Addressing fault messages:

<bob> http://www.w3.org/2005/08/addressing/fault

<bob> *This action SHOULD NOT be used as an action value in messages other

<bob> than those carrying WS-Addressing faults.*

section 6.4

<bob> SOAP modules, extensions and applications SHOULD define custom [action] values for

<bob> the

<bob> faults they describe but MAY designate use of the following [action]

<bob> value

<bob> instead:

Katy: change "generic faults" to "such as..."

DaveO: call them "SOAP defined faults" instead of "generic SOAP faults"

<dorchard> SOAP defined SOAP faults

The above [action] value SHOULD be used for SOAP defined SOAP faults including
version mismatch, must understand, and data encoding unknown. *This
action SHOULD NOT be used as an action value in messages other than
those carrying SOAP defined SOAP faults or those of SOAP modules and extensions.*
I use SHOULD because this is a hard thing to test, seems like the
appropriate level of guidance, and doesn't force a breaking change in
implementations at this point.

Marc: seems a bit contradictory

Glen: may want to have infrastructure choose the appropriate action value

consenusus building around closing the second part with no action

Umit: what's the reason for the second part

Jonathan: it would be nice to know if it was a generic SOAP fault as opposed to a app level fault.

Glen: it almost seems like over-riding SOAP fault codes

Anish: still need to change the para between the two action value.

<anish> in section 6

This will be marked as CR24

Resolution: CR24

as above, accepted without objection

One paragraph out-optional-in note

<bob> The above [action] value SHOULD be used for SOAP defined faults

<bob> including

<bob> version mismatch, must understand, and data encoding unknown. *This

<bob> action SHOULD NOT be used as an action value in messages other than

<bob> those carrying SOAP defined faults or those of SOAP modules and

<bob> extensions.*

<bob>

<bob> I use SHOULD because this is a hard thing to test, seems like the

<bob> appropriate level of guidance, and doesn't force a breaking change in

<bob> implementations at this point.

<bob>

<bob> Original thread that sparked this follows...

<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/att-0072/soap11reqoptresphttpbinding.html

<dorchard> This SOAP 1.1 request optional response HTTP binding, in conjunction with the SOAP 1.1 binding, can be used for sending request messages with an optional SOAP response. This binding augments the SOAP 1.1 binding by allowing that the HTTP [RFC 2616] response MAY have a 202 status code and the response body MAY be empty. Note that the HTTP [RFC 2616] specification states "the 202 response is intentionally non-committal". As such, any content in the respon

<bob> This SOAP 1.1 request optional response HTTP binding, in conjunction

<bob> with the SOAP 1.1 binding, can be used for sending request messages with

<bob> an optional SOAP response. This binding augments the SOAP 1.1 binding

<bob> by allowing that the HTTP [RFC 2616] response MAY have a 202 status code

<bob> and the response body MAY be empty. Note that the HTTP [RFC 2616]

<bob> specification states "the 202 response is intentionally non-committal".

<bob> As such, any content in the response body, including a SOAP body, MAY or

<bob> MAY not be an expected SOAP response.

<dorchard> As such, any content in the response body, including a SOAP body, MAY or MAY not be an expected SOAP response.

Umit: can the last sentnce be reworded?

Anish: this is an op response, so you could also get back 202 with and without a SOAP env, as well as a 200 with a SOAP env

Bob: we need new text starting from "As such..."

<marc> At the risk of prolonging the discussion I note that SOAP 1.1 doesn't preclude a HTTP 202 without a SOAP entity body: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383529

Anish: propose striking sentence starting "As such..."

Jonathan:

how does this affect the test suite

Glen: the 202 is used in the test suite

<dorchard> Another slight wording mod of the last 2 sentence..

<dorchard> Note that the HTTP [RFC 2616] specification states "the 202 response is intentionally non-committal" and so any content in the response body, including a SOAP Envelope, MAY not be an expected SOAP response.

Text above agreed

RESOLUTION: Out-optional-in MEP is accepted and will be published as a WG NOTE

Break until 10:45

<bob> above resolution is to clean up and publish the note:

<bob> N.B.

<bob> Bob- talk to hugo about how to publish

resuming meeting again

Topic: CR23

<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0189.html

<anish> alternate proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0005.html

Anish: has an alternative proposal and suggests that this isuue be closed with no action

umit: it is WS_RX's choice to use our anon URI or mint their own

Glen: agrees with Anish
... we don't need to encourage WS-RX to use this URI in ways that may not be these semantics

Katy: the semantics is that it depends on the underlying SOAP transport binding
... It allows RX to go either way - use this URI as we define it or define their own URI for acksTo

<uyalcina> I am very uncomfortable in reverting a request that came from RX and forcing a particular decision on them,

<uyalcina> we should give them the choice

Anish: not comfortable with making its meaning context sensitive

Jonathan: there is value in making this URI mean that it depends on the infrastructure
... in short, agreeing with Katy

DH: if you are using anon, you need to understand the context it is to be used

<Zakim> GlenD, you wanted to indicate that using a different URI is more comprehensible than looking up a namespace for an EPR header such as <wsrx:AcksTo>

Tom: could go either way, but does not see why a spec can't define its own EPR's semantics

Glen: in summary would prefer WS-RX to mint its own URI

DOR provides an analogy to java abstract vs concrete classes

anish: we don't disallow use of anon in any other context. we simply define its use for reply/failtTo

<GlenD> Tom just made an interesting point - when you see a URI, you tend to want to deference it to see what it means...

umit: there is an abstract/concrete analogy. abstract is "any back channel" while concrete is specific back channels in specifc contexts

<GlenD> If it's RX's "sequenceBackchannel" URI, that's clearer than "W3C's no-real-meaning-anonymous URI"

anish: the current text encourages you to use this URI in a different context

<Zakim> TonyR, you wanted to addressing RX minting their own URI

Tony: RX should define their own URI because it has a different meaning

<Zakim> dhull, you wanted to point out that RX is not the only potential reuser of anon

<uyalcina> Please folks, WS-RX ASKED us to loosen up the definition of the URI for them.

<uyalcina> This is why we are discussing this

<anish> the issue about implementations changing is a red herring, imho, it does not change the impl much. There are a whole lot of changes that are currently taking place in wsrx which are huge compared to this tiny 'if' stmt change

<uyalcina> +1 to DH.

DH: we should leave the door open for future SOAP bindings which have back channels; so we should provide guidance for what anon might mean for them

<Zakim> dorchard, you wanted to follow my nose on <wsrx:acksTo>wsa:anon</wsrx:acksTo> vs <wsrx:acksTo>wsrx:anon</wsrx:acksTo>

Hugo: support Anish's proposal

<Katy> Additional text does not force rx to use anon URI - just states that, if it is used, the behaviour must be specified in RX context.

DO: in either case, the RX spec implementers will have to look at their spec to see how the anon value is used

Jonathan: wants to allow anon to be used with AcksTo as used today

<Zakim> GlenD, you wanted to call the question (let's vote!)

Tom: happier with Anish's proposal, but could edit Katy's proposal to meet concerns

<dorchard> Is it almost the straw poll of "do you want anon re-used or not"?

Glen: want to get a sense of the group

Katy: RX implementations are using the anon URI

Marc/Anish: they are not using this CR anon URI

<pauld> has no sympathy for WS-RX, they're referencing a moving target

Anish: RX uses the old anon URI

Umit: the semantics of the old anon URI was "any back channel" which is what Katy's proposal is trying to capture

<GlenD> Umit - it doesn't matter that it's the SAME anonymous URI as addressing uses, though, does it?

<GlenD> If they need to change anyway, is it that big a deal?

<uyalcina> it does matter to RX.

<uyalcina> They asked us to define it for them

<pauld> what implementations are using our freshly minted URI?!

<GlenD> I'm asking Umit the architect/developer, not Umit the politician. :)

<uyalcina> i was the one who raised CR4 on behalf of WS-RX

poll to adopt katy's proposal

straw poll: for 6 against 8

Tom: the input WS-RX did not use "anon"

Bob: can we live with no action?

<dorchard> And, can we live with Katy's proposals?

Umit: I was given the AI by WS-RX TC to define the use of "anon"

Bob: I have an ongoing AI with WS-RX to keep tabs on movement to cr4, thus I will communicate to WS-RX what has changed
... What needs to change in the proposal to make it acceptable?

DO: I thought we voted for the intent, not the exact text

Glen: Minting URIs is easy and there does not seem to be a benefit to use the same URI with different meaning

DH: WS-RX found the "back channel"semantics of anon to be useful to reuse

<Zakim> dorchard, you wanted to ask more people

Vikas: For a non synchronous transport, you do not want somebody to specify what the back channel is

Anish: does not achive the reuse objective. WS-RX sequence can make use of many differnt binding fora given sequence; so this text may not be able to describe the RX scenarios.

<dorchard> anish, this only doesn't work if there's a non-soap binding..

Bob: anon means "knows what to do"

<anish> dave, or another soap/http binding

Hugo: I do not understand why people care about this so much as it's not clear that any of the option will change anything; let's change find an option that everybody can live with and move on

<anish> dave, or if you use soap 1.1 and smtp or another transport protocol

<dorchard> anish, if somebody else defines soap/http then they would have to do anon..

<anish> right, and they would not be using our soap addressing binding, so any text we put it in there cannot be used by wsrx

<dorchard> jeff, aren't we defining extensible semantics though? That is the semantics are of re-use...

<uyalcina> The URI's semantic is the same=back channel

Jeff: if you use a URI defined in a spec you are confined to its semantics. If anyone wants to use a differnt semantics, define a different URI. Problem if different specs continue to use anaon with different semantics

<anish> can we do a can-live-with poll

<uyalcina> what we are debating is the semantics of the EPRs that use the URI

<pauld> wakes up for what sounds like a versioning and extensibilty discussion

<bob> ?

Bob: can anyone not live with closing with no action?

Tom: I don't want to suggest reuse in the text, becasue if you do you have to put in all sorts of caveats.
... katy's text needs worsmithing.

<uyalcina> +1 To Jonathan

<pauld> anonymous means "do the right thing"

<anish> jonathan, do u think we need to say that or is it enuf for wsrx to say that?

<anish> i.e., with status quo wsrx can do exactly what u are suggesting

<Jonathan> I think we've overconstrained anonymous already.

<Zakim> TonyR, you wanted to point out that jonathan's point is valid, but that's not what the words SAY at the moment

<anish> how?

<anish> we in fact only say right now what it means in replyTo and faultTo

<anish> we don't say anything beyond that

Tony: At this point it does not say "knows what to do"

<dorchard> I assert that the anon is a special value and it means that a user will have to look at context, and the good part of Katy's proposal is to highlight that people need to describe their use..

<Katy> Additional text clarifies what is required by those who want to reuse anonymous - i.e. it must be defined when used outside ws-a context

Anish: we do not say what anon means outside replyTo/FaultTo

Jonathan: we constrain what it means at the SOAP level and the HTTP level

<pauld> Katy's text is simply "caveat emptor" .. I puzzle how to write test cases for it ..

<anish> section 5.1.2 says:

<anish> When "http://www.w3.org/2005/08/addressing/anonymous" is specified for the [reply endpoint] property and the message is the request part of a SOAP request-response MEP [SOAP 1.2 Part 2: Adjuncts], then any response MUST be the response part of the same SOAP request-response MEP [SOAP 1.2 Part 2: Adjuncts].

Bob: Does the spec overly constrain the use of anon?

Tony: heading of 5.1 needs to be changed. Add some text to say that this section defines the use of anon in the ctx of WSA.

Anish: apart from the section heading, text does not constrian you in any way.

Bob: over lunch, small group will work on new text

DH: pending c18 will also affect this text

bob: anish and katy will work on text over lunch, followed by formal vote

LUNCH BREAK

resume 1:15PM

<Katy> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0008.html

Katy: explains the proposal prepared over lunch

<Katy> The precise

<Katy> meaning of this URI ** within the context of Addressing ** is defined by the binding of Addressing to a

<Katy> specific protocol..

<Katy> The precise

<Katy> meaning of this URI ** within the context of Addressing ** is defined by the binding of Addressing to a

<Katy> specific protocol..

Katy: is katy's suggested alternative text to the proposal

<scribe> Scribe: Anish

Bob: how do folks feel about this?

Tony: s/in SOAP Response/for SOAP Response/

Umit: i think the heading is still incorrect
... it is a general stmt
... s/SOAP//

RESOLUTION: resolve issue CR23 with proposal at http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0008.html

no objections

Topic: CR21

Marc explains the issue

jonathan: i feel that we made a bunch of changes in Vancouver and looks like we have issues about it.
... our solution introduced more problems. Revert back to what we had, but open to fixing this however we can

Discussion on what CR17 resolution did

Marc: I would rather just define a default which is not context sensitive

Glen: there are usecases where people can't use this

Umit: in that case the property is no longer optional
... it makes the header optional but not the property optional

glen: u can fix it either way
... if i care about one-way messages only then i don't care about it

<dhull> can everyone still hear on the phone

anish: don't make premature optimizations, no default. if the property is there, it is there. Else it isn't.

glen: instead of saying syntactic default, we can specify in the 'how to sent the reply' section
... why do we need to specify that in the wsdl doc

anish: how important is the default?

glen: it is important as there are cases where the reply can be large % of the message.

umit: in the wsdl doc, we have described using abstract message props
... the reply endpoint should be there. But that does not mean that the header is there.

<marc> http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8#WSDLMEPS

Marc: we can just delete section 5 in wsdl binding

anish: i don't think we should do it

glen: i don't think section 5 should be removed

<dorchard> Glen suggestion: change "in message" to "used by communicating nodes".

<dhull> +1 to "hands off the core"

davidh: what we are trying to say that this is actually used in message exchange

jonathan: i think we can revert CR17 and make the property required

Test status

jonathan/paul: can we do that later but still discuss the issue coming out of the tests?

ProblemHeader (test 1145/1245)

Jonathan explains the issue

Issue explained at: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0000.html

Jonathan: these features were marked at risk
... MS's position is we are not going to implement it, we would like it to be gone. We don't mind having it in, as long as we have 2 implementations

hugo: we did not mark those things at risk
... we put in a note saying that the section may change

paul: from my POV i feel strongly about it. it has minimal with no value but requires lot of testing
... my recollection from Boston was that it was at risk

Hugo: i don't think removing something like that would change the reviewer/implementers experience

jonathan: we are not going to implement it, unless you hold a gun to our head and then we would do something, but not ship

dhull: if this is not useful then i'm not going push on it

jonathan: not a security expert, but i have heard that passing just a Qname is better

dhull: u would send a message and the person receiving the message may not have the context

bob: We have not heard anyone speaking strongly for this
... do we have agreement that we redact the problemheader
... it is the Team's opinion that it would not change the implementation experience

RESOLUTION: redact problemHeader

wsa:UnreachableDestination fault code

Jonathan: not sure how to test it
... no motivation
... i don't want this fault code hold up CR
... this isn't as clear cut as the last one
... we could make it an informative test case rather than optional test case

dhull: feel differently about it
... the idea behind this is to deal with hop-by-hop or gateway situations
... if we want to do a test, we can create an endpoint that always throws a fault

jonathan: we might have to work on it. move it to informative will not help wrt result this week. but could be helpful in the long run

dhull: don't want to derail this. if we want to do it now or later that is fine
... the fact that no one has implemented doens
... n't tell us much
... would like to keep it, will help with test cases

dhull: we should be able to make the box turn green

bob: if status-quo means we need to have 4 imples then it is a problem

jonathan: this is a more advanced feature and we can agrue that we don't need this now

paul: i look at this fault and think it is not interoperable
... no benefit of this

katy: agree with paul

dhull: this is not an advanced feature it is a simple feature

tony: davidh your position would be more defensible if you had an impl

jonathan: two different perspective, say it is more adv. feature

bob: what do we have to do here to move on?

davidIh: there is no must here

bob: does the resolution mean just removing the testcase

hugo: we have an agreement that if we can't test it we'll remove it

jonathan: we can say that we failed to get implementations of this particular error condition
... advanced impl. can use this
... we can't have every class of implementations

bob: could be useful for say 'tcp/ip'
... nothing to do with addressing

dhull: in the gateway case not necessarily a transport failure
... jabber case is another one
... not going to lie on the road

jeff: the reason to set a criteria before you are under pressure is to create one that is reasonable
... hard to believe justification given now
... don't believe any arguements about things happening in the future
... this is supposed to be widely implemented spec and easy
... we should stick with it and carry on with the program

hugo: but nobody is using it

jonathan: what are you suggesting?

jeff: don't move on till we have an implementation

hugo: i don't understand that -- we have 3 (or 5) impl. and no one is using it

jeff: either yank it out or implement it

jonathan: i've a positioin that is compatible with that

paul: test cases haven't been written

dhull: lets be consistent

<uyalcina> It appears that there are no test cases for section 6.4.1

dhull: i don't want to cherry-pick

paul: we have a number of testcases bound to contributions from MS/IBM/myself/Hugo/Philippe -- we don't give good coverage to this area (faulting)
... it could be one fault or multiple fault
... don't know the reasons for test cases for a few faults and not all
... each fault code implies a processing model
... each of these has a high cost
... my company position to yank it out

dhull: in that case we have to yank out other things too
... are there test cases for actionnotsupported and endpointunavailable

<pauld> http://www.w3.org/2002/ws/addr/testsuite/testcases/

dhull: how do u know that the implementation is behaving properly

daveo: is it a question of creating testcases or impl. just don't support it
... lets have the WG members write tests

<pauld> http://www.w3.org/2002/ws/addr/testsuite/features/

daveo: standardized fault is important

<BREAK>

<scribe> Scribe: anish

bob: we are trying to figure out appropriate way to move forward on the fault codes
... one suggestion is to take all of non-tested/unimplemented faultcodes and to remove them from the normative spec and put it in a non-normative note
... all of the faults in section 6 that are not tested

dhull: actually all the optional faults (with no MUST)

umit: why not create a non-normative fault codes

jeff: need faultcodes for interop
... helps to have std codes

dhull: that is the idea
... but nothing normative

paul: i favor note, non-normative appendix has a cost
... wrt errata
... expectation is that it will grow
... these are soap fault that are useful

tom: non-Required faults are still normative for the clients

<uyalcina> I do not prefer a note, one spec is enough for implementors as a reference. All of our implementors are confused how many specifications docs are out there, what their status is, etc.

jeff: i don't understand the packaging argument

paul: i can pick up the ws-addr spec with 2 pages as opposed to 6 pages

jeff: there should be normative in the sense that they are defined by the rec

paul: endpointnotavailable can be catch for a lot of things

jeff: is helpful so that one can have a switch

<uyalcina> we seem to be mixing the concept of whether we can test the error generating conditions and whether the codes may be useful for users.

paul: want more of vendor specific codes
... if the semantics can be nailed down -- which is a lot of work

jeff: u don't have to test them

bob: if the spec were to include the other non-must faults, those may be impossible/hard to test

jeff: we could write a test for that

bob: we might

dhull: fault is not the feature

hugo: we are talking about section 5 and it is useless, times time, helps interop etc
... put them on the whiteboard and find out which are releated to MUST, whether there is a test, implemented etc

umit: where are we going with the classification?
... i'm worried that eliminating subcodes. Would like to compare their use how XML schema codes were useful with XML Schema implementations schema. Would like to keep most of the codes

jonathan: one of the difficulties with testing is that it is hard to create bad messages

paul: not people writing test cases

<dhull> section 6 says "[Details] The detail elements, use of the specified detail elements is REQUIRED. If absent, no detail elements are defined for the fault.", but I don't think any of the faults really gives any REQUIRED detail elements. They either say nothing or say MAY.

paul: my understanding was that implementations don't implement features in time, they are gone

<uyalcina> Lets be fair here. WSDL binding just went to LC and some of the fault codes were added recently after Japan at Vancouver.

Hugo's table:

Problem hdr - Must:N Test:Y Impl:N

Problem Hdr QN - Must:N Test:Y Impl:Y

Problem IRI - Must:N Test:Y Impl:N

Problem Action - Must:N Test:N Impl:N

Retry After - Must:N Test:N Impl:N

Invalid Addr Hdr - Must:Y Test:Y Impl:Y

Inv Addr - Must:Y Test:N Impl:N

Inv EPR - Must:Y Test:N Impl:

Inv. Cardinality - Must:Y Test:Y Impl:Y

Miss Addr in EPR - Must:Y Test:N Impl:

Dup MID - Must:N Test:N Impl:

Action Mismatch - Must:Y Test:N Impl:

Only Anon - Must:Y Test:N Impl:

Only Non-Anon - Must:Y Test:N Impl:

Message Adr Hdr Req - Must:Y Test:Y Impl:N

Dest. Unreachable - Must:N Test:N Impl:N

Action Not Supported - Must:N Test:N Impl:N

Endpoint Unavailable - Must:N Test:N Impl:N

bob: we do not specify behavior

hugo: my proposal is to keep the ones with 'Must' and they seem to be implemented and figure out what to do with the rest

katy: we should be able to look and them and remove if not needed

umit: i pushed 2 error codes cause they are related to WSDL

<dorchard> agenda question, what else is after the test cases?

jonathan: if we can have a written proposal that can be reviewed by our engineers that would be good
... and look at it tomorrow

<uyalcina> those two error codes came in late in Vancouver, they are relevant for the WSDL binding.

<pauld> I do not believe we have two implementations who have implemented each of these faults in the same way

<pauld> WSDL Binding can develop its own faults

<Zakim> dhull, you wanted to reconsider whether a standard spelling with no standard semantics is helpful or harmful

daveh: the reason for have the last three fault codes in hugo's table was to not to have a must around it, but having the spelling available for interop
... we could just pull the 3 out

bob: proposal --
... Define normatively two faults that MUST be implemented
... 1)Invalid Adr Header; subfaults move to note
... 2) message Adr Hdr req
... 3) move all other non-MUST fualts to a note
... 0) drop Dest unreachable, Action not supported and Endpoint unavailble faults

<dorchard> For the record, I'll be in and out tomorrow AM then absent in the PM for other WG/TAG meetings..

dhull: 0 is separate decision

bob: any opposition

none

RESOLUTION: accepted (0) in bob's proposal (subsequently nullified the following day)

jeff: don't agree that it should be in the note

umit: what if there are in a non-normative appendix

jeff: i want to be able to be count on these codes as a client

katy: David Illsley thinks that we can remove more codes

bob: there are a lot of flavor of Invalid Addr Hdr

jeff: normativeness means we reserve this slot in the NS

hugo: we have done the generic category of Invalid Addr Hdr
... don't find the necessity to test the details

bob: we have tested at least one detail

paul: unhappy camper
... i went with the consensus in Boston with the assumption that based on implementors experience we'll rip it out if needed
... would like to express my objection and get it on record
... i would like to remove all rows that are optional
... it is half-baked, we slapped it in there
... it should not be in there

jeff: in corba there were predefined codes which were hints to users

paul: this will come back an bite us

umit: we have two fault codes related to WSDL. WSDL isn't even in CR

paul: i feel strongly about remove these codes, but i'm willing to move on cause we need to get done
... error codes need to be machine processable

jeff: other reasons to have error codes too

dhull: intellence systems can go thru logs and do interesting things. So this is helpful
... i do agree that our processing model is weak (wrt codes)

katy: in response to Paul, agree with what he is saying, but we are down to only two faults
... we got these subcodes/details, they will just fall out depending on what we decide
... we have 6.4.1.1 - 6.4.1.8 subcodes instead of throwing them into a note we should step thru them and see if they are needed
... why not move the anon/non-anon faults to wsdl

umit: we tell people when they are required but they are valid independent of that

katy: problem action is not a fault, it is a detail

bob: ah, it is part of invalid header hdr

Bob's new proposal:

1) invalid Adr header; tested one detial, leave the rest of the details (internal rationalization)

2) message Adr Hdr req kept

3) move all other non-MUST faults to a note

dhull: i don't want to revisit closed issues

Bob's new new proposal:

1) invalid Adr header; tested one detail, leave the rest of the details (internal rationalization, induction proof)

2) message Adr Hdr req kept

bob: we will close this tomorrow morning
... immediatly after which we will continue with the test report

jonathan: our report is looking better, but will be better to have more vendors online

bob: we also have to discuss wsa:From and source endpoint which have been
... identified as "at risk" features

WS-Addressing WG Face to Face meeting
2 Mar 2006

Attendees

Contents

proposed issue 1

proposed issue 2

One paragraph out-optional-in note

Topic: CR23

Topic: CR21

Test status

ProblemHeader (test 1145/1245)

wsa:UnreachableDestination fault code

Summary of Action Items

WS-Addressing WG Face to Face meeting 2 Mar 2006

Attendees

Contents

proposed issue 1

proposed issue 2

One paragraph out-optional-in note

Topic: CR23

Topic: CR21

Test status

ProblemHeader (test 1145/1245)

wsa:UnreachableDestination fault code

Summary of Action Items

WS-Addressing WG Face to Face meeting
2 Mar 2006