See also: IRC log
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
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?
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> *This action SHOULD NOT be used as an action value in messages other
<bob> than those carrying WS-Addressing faults.*
<bob> SOAP modules, extensions and applications SHOULD define custom [action] values for
<bob> faults they describe but MAY designate use of the following [action]
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
as above, accepted without objection
<bob> The above [action] value SHOULD be used for SOAP defined faults
<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> 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> Original thread that sparked this follows...
<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> 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".
<dorchard> As such, any content in the response body, including a SOAP body, MAY or MAY not be an expected SOAP response.
<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 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..."
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> Bob- talk to hugo about how to publish
resuming meeting again
<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
... 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: 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> 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
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
... it is a general stmt
RESOLUTION: resolve issue CR23 with proposal at http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0008.html
Marc explains the issue
jonathan: i feel that we made a
bunch of changes in Vancouver and looks like we have issues
... 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
... 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'
... 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: 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
More discussion on various solution
katy: my concern is that if we
undo cr17, we have to make sure that it all works
... can we fix it syntactically in the wsdl spec
... under the MEPs, it says "this section describes whether properties are required or optional"
<dhull> s/Mandatory/Required by MEP/?
katy: we can change it to : this
section says which core MAPs are rquried by MEPs of WSDL
... and the top of the table change mandatory to requried
dhull: i don't think change from
mandatory to required does anything. we need to say that the
requireness is for the MEP
... the important part is "for MEP"
umit: how does it solve the
... the MAP reply-to will always have a value
Marc: u are mixing the abstract
and serialized one
... if u come up with another way to serialize this then it won't fly
Glen: agree with katy's
... we say there is no syntactic defaults
... from the MEP there may be defaults
Marc: i want to write a lib which
can query soap message and get the abstract properties
... if i have to default based on the context, i don't like it
umit: we can't put any case (where it has to fault if a value is not present) in our test case
glen: that is a different issue
marc: in this case, for our mapping, there will always be a value for [reply to]
umit: without all the context you can never figure this out
marc: we can add another note to
make this clear
... proposal -- core section 3.4 note that for the serialization [fault to] and [reply to] is always present
Tony: rather than saying that the
processor will never fault, I would say that the MAP would
never be empty
... instead of talking about the behavior of the processor we should talk about the properties
<TonyR> Current text of the contentious note is: When using the XML Infoset representation, in the absence of a wsa:ReplyTo element the value of the [reply endpoint] message addressing property defaults to an EPR with an [address] property of "http://www.w3.org/2005/08/addressing/anonymous" - see section 3.2 XML Infoset Representation of Message Addressing Properties
Marc: proposal -- reopen CR17, close with clarification to the existing note and revert decision on CR17
Umit: i prefer saying explicitly that we allow other serializations
bob: we have marc's proposal and
see if we can converge
... is this the approach to take to resolve this?
... can we leave the wordsmithing to the editors?
Umit: I'll work with marc on this
Tony's proposed text: The [reply endpoint] messaging property is defaulted to "ANONYMOUS" by the current serialisation, so this MAP will not be empty.
RESOLUTION: cr21 Revert cr17, new text proposed by Tony and close issue CR21 with reversal of cr17
umit: there will be clarification of the note
<scribe> ACTION: umit/tony/marc to figure out the wordsmithing for clarification to the note (CR17/CR21) [recorded in http://www.w3.org/2006/03/02-ws-addr-minutes.html#action01]
jonathan/paul: can we do that later but still discuss the issue coming out of the tests?
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
... 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
Jonathan: not sure how to test
... 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
... 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
<more discussion on various fault codes and what they mean>
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
... advanced impl. can use this
... we can't have every class of implementations
bob: could be useful for say
... 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
... 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
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
daveo: standardized fault is important
<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
... 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
... 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
... 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
... 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
<hugo draws a chart with various faultcodes and associated attributes: Must, Test and Implemented>
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.
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
... 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
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
... error codes need to be machine processable
jeff: other reasons to have error codes too
<discussion on error codes>
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
... we got these subcodes/details, they will just fall out depending on what we decide
... we have 188.8.131.52 - 184.108.40.206 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
... 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
<Recessed for the day >