IRC log of ws-addr on 2006-03-02

Timestamps are in UTC.

07:54:01 [RRSAgent]
RRSAgent has joined #ws-addr
07:54:01 [RRSAgent]
logging to
07:54:15 [TonyR]
zakim, this is ws-address
07:54:15 [Zakim]
sorry, TonyR, I do not see a conference named 'ws-address' in progress or scheduled at this time
07:54:21 [TonyR]
zakim, list conf
07:54:21 [Zakim]
I don't understand 'list conf', TonyR
07:54:29 [TonyR]
zakim, list conferences
07:54:29 [Zakim]
I see no active conferences
07:54:31 [Zakim]
scheduled at this time are WAI_PFWG(F2F-TP)2:30AM, WS_AddrWG(TP)3:00AM, XML_XMLCore(TP)3:00AM
07:54:47 [TonyR]
zakim, this is ws_addrwg
07:54:47 [Zakim]
TonyR, I see WS_AddrWG(TP)3:00AM in the schedule but not yet started. Perhaps you mean "this will be ws_addrwg".
07:54:48 [bob]
zakim, this will be ws_addrwg
07:54:49 [Zakim]
ok, bob; I see WS_AddrWG(TP)3:00AM scheduled to start in 6 minutes
07:55:53 [bob]
Meeting: WS-Addressing WG Face to Face meeting
07:56:31 [bob]
Chair: Bob Freund
07:59:49 [Zakim]
WS_AddrWG(TP)3:00AM has now started
07:59:56 [Zakim]
08:04:02 [hugo]
hugo has joined #ws-addr
08:04:29 [hugo]
Zakim, call IlesB
08:04:29 [Zakim]
I am sorry, hugo; I do not know a number for IlesB
08:06:07 [Nilo]
Nilo has joined #ws-addr
08:07:10 [hugo]
Zakim, call TP_Iles_B
08:07:10 [Zakim]
ok, hugo; the call is being made
08:07:12 [Zakim]
08:07:41 [bob]
who is on the phone?
08:07:49 [GlenD]
GlenD has joined #ws-addr
08:08:56 [Nilo]
08:10:03 [Katy]
Katy has joined #ws-addr
08:10:13 [dhull]
dhull has joined #ws-addr
08:10:50 [TonyR]
zakim, who is on the phone?
08:10:50 [Zakim]
On the phone I see ??P0, TP_Iles_B
08:11:23 [TonyR]
zakim, ??p0 is MarkLittle
08:11:23 [Zakim]
+MarkLittle; got it
08:12:41 [uyalcina]
uyalcina has joined #ws-addr
08:13:12 [Jonathan]
08:13:31 [Nilo]
agenda approved, with test status update included
08:14:35 [Nilo]
Feb 20 minutes approval postponed to tomorrow
08:16:17 [Zakim]
08:16:46 [Nilo]
test results from Jonathan: 5 implementations tested, results shown, basically a sea of green
08:17:42 [Nilo]
a few optional features have no implementations; so they are at risk
08:19:45 [TonyR]
zakim, who is on the phone?
08:19:45 [Zakim]
On the phone I see MarkLittle, TP_Iles_B, ??P1
08:20:53 [Nilo]
Bob would like to get PR text completed today and wants everyoe to work towards that
08:21:21 [jeffm]
jeffm has joined #ws-addr
08:22:24 [Nilo]
AI review - all AIs completed
08:23:09 [yinleng]
yinleng has joined #ws-addr
08:23:40 [Nilo]
Umit concerned about lack of WSDL implementations affecting the WSDL binding
08:24:54 [Nilo]
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
08:25:20 [Zakim]
08:25:22 [TRutt]
TRutt has joined #ws-addr
08:25:54 [Zakim]
08:26:07 [Nilo]
Topic: proposed issue 1
08:26:12 [yinleng]
zakim, ??P1 is me
08:26:12 [Zakim]
+yinleng; got it
08:26:14 [hugo]
08:28:17 [anish]
anish has joined #ws-addr
08:28:24 [Nilo]
DH thinks this is a potentially editorial change and can be done after we have agreed to the other changes to this text
08:29:04 [Nilo]
Umit: how is SOAP1.1 text affected
08:29:45 [Jonathan]
08:30:06 [Nilo]
Topic: proposed issue 2 (see link above)
08:31:06 [Allen]
Allen has joined #ws-addr
08:34:02 [Nilo]
jonathan: two action values - one for addressing-specific faults, another for application-level ones
08:34:54 [Nilo]
Hugo: concern with the term "generic SOAP faults"
08:34:55 [dorchard]
dorchard has joined #ws-addr
08:35:40 [Nilo]
general consensus re the action value for the addressing-specific faults
08:36:49 [Nilo]
with one addition: add a reference to the section on the Faults section
08:37:25 [bob]
The [action] property below designates WS-Addressing fault messages:
08:37:25 [bob]
08:37:25 [bob]
08:37:25 [bob]
08:37:25 [bob]
*This action SHOULD NOT be used as an action value in messages other
08:37:26 [bob]
than those carrying WS-Addressing faults.*
08:37:28 [bob]
08:37:28 [Nilo]
section 6.4
08:37:30 [bob]
SOAP modules and extensions SHOULD define custom [action] values for
08:37:32 [bob]
08:37:34 [bob]
faults they describe but MAY designate use of the following [action]
08:37:36 [bob]
08:37:38 [bob]
08:38:35 [FabGandon]
FabGandon has joined #ws-addr
08:38:43 [Nilo]
Katy: change "generic faults" to "such as..."
08:38:45 [marc]
marc has joined #ws-addr
08:39:18 [Nilo]
DaveO: call them "SOAP defined faults" instead of "generic SOAP faults"
08:39:31 [dorchard]
SOAP defined SOAP faults
08:40:11 [bob]
The above [action] value SHOULD be used for SOAP defined faults
08:40:11 [bob]
08:40:11 [bob]
version mismatch, must understand, and data encoding unknown. *This
08:40:11 [bob]
action SHOULD NOT be used as an action value in messages other than
08:40:11 [bob]
those carrying SOAP defined faults or those of SOAP modules and
08:40:12 [bob]
08:40:14 [bob]
08:40:16 [bob]
I use SHOULD because this is a hard thing to test, seems like the
08:40:18 [bob]
appropriate level of guidance, and doesn't force a breaking change in
08:40:20 [bob]
implementations at this point.
08:40:22 [bob]
08:40:24 [bob]
Original thread that sparked this follows...
08:41:45 [bob]
The above [action] value SHOULD be used for SOAP defined SOAP faults
08:41:45 [bob]
08:41:45 [bob]
version mismatch, must understand, and data encoding unknown. *This
08:41:45 [bob]
action SHOULD NOT be used as an action value in messages other than
08:41:45 [bob]
those carrying SOAP defined SOAP faults or those of SOAP modules and
08:41:46 [bob]
08:41:48 [bob]
08:41:50 [bob]
I use SHOULD because this is a hard thing to test, seems like the
08:41:52 [bob]
appropriate level of guidance, and doesn't force a breaking change in
08:41:54 [bob]
implementations at this point.
08:41:56 [bob]
08:41:58 [bob]
Original thread that sparked this follows...
08:42:29 [chad]
chad has joined #ws-addr
08:43:57 [Nilo]
Marc: seems a bit contradictory
08:44:45 [Nilo]
Glen: may want to have infrastructure choose the appropriate action value
08:46:27 [Nilo]
consenusus building around closing the second part with no action
08:46:54 [Nilo]
Umit: what's the reason for the second part
08:47:28 [Nilo]
Jonathan: it would be nice to know if it was ageneric SOAP fault as opposed to a app level fault.
08:47:43 [Nilo]
Glen: it almost seems like over-riding SOAP fault codes
08:49:28 [Nilo]
Anish: still need to change the para between the two action value.
08:49:53 [anish]
s/SOAP modules and extensions/SOAP modules, extensions and applications/
08:50:06 [anish]
in section 6
08:51:33 [Nilo]
This is marked as CR24
08:51:47 [Nilo]
Resolved CR24
08:51:51 [Nilo]
as above
08:53:12 [Nilo]
Topic: One paragraph out-optional-in note
08:54:14 [bob]
The above [action] value SHOULD be used for SOAP defined faults
08:54:14 [bob]
08:54:14 [bob]
version mismatch, must understand, and data encoding unknown. *This
08:54:14 [bob]
action SHOULD NOT be used as an action value in messages other than
08:54:14 [bob]
those carrying SOAP defined faults or those of SOAP modules and
08:54:15 [bob]
08:54:17 [bob]
08:54:19 [bob]
I use SHOULD because this is a hard thing to test, seems like the
08:54:21 [bob]
appropriate level of guidance, and doesn't force a breaking change in
08:54:23 [bob]
implementations at this point.
08:54:25 [bob]
08:54:27 [bob]
Original thread that sparked this follows...
08:54:39 [bob]
08:57:00 [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
08:58:13 [bob]
This SOAP 1.1 request optional response HTTP binding, in conjunction
08:58:13 [bob]
with the SOAP 1.1 binding, can be used for sending request messages with
08:58:13 [bob]
an optional SOAP response. This binding augments the SOAP 1.1 binding
08:58:13 [bob]
by allowing that the HTTP [RFC 2616] response MAY have a 202 status code
08:58:13 [bob]
and the response body MAY be empty. Note that the HTTP [RFC 2616]
08:58:14 [bob]
specification states "the 202 response is intentionally non-committal".
08:58:16 [bob]
As such, any content in the response body, including a SOAP body, MAY or
08:58:18 [bob]
MAY not be an expected SOAP response.
08:58:57 [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".
08:59:08 [dorchard]
As such, any content in the response body, including a SOAP body, MAY or MAY not be an expected SOAP response.
08:59:46 [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
09:00:16 [pauld]
pauld has joined #ws-addr
09:00:59 [pauld]
chad, you don't understand, much :-(
09:01:43 [Nilo]
Umit: can the last sentnce be reworded?
09:04:20 [Nilo]
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
09:04:54 [Nilo]
Bob: we need new text starting from "As such..."
09:05:02 [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:
09:05:49 [Nilo]
Anish: propose striking snetnce starting "As such..."
09:06:55 [Nilo]
09:07:21 [Nilo]
09:07:30 [Nilo]
how does this affect the test suite
09:07:57 [Nilo]
Glen: the 202 is used in the test suite
09:08:35 [dorchard]
Another slight wording mod of the last 2 sentence..
09:08:36 [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.
09:10:24 [Nilo]
Text above agreed
09:10:34 [Nilo]
Issue resolved, and we will publish as a NOTE
09:11:04 [Nilo]
Break until 10:45
09:16:08 [Zakim]
09:35:53 [Katy]
Katy has joined #ws-addr
09:40:27 [Katy]
Katy has joined #ws-addr
09:40:34 [Zakim]
09:41:33 [TRutt]
TRutt has left #ws-addr
09:45:01 [bob]
above resolution is to clean up and publish the note:
09:45:06 [bob]
09:45:22 [bob]
Bob- talk to hugo about how to publish
09:46:09 [Nilo]
resuming meeting again
09:46:23 [Nilo]
topic: CR23
09:47:17 [bob]
09:47:43 [anish]
alternate proposal:
09:47:51 [TRutt]
TRutt has joined #ws-addr
09:48:33 [marc]
marc has joined #ws-addr
09:50:56 [anish]
09:51:51 [bob]
ack ani
09:53:15 [uyalcina]
09:53:47 [GlenD]
09:53:55 [Katy]
09:54:09 [Nilo]
Anish: has an alternative proposal and suggests that this isuue be closed with no action
09:54:10 [bob]
ack um
09:54:40 [bob]
ack u
09:54:46 [Nilo]
umit: it is WS_RX's choice to use our anon URI or mint their own
09:54:57 [anish]
09:55:02 [Jonathan]
09:55:07 [bob]
ack gl
09:55:12 [Nilo]
Glen: agrees with Anish
09:56:00 [bob]
ack k
09:56:00 [Nilo]
Glen: we don't need to encourage WS-RX to use this URI in ways that may not be these semantics
09:56:59 [Nilo]
Katy: the semantics is that it depends on the underlying SOAP transport binding
09:57:21 [dhull]
09:57:28 [TRutt]
09:58:05 [bob]
ack an
09:58:22 [GlenD]
q+ to indicate that using a different URI is more comprehensible than looking up a namespace for an EPR header such as <wsrx:AcksTo>
09:58:31 [Nilo]
Katy: It allows RX to go either way - use this URI as we define it or define their own URI for acksTo
09:59:07 [uyalcina]
I am very comfortable in reverting a request that came from RX and forcing a particular decision on them,
09:59:18 [uyalcina]
we should give them the choice
09:59:24 [dorchard]
09:59:27 [bob]
ack jon
09:59:29 [uyalcina]
09:59:30 [Nilo]
Anish: not comfortable with making its meaning context sensitive
10:00:17 [Nilo]
Jonathan: there is value in making this URI mean that it depends on the infrastructure
10:01:07 [bob]
ack dh
10:01:21 [Nilo]
Jonathan: in short, agreeing with Katy
10:02:01 [anish]
10:02:08 [bob]
ack tr
10:02:19 [Nilo]
DH: if you are using anon, you need to understand the context it is to be used
10:02:53 [uyalcina]
10:03:09 [bob]
ack gl
10:03:09 [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>
10:03:28 [Katy]
10:03:33 [TonyR]
q+ addressing RX minting their own URI
10:03:35 [Nilo]
Tom: could go either way, but does not see why a spec can't define its own EPR's semantics
10:03:45 [TonyR]
q+ to addressing RX minting their own URI
10:04:12 [bob]
10:04:53 [Nilo]
Glen: in summary would prefer WS-RX to mint its own URI
10:04:56 [bob]
ack dor
10:07:06 [Nilo]
DOR provides an analogy to java abstract vs concrete classes
10:07:23 [bob]
ack ani
10:08:48 [Jonathan]
10:09:06 [dhull]
q+ to point out that RX is not the only potential reuser of anon
10:09:34 [hugo]
10:09:42 [bob]
ack uy
10:09:50 [Nilo]
anish: we don't disallow use of anon in any other context. we simply define its use for reply/failtTo
10:10:27 [GlenD]
Tom just made an interesting point - when you see a URI, you tend to want to deference it to see what it means...
10:10:39 [Nilo]
umit: there is an abstract/concrete analogy. abstract is "any back channel" while concrete is specific back channels in specifc contexts
10:10:56 [GlenD]
If it's RX's "sequenceBackchannel" URI, that's clearer than "W3C's no-real-meaning-anonymous URI"
10:11:00 [dorchard]
dorchard has joined #ws-addr
10:11:03 [dorchard]
10:11:10 [bob]
ack ka
10:11:10 [pauld]
10:12:25 [Jonathan]
10:12:27 [Nilo]
anish: the current text encourages you to use this URI in a different context
10:12:36 [bob]
ack tony
10:12:36 [Zakim]
TonyR, you wanted to addressing RX minting their own URI
10:12:53 [Nilo]
Tony: RX should define their own URI because it has a different meaning
10:12:58 [pauld]
10:13:00 [uyalcina]
uyalcina has joined #ws-addr
10:13:33 [Jonathan]
q+ Jonathan
10:13:42 [TRutt]
10:13:45 [bob]
ack dhu
10:13:45 [Zakim]
dhull, you wanted to point out that RX is not the only potential reuser of anon
10:13:58 [uyalcina]
Please folks, WS-RX ASKED us to loosen up the definition of the URI for them.
10:14:03 [uyalcina]
This is why we are discussing this
10:14:25 [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
10:15:29 [uyalcina]
+1 to DH.
10:15:29 [bob]
ack hu
10:15:32 [Nilo]
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
10:16:31 [bob]
ack dor
10:16:31 [Zakim]
dorchard, you wanted to follow my nose on <wsrx:acksTo>wsa:anon</wsrx:acksTo> vs <wsrx:acksTo>wsrx:anon</wsrx:acksTo>
10:16:33 [GlenD]
q+ to call the question (let's vote!)
10:16:33 [Nilo]
Hugo: support Anish's proposal
10:17:59 [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.
10:18:37 [Nilo]
DO: in either case, the RX spec implementers will have to look at their spec to see how the anon value is used
10:19:31 [anish]
10:19:48 [bob]
ack jon
10:21:26 [Nilo]
Jonathan: wants to allow anon to be used with AcksTo as used today
10:21:40 [dhull]
10:21:45 [dhull]
10:21:56 [bob]
ack tr
10:22:13 [dhull]
10:23:15 [dorchard]
q+ to ask is the core of Katy's proposal to call out the context dependent.
10:23:15 [bob]
ack glen
10:23:16 [Zakim]
GlenD, you wanted to call the question (let's vote!)
10:23:22 [Nilo]
Tom: happier with Anish's proposal, but could edit Katy's proposal to meet concerns
10:23:53 [dhull]
10:24:25 [dorchard]
Is it almost the straw poll of "do you want anon re-used or not"?
10:25:08 [dhull]
10:25:13 [anish]
10:25:14 [dhull]
10:25:18 [Nilo]
Glen: want to get a sense of the group
10:25:50 [Nilo]
Katy: RX implementations are using the anon URI
10:26:08 [Nilo]
Marc/Anish: they are not using this CR anon URI
10:26:14 [bob]
ack ani
10:26:28 [pauld]
has no sympathy for WS-RX, they're referencing a moving target
10:26:30 [Nilo]
Anish: RX uses the old anon URI
10:27:27 [Nilo]
Umit: the semantics of the old anon URI was "any back channel" which is what Katy's proposal is trying to capture
10:27:31 [GlenD]
Umit - it doesn't matter that it's the SAME anonymous URI as addressing uses, though, does it?
10:27:42 [GlenD]
If they need to change anyway, is it that big a deal?
10:27:49 [uyalcina]
it does matter RX.
10:27:54 [uyalcina]
They asked us to define it for them
10:28:05 [uyalcina]
s/matter/matter to/
10:28:13 [pauld]
what implementations are using our freshly minted URI?!
10:28:13 [GlenD]
I'm asking Umit the architect/developer, not Umit the politician. :)
10:28:28 [uyalcina]
i was the one who raised CR4 on behalf of WS-RX
10:29:15 [Nilo]
poll to adopt katy's proposal
10:31:25 [Nilo]
straw poll: for 6 against 7
10:32:42 [bob]
10:32:42 [GlenD]
it was 6 to 8, actually
10:33:06 [GlenD]
10:33:11 [bob]
ack do
10:33:11 [Zakim]
dorchard, you wanted to ask is the core of Katy's proposal to call out the context dependent.
10:33:40 [dhull]
10:34:01 [Katy]
10:34:03 [Nilo]
Tom: the input WS-RX did not use "anon"
10:34:48 [Nilo]
Bob: can we live with no action?
10:35:09 [dorchard]
And, can we live with Katy's proposals?
10:35:13 [Nilo]
Umit: I was given the AI by WS-RX TC to define the use of "anaon"
10:35:22 [Nilo]
10:35:25 [dhull]
10:35:45 [dorchard]
q+ to ask more people
10:36:52 [Nilo]
BoB: I take charge of this AI and response to WS-RX
10:38:03 [Nilo]
Bob: What needs to change in the proposal to make it acceptable?
10:38:19 [anish]
10:38:59 [hugo]
10:39:04 [jeffm]
10:39:09 [Nilo]
DO: I thought we voted for the intent, not the exact text
10:39:34 [TRutt]
10:39:44 [bob]
ack gl
10:40:19 [Katy]
10:41:54 [Jonathan]
10:42:05 [bob]
ack dh
10:42:17 [Nilo]
Glen: Minting URIs is easy and there does not seem to be a benefit to use the same URI with different meaning
10:43:15 [Nilo]
DH: WS-RX found the "back channel"semantics of anon to be useful to reuse
10:45:07 [bob]
ack do
10:45:07 [Zakim]
dorchard, you wanted to ask more people
10:46:43 [Katy]
10:47:52 [Nilo]
Vikas: For a non synchronous transport, you do not want somebody to specify what the back channel is
10:48:01 [bob]
ack ani
10:49:58 [Nilo]
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.
10:50:58 [dorchard]
anish, this only doesn't work if there's a non-soap binding..
10:51:04 [bob]
ack hu
10:51:04 [Nilo]
Bob: anon means "knows what to do"
10:51:18 [anish]
dave, or another soap/http binding
10:51:40 [bob]
ack jeff
10:51:44 [Nilo]
Hugo: does not understand what this text will do
10:51:48 [anish]
dave, or if you use soap 1.1 and smtp or another transport protocol
10:52:15 [dorchard]
anish, if somebody else defines soap/http then they would have to do anon..
10:52:50 [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
10:52:54 [dorchard]
jeff, aren't we defining extensible semantics though? That is the semantics are of re-use...
10:53:02 [uyalcina]
The URI's semantic is the same=back channel
10:53:15 [Nilo]
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
10:53:21 [anish]
can we do a can-live-with poll
10:53:28 [uyalcina]
what we are debating is the semantics of the EPRs that use the URI
10:53:49 [pauld]
wakes up for what sounds like a versioning and extensibilty discussion
10:53:54 [hugo]
s/does not understand what this text will do/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/
10:54:34 [bob]
10:54:36 [bob]
10:54:37 [anish]
10:55:52 [Nilo]
Bob: can anyone not live with closing with no action?
10:56:45 [bob]
10:56:48 [Nilo]
Tom: I don't want to suggest reuse in the text, becasue if you do you have to put in all sorts of caveats.
10:56:51 [bob]
ack tr
10:57:01 [Nilo]
Tom: katy's text needs worsmithing.
10:57:10 [bob]
ack jon
10:57:55 [uyalcina]
+1 To Jonathan
10:58:00 [pauld]
anonymous means "do the right thing"
10:58:11 [bob]
ack ka
10:58:16 [anish]
jonathan, do u think we need to say that or is it enuf for wsrx to say that?
10:58:22 [TonyR]
q+ to point out that jonathan's point is valid, but that's not what the words SAY at the moment
10:58:38 [anish]
i.e., with status quo we wsrx can do exactly what u are suggesting
10:59:00 [anish]
10:59:15 [Jonathan]
I think we've overconstrained anonymous already.
10:59:20 [bob]
ack tony
10:59:20 [Zakim]
TonyR, you wanted to point out that jonathan's point is valid, but that's not what the words SAY at the moment
10:59:21 [anish]
10:59:37 [anish]
we in fact only say right now what it means in replyTo and faultTo
10:59:46 [anish]
we don't say anything beyond that
11:00:06 [Nilo]
Tony: At this point it does not say "knows what to do"
11:00:10 [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..
11:01:15 [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
11:01:24 [bob]
11:01:56 [Nilo]
Anish: we do not say what anon means outside replyTo/FaultTo
11:02:30 [Nilo]
Jonathan: we constriant what it means at the SOAP level and the HTTP level
11:02:48 [Nilo]
11:03:15 [pauld]
Katy's text is simply "caveat emptor" .. I puzzle how to write test cases for it ..
11:03:16 [hugo]
Zakim, who's on the phone?
11:03:17 [Zakim]
On the phone I see TP_Iles_B
11:03:28 [hugo]
Zakim, drop TP_Iles_B
11:03:28 [Zakim]
TP_Iles_B is being disconnected
11:03:29 [Zakim]
WS_AddrWG(TP)3:00AM has ended
11:03:30 [Zakim]
Attendees were TP_Iles_B, MarkLittle, yinleng
11:05:00 [anish]
section 5.1.2 says:
11:05:02 [anish]
When "" 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].
11:05:42 [Nilo]
Bob: Does the spec overly constrain the use of anon?
11:06:43 [bob]
11:06:47 [dorchard]
11:06:57 [Nilo]
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.
11:07:01 [dhull]
11:07:07 [dhull]
11:07:17 [dhull]
q+ to point out that CR18 resolution gets us almost there
11:07:23 [Nilo]
Anish: apart from the section heading, text does not constrian you in any way.
11:08:56 [Nilo]
Bob: over lunch, small group will work on new text
11:10:47 [Nilo]
DH: pending c18 will also affect this text
11:11:14 [Nilo]
bob: anish and katy will work on text over lunch, followed by formal vote
11:11:25 [Nilo]
11:11:32 [Nilo]
resume 1:15PM
12:16:15 [TonyR]
TonyR has joined #ws-addr
12:18:27 [Katy]
Katy has joined #ws-addr
12:21:34 [Katy]
12:30:36 [bob]
Scribe: Bob
12:31:47 [bob]
Katy: explains the proposal prepared over lunch
12:34:30 [Katy]
The precise
12:34:30 [Katy]
meaning of this URI ** within the context of Addressing ** is defined by the binding of Addressing to a
12:34:30 [Katy]
specific protocol..
12:34:43 [marc]
marc has joined #ws-addr
12:34:54 [Katy]
The precise
12:34:54 [Katy]
meaning of this URI ** within the context of Addressing ** is defined by the binding of Addressing to a
12:34:54 [Katy]
specific protocol..
12:35:17 [bob]
... is katy's suggested alternative text to the proposal
12:36:05 [uyalcina]
uyalcina has joined #ws-addr
12:38:57 [bob]
Scribe: Anish
12:41:10 [anish]
Bob: how do folks feel about this?
12:41:21 [bob]
12:41:27 [uyalcina]
12:41:29 [dhull]
12:41:39 [anish]
Tony: s/in SOAP Response/for SOAP Response/
12:41:41 [uyalcina]
12:41:45 [bob]
ack do
12:41:50 [bob]
cak u
12:41:50 [anish]
Umit: i think the heading is still incorrect
12:42:12 [anish]
... it is a general stmt
12:42:19 [bob]
ack u
12:43:59 [anish]
... s/SOAP//
12:44:31 [TRutt]
TRutt has joined #ws-addr
12:45:26 [anish]
RESOLUTION: resolve issue CR23 with proposal at
12:45:32 [anish]
no objections
12:46:20 [anish]
Topic: issue CR21
12:47:50 [anish]
Marc explains the issue
12:51:02 [bob]
12:51:56 [pauld]
pauld has joined #ws-addr
12:52:00 [anish]
jonathan: i feel that we made a bunch of changes in Vancouver and looks like we have issues about it.
12:52:27 [anish]
... our solution introduced more problems. Revert back to what we had, but open to fixing this however we can
12:55:11 [anish]
Discussion on what CR17 resolution did
12:57:14 [pauld]
rrsagent, where am i?
12:57:14 [RRSAgent]
12:57:41 [pauld]
rrsagent, make logs member-visible
12:58:33 [anish]
Marc: I would rather just define a default which is not context sensitive
12:58:49 [anish]
Glen: there are usecases where people can't use htis
12:58:53 [anish]
12:59:57 [anish]
Umit: in that case the property is no longer optional
13:00:07 [anish]
... it makes the header optional but not the property optional
13:00:35 [anish]
glen: u can fix it either way
13:00:44 [anish]
... if i care about one-way messages only then i don't care about it
13:01:05 [dhull]
can everyone still here on the phone
13:01:13 [dhull]
13:01:57 [anish]
anish: don't make premature optimizations, no default. if the property is there, it is there. Else it isn't.
13:02:09 [Jonathan]
zakim, who's on the phone?
13:02:09 [Zakim]
apparently WS_AddrWG(TP)3:00AM has ended, Jonathan
13:02:10 [Zakim]
On IRC I see pauld, TRutt, uyalcina, marc, Katy, TonyR, dorchard, Allen, anish, yinleng, jeffm, dhull, GlenD, Nilo, hugo, RRSAgent, Zakim, vikas, bob, Jonathan
13:02:38 [anish]
glen: instead of saying syntactic default, we can specify in the 'how to sent the reply' section
13:02:52 [anish]
13:02:54 [uyalcina]
13:02:55 [uyalcina]
13:03:13 [chad]
chad has joined #ws-addr
13:03:26 [anish]
glen: why do we need to specify that in the wsdl doc
13:03:28 [pauld]
chad, NORWICH :-)
13:04:01 [anish]
anish: how important is the default?
13:04:12 [dhull]
chad, ESSEX :-)
13:05:05 [bob]
13:05:26 [bob]
ack anish
13:05:31 [bob]
ack u
13:05:34 [anish]
glen: it is important as there are cases where the reply can be large % of the message.
13:05:49 [anish]
umit: in the wsdl doc, we have described using abstract message props
13:06:16 [anish]
... the reply endpoint should be there. But that does not mean that the header is there.
13:06:53 [marc];%20charset=utf-8#WSDLMEPS
13:07:05 [anish]
Marc: we can just delete section 5 in wsdl binding
13:07:15 [anish]
anish: i don't think we should do it
13:07:54 [anish]
glen: i don't think section 5 should be removed
13:08:25 [dorchard]
Glen suggestion: change "in message" to "used by communicating nodes".
13:08:26 [anish]
13:08:40 [dhull]
+1 to "hands off the core"
13:10:02 [bob]
13:10:08 [bob]
ack anish
13:10:31 [anish]
davidh: what we are trying to say that this is actually used in message exchange
13:11:06 [anish]
jonathan: i think we can revert CR17 and make the property required
13:11:44 [Katy]
13:12:33 [anish]
More discussion on various solution
13:12:45 [bob]
ack ka
13:13:05 [anish]
katy: my concern is that if we undo cr17, we have to make sure that it all works
13:13:26 [anish]
... can we fix it syntactically in the wsdl spec
13:13:56 [anish]
... under the MEPs, it says "this section describes whether properties are required or optional"
13:14:29 [dhull]
s/Mandatory/Required by MEP/?
13:14:34 [anish]
... we can change it to : this section says which core MAPs are rquried by MEPs of WSDL 1.1
13:14:45 [dhull]
13:15:13 [anish]
... and the top of the table change mandatory to requried
13:15:17 [bob]
ack dh
13:15:46 [anish]
dhull: i don't think change from mandatory to required does anything. we need to say that the requireness is for the MEP
13:16:04 [anish]
... the important part is "for MEP"
13:16:14 [anish]
umit: how does it solve the current problem
13:16:40 [anish]
... the MAP reply-to will always have a value
13:16:54 [anish]
Marc: u are mixing the abstract and serialized one
13:17:16 [anish]
... if u come up with another way to serialize this then it won't fly
13:17:51 [anish]
Glen: agree with katy's suggestion
13:18:01 [anish]
... we say there is no syntactic defaults
13:18:14 [anish]
... from the MEP there may be defaults
13:18:41 [anish]
Marc: i want to write a lib which can query soap message and get the abstract properties
13:19:14 [anish]
... if i have to default based on the context, i don't like it
13:19:38 [Katy]
13:20:00 [anish]
13:20:19 [Zakim]
WS_AddrWG(TP)3:00AM has now started
13:20:28 [Zakim]
13:20:37 [Zakim]
13:20:38 [Zakim]
WS_AddrWG(TP)3:00AM has ended
13:20:40 [Zakim]
Attendees were Mark_Little
13:21:03 [bob]
13:21:09 [anish]
umit: we can't put any case (where it has to fault if a value is not present) in our test case
13:21:14 [anish]
glen: that is a different issue
13:22:05 [anish]
marc: in this case, for our mapping, there will always be a value for [reply to]
13:22:17 [anish]
umit: without all the context you can never figure this out
13:22:36 [anish]
marc: we can add another note to make this clear
13:23:22 [hugo]
Zakim, who's on the phone?
13:23:22 [Zakim]
apparently WS_AddrWG(TP)3:00AM has ended, hugo
13:23:23 [Zakim]
On IRC I see chad, pauld, TRutt, uyalcina, marc, Katy, TonyR, dorchard, Allen, anish, yinleng, jeffm, dhull, GlenD, Nilo, hugo, RRSAgent, Zakim, vikas, bob, Jonathan
13:23:26 [Katy]
13:23:33 [hugo]
Zakim, list conferences
13:23:33 [Zakim]
I see WAI_PFWG(F2F-TP)2:30AM active
13:23:34 [Zakim]
also scheduled at this time are XML_EXI(TP)4:00AM, WS_AddrWG(TP)3:00AM, XML_XMLCore(TP)3:00AM, Team_Global(review)8:00AM, SW_DAWG(TP)8:00AM, VB_VBWG(TP-F2F)8:30AM
13:23:39 [anish]
Marc: proposal -- core section 3.4 note that for the serialization [fault to] and [reply to] is always present
13:24:06 [anish]
Tony: rather than saying that the processor will never fault, I would say that the MAP would never be empty
13:24:25 [anish]
... instead of talking about the behavior of the processor we should talk about the properties
13:25:57 [hugo]
Zakim, call TP_Iles_B
13:25:57 [Zakim]
ok, hugo; the call is being made
13:25:58 [Zakim]
WS_AddrWG(TP)3:00AM has now started
13:25:59 [Zakim]
13:26:01 [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 "" - see section 3.2 XML Infoset Representation of Message Addressing Properties
13:26:04 [anish]
Marc: proposal -- reopen CR17, close with clarification to the existing note and revert decision on CR17
13:27:18 [Zakim]
13:27:20 [Zakim]
13:27:21 [anish]
Umit: i prefer saying explicitly that we allow other serializations
13:27:22 [Zakim]
13:27:40 [anish]
bob: we have marc's proposal and see if we can converge
13:27:58 [anish]
... is this the approach to take to resolve this?
13:28:15 [anish]
... can we leave the wordsmithing to the editors?
13:28:27 [anish]
Umit: I'll work with marc on this
13:29:06 [anish]
Tony's proposed text: The [reply endpoint] messaging property is defaulted to "ANONYMOUS" by the current serialisation, so this MAP will not be empty.
13:29:41 [anish]
Bob: resolution - revert cr17, new text proposed by Tony and close issue CR21 with no action
13:29:57 [anish]
marc: cr21 should be closed with reversal of cr17
13:30:06 [anish]
umit: there will be clarification of the note
13:30:39 [anish]
ACTION: umit/tony/marc to figure out the wordsmithing for clarification to the note (CR17/CR21)
13:30:58 [anish]
zakim, who is on the phone?
13:30:58 [Zakim]
On the phone I see TP_Iles_B, Mark_Little
13:31:51 [anish]
Topic: Test status
13:33:00 [anish]
jonathan/paul: can we do that later but discuss the issue coming out of the tests
13:33:14 [anish]
Topic: ProblemHeader (test 1145/1245)
13:33:21 [anish]
Jonathan explains the issue
13:33:56 [anish]
Issue explained at:
13:34:14 [anish]
Jonathan: these features were marked at risk
13:35:09 [anish]
... 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
13:36:18 [anish]
hugo: we did not mark those things at risk
13:36:36 [anish]
... we put in a note saying that the section may change
13:37:33 [anish]
paul: from my POV i feel strongly about it. it has minimal with no value but requires lot of testing
13:38:13 [dhull]
13:38:18 [anish]
... my recollection from Boston was that it was at risk
13:38:46 [anish]
Hugo: i don't think removing something like that would change the reviewer/implementers experience
13:39:08 [bob]
ack dh
13:39:11 [anish]
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
13:39:38 [anish]
dhull: if this is not useful then i'm not going push on it
13:39:59 [anish]
jonathan: not a security expert, but i have heard that passing just a Qname is better
13:40:22 [anish]
dhull: u would send a message and the person receiving the message may not have the context
13:40:35 [anish]
bob: not heard anyone speaking strongly for this
13:41:19 [anish]
... do we have agreement that we redact the problemheader
13:41:37 [anish]
... it is the Team's opinion that it would not change the implementation experience
13:41:51 [anish]
RESOLUTION: redact problemHeader
13:42:09 [anish]
Topic: wsa:UnreachableDestination fault code
13:42:15 [dhull]
13:42:16 [anish]
Jonathan: not sure how to test it
13:42:24 [anish]
... no motivation
13:42:45 [anish]
... i don't want this fault code hold up CR
13:42:54 [anish]
... this isn't as clear cut as the last one
13:43:10 [anish]
... we could make it an informative test case rather than optional test case
13:43:20 [anish]
dhull: feel differently about it
13:43:33 [anish]
... the idea behind this is to deal with hop-by-hop or gateway situations
13:43:46 [MarkB]
MarkB has joined #ws-addr
13:44:20 [anish]
... if we want to do a test, we can create an endpoint that always throws a fault
13:44:33 [bob]
bob has joined #ws-addr
13:44:46 [anish]
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
13:45:24 [anish]
dhull: don't want to derail this. if we want to do it now or later that is fine
13:45:30 [bob]
13:45:35 [bob]
ack dh
13:45:51 [anish]
... the fact that no one has implemented doens
13:45:57 [anish]
.. n't tell us much
13:46:12 [anish]
... would like to keep it, will help with test cases
13:46:51 [anish]
<more discussion on various fault codes and what they mean>
13:48:42 [anish]
dhull: we should be able to make the box turn green
13:49:30 [anish]
bob: if status-quo means we need to have 4 imples then it is a problem
13:49:50 [anish]
jonathan: this is a more advanced feature and we can agrue that we don't need this now
13:50:02 [anish]
paul: i look at this fault and think it is not interoperable
13:50:12 [anish]
... no benefit of this
13:50:20 [anish]
katy: agree with paul
13:50:55 [anish]
dhull: this is not an advanced feature it is a simple feature
13:51:13 [anish]
tony: davidh your position would be more defensible if you had an impl
13:51:56 [anish]
jonathan: two different perspective, say it is more adv. feature
13:52:09 [anish]
bob: what do we have to do here to move on?
13:52:33 [anish]
davidh: there is no must here
13:53:05 [uyalcina]
13:53:22 [bob]
ack u
13:53:42 [yinleng]
yinleng has left #ws-addr
13:56:40 [anish]
bob: does the resolution mean just removing the testcase
13:56:53 [vikas]
vikas has joined #ws-addr
13:57:12 [anish]
hugo: we have an agreement that if we can't test it we'll remove it
13:59:21 [anish]
jonathan: we can say that we failed to get implementations of this particular error condition
13:59:31 [anish]
... advanced impl. can use this
13:59:41 [anish]
... we can't have every class of implementations
14:00:18 [anish]
bob: could be useful for say 'tcp/ip'
14:00:24 [anish]
... nothing to do with addressing
14:00:38 [anish]
dhull: in the gateway case not necessarily a transport failure
14:00:45 [anish]
... jabber case is another one
14:01:49 [anish]
dhull: not going to lie on the road
14:02:14 [anish]
jeff: the reason to set a criteria before you are under pressure is to create one that is reasonable
14:02:29 [Jonathan]
Jonathan has joined #ws-addr
14:02:41 [anish]
... hard to believe justification given now
14:02:58 [anish]
... don't believe any arguements about things happening in the future
14:03:10 [dhull]
14:03:11 [anish]
... this is supposed to be widely implemented spec and easy
14:03:23 [anish]
... we should stick with it and carry on with the program
14:03:32 [anish]
hugo: but nobody is using it
14:03:44 [anish]
jonathan: what are you suggesting?
14:03:45 [Allen]
Allen has joined #ws-addr
14:03:53 [anish]
jeff: don't move on till we have an implementation
14:04:30 [anish]
hugo: i don't understand that -- we have 3 (or 5) impl. and no one is using it
14:05:10 [anish]
jeff: either yank it out or implement it
14:05:31 [anish]
jonathan: i've a positioin that is compatible with that
14:06:07 [anish]
paul: test cases haven't been written
14:06:19 [anish]
dhull: lets be consistent
14:06:24 [uyalcina]
It appears that there are no test cases for section 6.4.1
14:06:31 [anish]
... i don't want to cherry-pick
14:06:38 [bob]
14:06:39 [dorchard]
14:07:09 [anish]
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)
14:07:27 [anish]
... it could be one fault or multiple fault
14:07:40 [anish]
... don't know the reasons for test cases for a few faults and not all
14:07:53 [anish]
... each fault code implies a processing model
14:08:35 [anish]
... each of these has a high cost
14:08:47 [anish]
... my company position to yang it out
14:09:01 [anish]
dhull: in that case we have to yank out other things too
14:09:06 [anish]
14:09:29 [bob]
ack dh
14:09:30 [Katy]
14:09:45 [anish]
dhull: are there test cases for actionnotsupported and endpointunavailable
14:09:48 [pauld]
14:10:30 [anish]
dhull: how do u know that the implementation is behaving properly
14:10:38 [TRutt]
14:10:48 [bob]
ack do
14:11:38 [anish]
daveo: is it a question of creating testcases or impl. just don't support it
14:11:53 [anish]
q+ to ask for break
14:12:19 [anish]
daveo: lets have the WG members write tests
14:12:30 [pauld]
14:12:38 [bob]
14:12:50 [anish]
daveo: standardized fault is important
14:14:15 [anish]
14:39:12 [dhull]
dhull has joined #ws-addr
14:45:18 [prasad]
prasad has joined #ws-addr
14:45:21 [anish]
anish has joined #ws-addr
14:45:23 [jeffm]
jeffm has joined #ws-addr
14:46:53 [anish]
Scribe: anish
14:47:19 [Katy]
14:47:23 [anish]
bob: we are trying to figure out appropriate way to move forward on the fault codes
14:47:57 [anish]
... 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
14:48:13 [anish]
... all of the faults in section 6 that are not tested
14:48:24 [anish]
dhull: actually all the optional faults (with no MUST)
14:49:32 [anish]
umit: why not create a non-normative fault codes
14:49:46 [anish]
jeff: need faultcodes for interop
14:50:07 [anish]
14:50:18 [anish]
jeff: helps to have std codes
14:50:23 [anish]
dhull: that is the idea
14:50:27 [uyalcina]
uyalcina has joined #ws-addr
14:50:27 [Nilo]
Nilo has joined #ws-addr
14:50:29 [anish]
... but nothing normative
14:50:48 [anish]
paul: i favor note, non-normative appendix has a cost
14:50:52 [anish]
... wrt errata
14:51:21 [anish]
... expectation is that it will grow
14:51:43 [anish]
... these are soap fault that are useful
14:52:38 [anish]
tom: non-Required faults are still normative for the clients
14:52:39 [hugo]
14:52:48 [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.
14:52:51 [anish]
jeff: i don't understand the packaging argument
14:52:52 [bob]
ack tr
14:53:23 [anish]
paul: i can pick up the ws-addr spec with 2 pages as opposed to 6 pages
14:53:38 [anish]
14:53:52 [anish]
jeff: there should be normative in the sense that they are defined by the rec
14:54:41 [uyalcina]
14:55:40 [anish]
paul: endpointnotavailable can be catch for a lot of things
14:55:50 [dhull]
14:55:51 [anish]
jeff: is helpful so that one can have a switch
14:56:18 [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.
14:56:31 [anish]
paul: want more of vendor specific codes
14:57:06 [anish]
... if the semantics can be nailed down -- which is a lot of work
14:57:14 [anish]
jeff: u don't have to test them
14:57:37 [anish]
bob: if the spec were to include the other non-must faults, those may be impossible/hard to test
14:57:43 [dorchard]
dorchard has joined #ws-addr
14:57:44 [anish]
jeff: we could write a test for that
14:57:49 [anish]
bob: we might
14:58:07 [TRutt]
TRutt has joined #ws-addr
14:58:09 [pauld]
pauld has joined #ws-addr
14:58:11 [anish]
dhull: fault is not the feature
14:58:28 [bob]
ack hu
14:58:40 [anish]
hugo: we are talking about section 4 and it is useless, times time, helps interop etc
14:58:56 [dhull]
14:59:03 [anish]
... put them on the whiteboard and find out which are releated to MUST, whether there is a test, implemented etc
14:59:22 [dhull]
14:59:37 [anish]
14:59:51 [bob]
ack uy
15:00:08 [anish]
umit: where are we going with the classification?
15:01:02 [anish]
... i'm worried that eliminating subcodes. Would like to compare with schema. Would like to keep most of the codes
15:01:37 [uyalcina]
s/compare with/compare their use how XML schema codes were useful with XML Schema implementations/
15:02:05 [anish]
<hugo draws a chart with various faultcodes and associated attributes: Must, Test and Implemented>
15:08:22 [dhull]
dhull has joined #ws-addr
15:10:06 [MarkB]
MarkB has joined #ws-addr
15:22:57 [anish]
jonathan: one of the difficulties with testing is that it is hard to create bad messages
15:23:32 [anish]
paul: not people writing test cases
15:23:43 [bob]
15:23:54 [dorchard]
dorchard has joined #ws-addr
15:23:58 [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.
15:25:04 [anish]
paul: my understanding was that implementations don't implement features in time, they are gone
15:25:13 [uyalcina]
Lets be fair here. WSDL binding just went to LC and some of the fault codes were added recently after Japan at Vancouver.
15:25:33 [anish]
Hugo's table:
15:25:34 [dhull]
15:25:40 [anish]
Problem hdr - Must:N Test:Y Impl:N
15:25:40 [anish]
Problem Hdr QN - Must:N Test:Y Impl:Y
15:25:40 [anish]
Problem IRI - Must:N Test:Y Impl:N
15:25:40 [anish]
Problem Action - Must:N Test:N Impl:N
15:25:40 [anish]
Retry After - Must:N Test:N Impl:N
15:25:41 [anish]
Invalid Addr Hdr - Must:Y Test:Y Impl:Y
15:25:43 [anish]
Inv Addr - Must:Y Test:N Impl:N
15:25:45 [anish]
Inv EPR - Must:Y Test:N Impl:
15:25:47 [anish]
Inv. Cardinality - Must:Y Test:Y Impl:Y
15:25:49 [anish]
Miss Addr in EPR - Must:Y Test:N Impl:
15:25:51 [anish]
Dup MID - Must:N Test:N Impl:
15:25:53 [anish]
Action Mismatch - Must:Y Test:N Impl:
15:25:55 [anish]
Only Anon - Must:Y Test:N Impl:
15:25:57 [anish]
Only Non-Anon - Must:Y Test:N Impl:
15:25:59 [anish]
Message Adr Hdr Req - Must:Y Test:Y Impl:
15:26:01 [anish]
Dest. Unreachable - Must:N Test:N Impl:N
15:26:03 [anish]
Action Not Supported - Must:N Test:N Impl:N
15:26:05 [anish]
Endpoint Unavailable - Must:N Test:N Impl:N
15:26:22 [bob]
ack dh
15:26:58 [anish]
s/Message Adr Hdr Req - Must:Y Test:Y Impl:/Message Adr Hdr Req - Must:Y Test:Y Impl:N/
15:28:46 [anish]
bob: we do not specify behavior
15:29:22 [GlenD]
GlenD has joined #ws-addr
15:31:24 [anish]
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
15:32:05 [anish]
katy: we should be able to look and them and remove if not needed
15:32:33 [anish]
umit: i pushed 2 error codes cause they are related to WSDL
15:32:38 [dorchard]
agenda question, what else is after the test cases?
15:33:47 [anish]
jonathan: if we can have a written proposal that can be reviewed by our engineers that would be good
15:33:52 [anish]
... and look at it tomorrow
15:34:18 [uyalcina]
those two error codes came in late in Vancouver, they are relevant for the WSDL binding.
15:35:15 [pauld]
I do not believe we have two implementations who have implemented each of these faults in the same way
15:35:37 [pauld]
WSDL Binding can develop it's own faults
15:35:46 [pauld]
15:36:06 [dhull]
q+ to reconsider whether a standard spelling with no standard semantics is helpful or harmful
15:36:29 [bob]
ack dh
15:36:29 [Zakim]
dhull, you wanted to reconsider whether a standard spelling with no standard semantics is helpful or harmful
15:37:08 [anish]
daveh: the reason for have the last three fault codes in hugo's table was to not to have a must around it, but have the spelling available for interop
15:37:14 [anish]
15:37:33 [anish]
... we could just pull the 3 out
15:38:23 [anish]
bob: proposal --
15:38:34 [anish]
... Define normatively two faults that MUST be implemented
15:38:46 [anish]
... 1)Invalid Adr Header; subfaults move to note
15:38:54 [anish]
... 2) message Adr Hdr req
15:39:06 [anish]
... 3) move all other non-MUST fualts to a note
15:40:41 [anish]
... 0) drop Dest unreachable, Action not supported and Endpoint unavailble faults
15:41:06 [dorchard]
For the record, I'll be in and out tomorrow AM then absent in the PM for other WG/TAG meetings..
15:42:29 [anish]
dhull: 0 is separate decision
15:42:40 [anish]
bob: any opposition
15:42:41 [anish]
15:42:45 [anish]
15:43:00 [Zakim]
15:43:02 [anish]
RESOLUTION: accepted (0) in bob's proposal
15:44:42 [anish]
jeff: don't agree that it should be in the note
15:45:02 [anish]
umit: what if there are in a non-normative appendix
15:45:30 [anish]
jeff: i want to be able to be count on these codes as a client
15:46:03 [anish]
katy: david thinks that we can remove more codes
15:47:11 [pauld]
s/david/David Illsley/
15:47:12 [anish]
15:48:08 [anish]
bob: there are a lot of flavor of Invalid Addr Hdr
15:49:32 [marc]
marc has joined #ws-addr
15:49:34 [anish]
jeff: normativeness means we reserve this slot in the NS
15:50:23 [anish]
hugo: we have done the generic category of Invalid Addr Hdr
15:50:39 [anish]
... don't find the necessity to test the details
15:50:47 [anish]
bob: we have tested at least one detail
15:53:52 [anish]
paul: unhappy camper
15:54:30 [anish]
... i went with the consensus in Boston with the assumption that based on implementors experience we'll rip it out if needed
15:55:00 [anish]
... would like to express my objection and get it on record
15:55:45 [anish]
... i would like to remove all rows that are optional
15:56:29 [anish]
... it is half-baked, we slapped it in there
15:56:54 [anish]
... it should not be in there
15:57:49 [anish]
jeff: in corba there were predefined codes which were hints to users
15:57:49 [dhull]
15:58:20 [anish]
paul: this will come back an bite us
15:59:19 [anish]
umit: we have two fault codes related to WSDL. WSDL isn't even in CR
16:00:09 [anish]
paul: i feel strongly about remove these codes, but i'm willing to move on cause we need to get done
16:00:32 [anish]
... error codes need to be machine processable
16:00:40 [anish]
jeff: other reasons to have error codes too
16:01:15 [bob]
q+ katy
16:01:24 [anish]
<discussion on error codes>
16:03:11 [anish]
dhull: intellence systems can go thru logs and do interesting things. So this is helpful
16:05:01 [Zakim]
disconnecting the lone participant, TP_Iles_B, in WS_AddrWG(TP)3:00AM
16:05:01 [anish]
dhull: i do agree that our processing model is weak (wrt codes)
16:05:02 [marc]
q+ to find out exactly what we are planning to remove
16:05:02 [Zakim]
WS_AddrWG(TP)3:00AM has ended
16:05:04 [Zakim]
Attendees were TP_Iles_B, Mark_Little
16:05:18 [bob]
16:07:17 [bob]
16:07:21 [anish]
katy: in response to Paul, agree with what he is saying, but we are down to only two faults
16:07:52 [anish]
... we got these subcodes/details, they will just fall out depending on what we decide
16:07:56 [marc]
16:08:32 [anish]
... we have - subcodes instead of throwing them into a note we should step thru them and see if they are needed
16:09:48 [anish]
... why not move the anon/non-anon faults to wsdl
16:10:09 [anish]
umit: we tell people when they are required but they are valid independent of that
16:18:57 [anish]
katy: problem action is not a fault, it is a detail
16:19:24 [anish]
bob: ah, it is part of invalid header hdr
16:19:30 [anish]
Bob's new proposal:
16:20:05 [anish]
1) invalid Adr header; tested one detial, leave the rest of the details (internal rationalization)
16:20:13 [anish]
2) message Adr Hdr req kept
16:20:31 [anish]
3) move all other non-MUST faults to a note
16:22:39 [anish]
dhull: i don't want to revisit closed issues
16:23:02 [anish]
Bob's new new proposal:
16:23:08 [anish]
1) invalid Adr header; tested one detial, leave the rest of the details (internal rationalization)
16:23:23 [anish]
2) message Adr Hdr req kept
16:24:43 [anish]
bob: we will close this tomorrow morning
16:25:03 [anish]
... tomorrow we are going to begin with the test report
16:25:23 [anish]
jonathan: our report is looking better, but will be better to have more vendor online
16:25:38 [anish]
bob: we also have wsa:From and source endpoint
16:25:46 [anish]
... identified as at risk features
16:26:55 [anish]
16:27:01 [bob]
bob has left #ws-addr
16:27:04 [RRSAgent]
I have made the request to generate anish
16:27:35 [anish]
zakim, who is on?
16:27:35 [Zakim]
I don't understand your question, anish.
16:27:42 [anish]
zakim, who is on the phone?
16:27:42 [Zakim]
apparently WS_AddrWG(TP)3:00AM has ended, anish
16:27:43 [Zakim]
On IRC I see marc, GlenD, dorchard, MarkB, dhull, TRutt, Nilo, jeffm, anish, prasad, Jonathan, vikas, Katy, RRSAgent, Zakim
16:27:51 [bob_]
bob_ has joined #ws-addr
16:29:23 [TRutt]
TRutt has left #ws-addr
16:29:32 [bob_]
bob_ has joined #ws-addr
16:29:55 [bob_]
bob_ has joined #ws-addr
16:30:49 [bob_]
bob_ has joined #ws-addr
16:31:04 [MarkB]
MarkB has left #ws-addr
16:35:02 [bob]
bob has joined #ws-addr
16:47:26 [bob]
rrsagent, make logs public
16:47:47 [bob]
rrsagent, generate minutes
16:47:47 [RRSAgent]
I have made the request to generate bob
17:01:43 [bob]
bob has left #ws-addr
17:04:51 [dhull]
dhull has joined #ws-addr
17:07:40 [dhull_]
dhull_ has joined #ws-addr
17:12:41 [dhull_]
dhull_ has joined #ws-addr
17:18:50 [dhull_]
dhull_ has joined #ws-addr
17:40:41 [dhull_]
dhull_ has joined #ws-addr
19:56:19 [dhull_]
dhull_ has joined #ws-addr
20:13:35 [dhull_]
dhull_ has joined #ws-addr
20:25:37 [Zakim]
Zakim has left #ws-addr
20:30:40 [dhull_]
dhull_ has joined #ws-addr
20:31:33 [dhull_]
dhull_ has joined #ws-addr
21:06:53 [dhull_]
dhull_ has joined #ws-addr