IRC log of ws-ra on 2009-11-06

Timestamps are in UTC.

16:51:42 [RRSAgent]
RRSAgent has joined #ws-ra
16:51:42 [RRSAgent]
logging to
16:51:44 [trackbot]
RRSAgent, make logs public
16:51:44 [Zakim]
Zakim has joined #ws-ra
16:51:46 [trackbot]
Zakim, this will be WSRA
16:51:46 [Zakim]
ok, trackbot, I see WS_WSRA(TPAC)11:30AM already started
16:51:47 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
16:51:47 [trackbot]
Date: 06 November 2009
16:53:10 [Bob]
rrsagent, this meeting spans midnight
16:54:40 [Bob]
chair: Bob Freund
17:00:51 [asoldano]
asoldano has joined #ws-ra
17:01:37 [Zakim]
17:04:11 [Zakim]
17:06:17 [Wu]
Wu has joined #ws-ra
17:06:37 [Ram]
Ram has joined #ws-ra
17:07:16 [trutt]
trutt has joined #ws-ra
17:07:56 [Bob]
scribe: Wu
17:08:19 [li]
li has joined #ws-ra
17:08:35 [Wu]
bob: email sent to mailing list to update the issues
17:09:00 [Zakim]
17:09:04 [gpilz]
gpilz has joined #ws-ra
17:11:05 [Bob]
Topic: Moriatorium
17:12:42 [Wu]
gil: we ask time to Friday next week to finish the review
17:12:47 [dug]
can you hear asir?
17:13:01 [asoldano]
actually not very clearly
17:15:11 [asir]
asir has joined #ws-ra
17:15:18 [Wu]
bob: any objection to extend the deadline to close on 11/13/09?
17:15:32 [Wu]
bob: no objection. It is passed.
17:16:20 [Wu]
bob: issue 8031
17:16:49 [Wu]
asir: we need more time
17:17:00 [MartinC]
MartinC has joined #ws-ra
17:17:28 [Wu]
asr: to settle use cases with my team
17:18:14 [Wu]
bob: issue 7728
17:18:42 [Wu]
17:19:12 [Wu]
gil: point 2 of 7728 is already addressed.
17:19:36 [Wu]
gil: point 1 of issue 7728 is the one to address
17:19:41 [gpilz]
17:20:21 [Wu]
gil: this is the attachment for point 1 of issue 7728
17:23:09 [Sreed]
Sreed has joined #ws-ra
17:23:55 [Wu]
tom: likes it.
17:24:24 [Wu]
asir: we had some discussion on this issue over mailing list.
17:24:26 [asir]
Here it is
17:24:35 [Zakim]
17:25:32 [Zakim]
17:25:45 [Wu]
asir: there are two assumptions. First assumption - policy at EPR applies to all
17:25:48 [Zakim]
17:26:28 [Wu]
asir: second - consumer knows almost everything
17:27:40 [Wu]
asir: thinking points: who defines it, what is the relation between policy sitting in EPR and out-of-band agreement,
17:27:54 [gpilz]
17:27:58 [Wu]
asir: what is the policy subject
17:28:35 [Bob]
ack gp
17:29:03 [trutt_]
trutt_ has joined #ws-ra
17:30:09 [asir]
17:30:11 [Wu]
gil: i think may not need to address since it is quite common.
17:31:04 [Wu]
regarding your point A. point B needs to explore.
17:31:51 [trutt]
17:33:44 [Wu]
gil: we need to more clear for point C.
17:33:55 [Bob]
ack asir
17:34:17 [Wu]
asir: regarding point A, it may not be common for other people.
17:35:09 [trutt]
The ability to attach a policy expression pertaining to the endpoint as a whole to an epr, would be used in cases where there are not concerns about policy conflicts at a more granular level.
17:35:16 [Bob]
ack tr
17:35:51 [asir]
q+ to ask a question
17:36:21 [Wu]
Wu has joined #ws-ra
17:36:28 [Bob]
ack asir
17:36:28 [Zakim]
asir, you wanted to ask a question
17:36:47 [Wu]
asir: this proposal is out for long time, anyone has implemented it?
17:37:04 [Zakim]
17:37:25 [Wu]
asir: it has been there for 21/2 years.
17:37:51 [gpilz]
The policies attached to an EPR in this matter apply to all bindings, portTypes, operations, and messages associated with the endpoint referenced by the EPR.
17:37:53 [Wu]
17:39:16 [Wu]
bob: the WG has its own charter. We should be regard of our own charter/interest.
17:40:04 [Wu]
bob: there seems point C can be crisper.
17:40:28 [gpilz]
The policies attached to an EPR in this manner apply to all bindings, portTypes, operations, and messages associated with the endpoint referenced by the EPR.
17:42:13 [Wu]
gil: the posted text is trying to address point C
17:42:35 [Zakim]
17:43:30 [asir]
17:43:49 [Bob]
ack asir
17:44:31 [Wu]
asir: it is o.k. to say these assumptions are made.
17:45:35 [Wu]
asir: for example in section 8 of MEX that assuptions are positively documented.
17:46:10 [Wu]
bob: AI on Gil/Asir to work on a refresh version of proposal for issue 7728
17:46:31 [Zakim]
17:46:39 [Wu]
bob: issue 8124
17:46:55 [Vikas]
Vikas has joined #ws-ra
17:47:30 [Wu]
17:48:28 [Ram]
17:48:53 [Bob]
ack ram
17:48:53 [Wu]
dug: I don't see to split the namespace for policy
17:49:45 [Wu]
dug: I don't see real benefit of it.
17:50:51 [Wu]
ram: is there a value to change value in policy space which is isolated?
17:51:07 [Wu]
dug: it might cause more confusion.
17:51:18 [Sreed1]
Sreed1 has joined #ws-ra
17:52:59 [Wu]
gil: the chance to change policy only peice is small.
17:55:21 [Wu]
bob: it seems a coin flap choice in this case.
17:56:16 [Wu]
bob: we have examples that go both ways.
17:56:39 [Wu]
bob: the proposal is to consolidate the namespace.
17:57:25 [Wu]
asir: what is the harm of having two separate docs?
17:57:40 [Wu]
dug: cann't see real benefit.
17:58:01 [Wu]
asir: separate data and meta data is one benefit.
17:58:28 [Wu]
jeff: physically separation does not mean much.
17:58:44 [Wu]
dug: it is easy to read.
17:58:59 [Wu]
bob: any objection to proposal?
17:59:52 [Wu]
bob: no objection. issue 8124 is resolved with single namespace proposal
18:03:47 [Zakim]
18:06:11 [fmaciel]
fmaciel has joined #ws-ra
18:07:46 [Sreed]
Sreed has joined #ws-ra
18:13:36 [trutt_]
trutt_ has joined #ws-ra
18:17:27 [Wu]
bob: issue 7911
18:17:33 [gpilz]
18:17:53 [Bob]
18:18:57 [Wu]
yeves: my point to put a warning in the text, that people should be aware the possible descripency with some warning text.
18:18:57 [gpilz]
{some combo of specs} allows receivers to dispatch on either the [Action] property or the QName of the [Body] child. Implementations that authorize requests based on the requested operation are advised to ensure that the property values used for such authorization decisions are consistent with the property values that are used for dispatching.
18:18:59 [Bob]
ack gp
18:20:07 [Bob]
18:20:52 [Wu]
gil: adding the above sentence in security section should do the trick.
18:21:37 [Ram]
18:22:39 [Bob]
ack ram
18:23:25 [gpilz]
18:23:38 [Wu]
ram: why just limit to two options, there may be other ways.
18:24:14 [Bob]
ack gp
18:24:38 [Ram]
18:24:58 [Bob]
ack ram
18:25:44 [Wu]
ram: If there are multiple ways, the first sentence can be dropped.
18:26:16 [asir]
18:26:26 [Wu]
Yves: first sentence is to describe the issue and non-binding
18:26:54 [Bob]
ack asir
18:27:44 [Wu]
asir: confused from a different view about the proposal
18:27:56 [Wu]
bob: any text change proposal?
18:28:08 [Wu]
asir: needs to think about it.
18:28:34 [Wu]
bob: any objection to resolve this issue as Gil's text?
18:28:45 [Wu]
asir: needs more time.
18:29:38 [Wu]
bob: Gil puts this proposal into bug proposal and discuss in future meeting
18:31:00 [dug]
Event Source : A Web service that accepts requests to create subscriptions for the subscriber to receive certain type of notifications.
18:31:02 [dug]
18:31:09 [Bob]
Topic: Issue-7970
18:31:13 [asir]
Asir mentioned that MSFT needed more time to work on 7911 because we have so many WS-R
18:31:16 [dug]
18:31:31 [asir]
s/so many WS-R/so many WS-RA work items scheduled for the next WG meeting/
18:33:31 [Wu]
bob: please post the consolidated proposal of issue 7970
18:33:42 [dug]
18:34:26 [Bob]
18:38:34 [Wu]
ram: why sending notifications is not mentioned in event source
18:39:49 [Wu]
ram: if we may add event source may send notifications
18:40:00 [Bob]
18:40:55 [Wu]
dug: proposal to move "notifications may be sent by any ..." to the definition of event source
18:41:00 [dug]
18:41:19 [Bob]
ack bob
18:41:24 [Bob]
ack dug
18:41:29 [Wu]
bob: remove term "notification"
18:41:54 [Wu]
dug: i am o.k. but it should be raised as a separate issue.
18:42:08 [dug]
(if there's any push-back)
18:42:29 [Wu]
bob: propose to remove "one-way" in notification to "a" message.
18:43:08 [Wu]
gil: "one-way" in the definition of notification is not clear.
18:44:13 [Wu]
bob: any objection to accept comment #8 as resolving issue 7970?
18:44:41 [Wu]
bob: no objection. Issue 7970 is resolved.
18:46:11 [Wu]
bob: issue 7986
18:46:13 [Wu]
18:46:17 [gpilz]
18:46:33 [asir]
18:48:10 [Zakim]
18:48:10 [Wu]
gil: what happens if a subscriber request to event source, and the policy in that Notify EPR does not match the policy this proposal advertising?
18:48:51 [Bob]
ack gp
18:49:00 [Wu]
gil: we might need to a new fault for this.
18:49:39 [Wu]
18:49:51 [Wu]
dug: that is fine
18:49:56 [Bob]
ack asir
18:50:23 [Wu]
asir: if there is descripency, it is caused by the provider, right?
18:52:00 [asir]
Our comments are here
18:52:00 [Wu]
gil: this is not my concern. what happens policy in subscribe does not match the policy being published by provider.
18:53:15 [Zakim]
18:54:03 [gpilz]
18:54:10 [Wu]
asir: when you get back notification wsdl, it may be able to stay alone and maynot.
18:54:51 [Wu]
asir: we would like to have a method to get all meta data, not just wsdl.
18:56:35 [jeffm]
jeffm has joined #ws-ra
18:57:00 [Wu]
dug: if you want to get missing meta information, why just ask for it specifically.
18:58:32 [Wu]
gil: ask schema should get all schemas the endpoint knows about.
18:59:09 [Wu]
asir: this is point, why we need to add new dialect if this is the case.
19:01:27 [Wu]
dug: if metadata is optional, implies imcomplete metadata (e.g. has policy but not wsdl)
19:02:26 [Wu]
can happen. Do we need to solve the problem to get policy where is no wsdl?
19:03:00 [asir]
19:03:24 [Vikas]
Vikas has joined #ws-ra
19:03:37 [Wu]
dug: asking notification policy is something of interest and special.
19:03:59 [jeffm]
19:04:08 [Bob]
ack gp
19:05:31 [Bob]
ack asir
19:05:53 [Wu]
gil: all metadata are optional. There is a use case that event notification type does not have wsdl.
19:07:22 [Wu]
dug: it might solve this issue by putting this policy in endpoint.
19:07:53 [Wu]
dug: it applies to event sink endpoint.
19:08:11 [asir]
19:08:38 [Bob]
ack jeff
19:09:18 [Wu]
jeffm: optional is not helpful.
19:09:26 [Bob]
ack asir
19:10:33 [asir]
19:10:38 [Wu]
asir: there are two kinds of metadata: service metadata and notification metadata. If they separate, the problem might be solved.
19:11:20 [jeffm]
what i said was that repeating the "its optional mantra" is not helpful,because we are writing a MetaDATA spec which says what to do and how to specify the metadata when it is there
19:11:29 [trutt_]
trutt_ has joined #ws-ra
19:11:58 [Bob]
ack asir
19:13:21 [Wu]
dug: why we just create a new dialect "notification policy"?
19:16:04 [Wu]
dug: if using separate dialect, it will separate different cases.
19:18:22 [trutt_]
trutt_ has joined #ws-ra
19:21:10 [Wu]
asir: you are heading to the design pattern using dialect to do division.
19:22:42 [trutt_]
trutt_ has joined #ws-ra
19:25:28 [Wu]
gil: in mex, two class uris can use, e.g. generic (all), and specific (schema).
19:27:03 [Wu]
bob: two choices i.e. notification wsdl is wsdl or not.
19:28:01 [Wu]
dug: similar problem as discussed yesterday, implicit wsdl or real application wsdl. we need a flag to tell.
19:29:36 [Vikas]
Vikas has joined #ws-ra
19:33:16 [Wu]
bob: one alternative to call these dialects collection uri
19:33:50 [asir]
19:34:13 [Bob]
ack asir
19:34:40 [Wu]
dug: it means using a list of qualifiers
19:34:51 [Zakim]
19:35:21 [Vikas1]
Vikas1 has joined #ws-ra
19:35:34 [Wu]
bob: you can have three categories dilects, collection identifiers, and qualifiers.
19:37:10 [asir]
19:37:19 [Wu]
AI: Asir/Doug come back with new solution proposal.
19:37:34 [dug]
Gil too
19:37:47 [asir]
s/"Asir/Doug"/Asir, Doug and Gil/
19:38:39 [Bob]
ack asir
19:40:13 [Wu]
bob: issue 8198
19:41:22 [Wu]
19:41:27 [Ram]
19:41:44 [Bob]
ack ram
19:42:22 [Wu]
ram: i would be fine to be the owner of this issue.
19:43:24 [Wu]
ram: the problem is: people wants to link wsdl at the design time, and if there is a mechnism on it.
19:44:41 [Ram]
19:49:08 [Bob]
ack ram
19:52:14 [asir]
19:52:24 [Wu]
dug: may just pass the meta data document, one with notification wsdl and one with event notification. would that work?
19:53:10 [Wu]
dug: i am poking what solution will solve this problem.
19:53:33 [Bob]
ack asir
19:54:50 [asir]
19:55:18 [gpilz]
gpilz has left #ws-ra
19:55:18 [Wu]
gil: mex meta data document contains both. The linkage is they are in the same meta data document.
19:55:20 [Bob]
ack asir
19:55:46 [Wu]
asir: the max you can infer is "collection". Any inference to be drawn is out of band.
19:56:09 [Wu]
19:56:37 [Bob]
recessed until 13:00 pacific
19:56:44 [Zakim]
19:56:49 [fmaciel]
fmaciel has left #ws-ra
19:57:40 [Zakim]
19:57:41 [Zakim]
WS_WSRA(TPAC)11:30AM has ended
19:57:42 [Zakim]
Attendees were apis-db-stuff, asoldano, J.Mischkinsky, li, Vikas
20:05:13 [Vikas]
Vikas has joined #ws-ra
20:35:12 [dug]
dug has joined #ws-ra
20:39:21 [trutt_]
trutt_ has joined #ws-ra
20:47:07 [Bob]
Bob has joined #ws-ra
20:47:17 [Bob]
20:49:27 [fmaciel]
fmaciel has joined #ws-ra
20:50:35 [li]
li has joined #ws-ra
20:51:26 [Zakim]
WS_WSRA(TPAC)11:30AM has now started
20:51:32 [Zakim]
20:58:26 [Zakim]
21:00:40 [Sreed]
Sreed has joined #ws-ra
21:00:47 [gpilz]
gpilz has joined #ws-ra
21:01:36 [MartinC]
MartinC has joined #ws-ra
21:01:58 [Bob]
scribenick: trutt
21:02:59 [trutt]
Topic: issue 8068
21:03:08 [Bob]
21:04:16 [Wu]
Wu has joined #ws-ra
21:04:29 [gpilz]
21:04:46 [Ram]
Ram has joined #ws-ra
21:04:51 [Ram]
21:05:09 [asir]
asir has joined #ws-ra
21:05:12 [trutt]
Dug: some people would like to see the Event Description section (A.1) pulled out into a separate document/spec.
21:05:21 [asir]
21:05:22 [Bob]
ack ram
21:05:28 [asir]
21:06:00 [trutt]
Ram: what would be title of he new little spec?
21:06:09 [trutt]
Dug: we have to decide on that
21:06:13 [dug]
21:07:05 [trutt]
Dug: there would be a reference from ws-eventing to this "little" spec
21:07:41 [trutt]
Asir: what is the use case. Are there other specs which want to use it?
21:07:51 [trutt]
Martin: SCA eventing might want to use it
21:09:02 [jeffm]
jeffm has joined #ws-ra
21:10:45 [asir]
Here is a sentence that won't make sense in a separate doc
21:10:46 [asir]
•The /soap:Envelope/soap:Body/wse:Notify element has a single child element
21:12:29 [trutt]
No objection to a directional resolution to have editors to proceed with pulling out the Event Description (A.1/A.1.1) as a separate small specification
21:13:31 [Ashok]
Ashok has joined #ws-ra
21:13:41 [gpilz]
21:17:18 [trutt]
Topic: Issue 6435
21:17:20 [trutt]
we expect a new version of the state table to appear at future meetings.
21:17:21 [trutt]
Topic: Issue 7791
21:17:23 [trutt]
Consistent Policy applied to a set of resources
21:19:02 [trutt]
Dug: I would prefer to give Paul an email explaining that if he does not provide a proposal, the issue would close with no action
21:19:21 [trutt]
Ownership assigned to Asir
21:20:00 [trutt]
Asir to urge Paul to provide a proposal for resolution
21:24:23 [trutt]
Gil: this seems to want to introduce yet another scope selector (or axis) on the resource metadata to be returned.
21:25:28 [trutt]
Gil: any proposal needs to take into consideration the other proposals regarding meta data scope, like app vs implicit wsdl, notification vs regular wsdl, etc.
21:26:17 [trutt]
Asir: so Paul needs to motivate the need, and relate to the other issues on metadata scope which we are working on.
21:26:28 [asir]
and provide a concrete proposal
21:27:14 [trutt]
Topic: Issue 8201
21:27:15 [trutt]
Clarify required and optional operations
21:28:41 [trutt]
Ram: I suggest that all WG members look at my characterizations of the optionality of each operation, and comment on them so we can come to resolution.
21:29:12 [trutt]
Dug: I have a concern about why getStatus should not just be required.
21:30:20 [trutt]
Ram: if there is a general requirement for this feature, we can make it mandatory. I want to ensure there is a valid use case for requiring get status operation always.
21:30:45 [trutt_]
trutt_ has joined #ws-ra
21:31:32 [Bob]
scribenick: trutt_
21:31:54 [Wu]
21:32:50 [Bob]
ack wu
21:33:04 [trutt_]
Wu: I am happy with the general idea, but we need to agree on the actual set of mandatory operations.
21:33:34 [trutt]
Dug: ws frag does not need to say anything about get or put, because they are inherited from ws transfer.
21:33:50 [Bob]
scribenick: trutt
21:35:03 [trutt]
Bob: what should we do about get status? Should it be required?
21:36:40 [Ram]
21:36:48 [trutt]
Wu: I need time to check on the need for get status before I decide
21:37:24 [trutt]
Action: Ram to produce a concrete proposal based on his email.
21:37:24 [trackbot]
Created ACTION-119 - Produce a concrete proposal based on his email. [on Ram Jeyaraman - due 2009-11-13].
21:38:22 [trutt]
s/proposal based on/proposal for operations being required/optional, based on/
21:39:45 [trutt]
Dug: I suggest Ram pick a spec, and do an exemplar of how to specify the optionality. Perhaps eventing would be best to do it.
21:40:10 [trutt]
Topic Issue 7774
21:40:12 [trutt]
@mode in ws-frag is harmful
21:40:38 [dug]
21:40:57 [Bob]
ack ram
21:41:41 [Bob]
ack dug
21:41:44 [trutt]
Yves: Get rid of '@mode' and use Create(Frag) Delete(Frag), like it's done for
21:41:46 [trutt]
21:42:08 [trutt]
Yves: could Dug explain the reason for this @mode
21:44:03 [trutt]
Gil: ws frag is extending ws-transfer. verbs in ws-t have a context. a ws-t put is on resource as a whole. The insert is creating a new bit of fragment, however from view of ws-t it is acting on the resource as whole. It is changing the resource even though it is removing a piece of the resource.
21:46:02 [trutt]
Yves: what is fragment identifying. Is the verb on the whole resource of just the fragment.
21:48:33 [trutt]
Dug: with put you may delete a bit, but it is still an instruction to update the resource. that is why put is the best verb rather than a delete.
21:49:41 [trutt]
Dug: the dialogue URI could be used to accomplish your patch example.
21:51:33 [trutt]
Dug: I would like to think more about whether we could get rid of remove mode and instead use an empty value with a put.
21:53:00 [trutt]
Dug: may need to distinguish missing value and empty value
21:54:27 [trutt]
Defer resolution until after further email discussions.
21:54:54 [Zakim]
21:54:55 [trutt]
Topic: Issue 7969
21:54:57 [trutt]
Fragment: clarify behavior of optional xml
21:56:21 [trutt]
Dug: Add the following sentence to the end of the paragraph referenced above:
21:56:23 [trutt]
When @Mode is 'Insert' or 'Replace', any optional values (element or
21:56:24 [trutt]
21:56:26 [trutt]
within this subset that are not specified in the wsf:Value element will be set
21:56:28 [trutt]
to a resource-specific default value.
21:56:51 [trutt]
No objection to resolve issue 7969 with proposal in issue
21:57:20 [trutt]
Topic: issue 8191
21:57:21 [Bob]
21:57:22 [trutt]
serialization of fragment Put input is underspecified
21:57:24 [gpilz]
21:58:22 [trutt]
Gil: In the descriptions of the "XPath Level 1" and "XPath 1.0" expression
21:58:23 [trutt]
languages, WS-Fragment describes some important serialization rules for text and attribute nodes, however it does not say if or how such rules should be applied to /wst:Put/wsf:Fragment/wsf:Value's.
21:59:16 [dug]
22:00:09 [Bob]
ack dug
22:00:35 [trutt]
Gil: does the spec require to wrap text values as in a get, or can the value be used on its own.
22:01:16 [trutt]
s/text values/text values for an attribute/
22:01:59 [asir]
22:02:41 [trutt]
Dug: If there are more than one value returned, the wrapper may not be needed. Xpath level 1 does not return more than one value, so the wrapping might not be needed.
22:03:20 [trutt]
Dug: You might not need it for a put if there is no need to send more than one value on the request. I see no need for such a separator on the input side of a put.
22:03:27 [gpilz]
<wsf:Value>1</wsf:Value> or <wsf:Value><wsf:TextNode>1</wsf:TextNode></wsf:Value> ??
22:04:05 [Bob]
ack asir
22:05:14 [trutt]
Gil: if I am trying to replace a text node with ws-frag put, do I use the first form or the second form in the example above. The spec needs to be clear on this.
22:05:16 [Zakim]
22:06:02 [trutt]
Gil: how to serialize attribute nod and text node values on the ws-frag put.
22:06:12 [trutt]
s/nod and/node and/
22:06:29 [asir]
Gil wants clarity nothing is broken tho
22:06:51 [trutt]
Dug: we need to go off and think about this. I expect you do not need it on the input of the put operation.
22:07:37 [trutt]
Gil: If I use the response from a get operation to later use in a subsequent put, it might be beneficial to not require a change in the way the value is wrapped.
22:09:01 [asir]
22:09:32 [dug]
22:12:03 [trutt_]
trutt_ has joined #ws-ra
22:12:15 [trutt_]
Dug: I do not see a need to put a sequence of values.
22:13:16 [trutt_]
Bob: a streaming processor can deliver a text node as a sequence of text rather than as a whole.
22:13:40 [dug]
22:13:57 [Bob]
ack asir
22:14:57 [trutt]
Asir: Xquery serialization deals with this already. We should look at that.
22:15:07 [asir]
here it is
22:15:32 [trutt]
Agreed to leave this issue open to further investigation and discussion.
22:41:17 [trutt]
Topic: issue 8157
22:41:21 [Bob]
22:42:27 [trutt]
Define an EmptyFilter fault like we did for eventing
22:42:29 [trutt]
22:42:31 [trutt]
22:42:55 [Ram]
22:43:05 [trutt]
Gil: it seems like a good idea to me
22:43:08 [Bob]
ack ram
22:44:56 [trutt]
Ram: I would like to defer resolution until later.
22:45:12 [Zakim]
22:45:14 [Bob]
22:45:30 [trutt]
Topic: Issue 8158
22:45:32 [trutt]
22:45:59 [trutt]
In example 3.1 proposal:
22:46:01 [trutt]
change (20) to be:
22:46:02 [trutt]
(20) <wsen:Expires min="PT10M"> PT10M </wsen:Expires>
22:46:12 [trutt]
No objection to resolve 8158 with proposal.
22:47:02 [trutt]
Topic: Issue 8160
22:47:04 [trutt]
22:48:17 [asir]
22:48:20 [trutt]
check to see if all "required" uses are meant to be RFC2119 uses
22:48:30 [Bob]
ack asir
22:49:50 [trutt]
Asir: it is not a global change of "required" to "REQUIRED". eg accountabiliy in security section should not be a keyword.
22:50:38 [trutt]
Dug: this applies to enumeration as well.
22:51:07 [trutt]
Agreed to defer resolution until all the uses of the word "required" are examined individually.
22:51:12 [Zakim]
22:51:52 [trutt]
Agreed to change "needed" to "used" in the two exceptions that are listed in the issue proposal.
22:53:38 [trutt]
Topic: Issue 8163
22:53:40 [trutt]
22:53:41 [trutt]
No objection to resolve issue 8163 as proposed.
22:53:49 [Zakim]
22:54:06 [trutt]
Topic: Issue 8166
22:54:08 [trutt]
22:56:04 [Ram]
Ram has joined #ws-ra
22:56:05 [trutt]
No objection to resolve Issue 8166 with change to: "The term "subscription manager" in this specification refers to" to "The term "subscription manager" is used in this specification to refer to".
22:56:34 [trutt]
s/change to:/change from:/
22:57:18 [trutt]
Topic: Issue 8167
22:57:20 [trutt]
22:58:07 [trutt]
No objection to resolve 8167 as proposed.
22:59:55 [trutt]
Asir: reconsider, since we have to edit the paragraph to remove rfc 1119 terminology.
23:00:21 [trutt]
Agreed editor to remove rfc 2119 keywords from the paragraph cited in the bug.
23:01:04 [trutt]
No objection to resolve 8167 with amended proposal to remove rfc 2119 keywords from paragraph.
23:03:30 [trutt]
Topic: Issue 8168
23:03:31 [trutt]
23:03:33 [trutt]
No objection to resolve issue 8168 as proposed.
23:04:06 [trutt]
Topic: Issue 8169
23:04:07 [trutt]
23:09:01 [gpilz]
However, if a subscriber wishes to have notifications annotated with unique SOAP header blocks then it MAY includes reference parameters within the wse:NotifyTo element. These reference parameters will be processed as specified by WS-Addressing 1.0 - SOAP Binding.
23:09:02 [trutt]
23:11:41 [dug]
23:12:08 [Bob]
act tru
23:12:13 [Bob]
ack tru
23:12:23 [Bob]
23:13:44 [trutt]
No objection to resolve issue 8169 with proposed change in comment #1 from bugzilla.
23:16:10 [trutt]
Topic: 8170
23:16:12 [trutt]
23:16:14 [trutt]
Martin: change "demarshalling" to "unmarshalling"
23:16:15 [trutt]
No objection to resolve issue 8170 with proposed change in comment #2 from bugzilla
23:16:46 [trutt]
Topic: 8172
23:16:48 [trutt]
23:18:38 [trutt]
Tom: change "and MUST" to "which MUST" in the proposal
23:19:02 [trutt]
No objection to resolve issue 8172 with proposed change in comment #1 from bugzilla
23:19:38 [trutt]
Topic: Issue 8177
23:19:40 [trutt]
23:20:18 [trutt]
No objection to resolve Issue 8177 as proposed.
23:20:58 [trutt]
Topic: Issue 8179
23:21:00 [trutt]
23:21:02 [trutt]
No objection to resolve Issue 8179 as proposed.
23:21:47 [trutt]
Topic: Issue 8184
23:21:49 [trutt]
23:23:28 [Bob]
Atten: My Dear
23:23:29 [Bob]
Your overdue payments of $3.5Million had resolved to pay you in cash,by
23:23:31 [Bob]
packaging the monies and deposite to UPS COMP. inform of Family
23:23:32 [Bob]
Valuable Gift to deliver to you,to avoid another hoax as you
23:23:34 [Bob]
disappointed in the past please do not disclose this transaction with
23:23:35 [Bob]
any person for security them with your full information
23:23:37 [Bob]
and also do not let them know that your package contains funds to avoid
23:23:39 [Bob]
them delay your package as i register it in the name of family
23:23:40 [Bob]
23:24:56 [trutt]
No objection to resolve Issue 8184 as proposed.
23:29:32 [Bob]
Issue 8186
23:30:02 [Bob]
RESOLUTION: 8186 resolved as proposed
23:30:06 [trutt_]
trutt_ has joined #ws-ra
23:31:29 [trutt]
Topic: Issue 8162
23:31:30 [trutt]
23:31:32 [trutt]
No objection to resolve issue 8162 as proposed
23:32:07 [trutt]
Topic: Issue 8199
23:32:09 [trutt]
23:32:39 [trutt]
No objection to resolve issue 8199 as proposed.
23:33:23 [trutt]
Topic: Issue 8213
23:33:25 [trutt]
23:36:10 [trutt]
No objection to resolve Issue 8213 as proposed
23:38:47 [trutt]
Topic: Issue 8214
23:38:49 [trutt]
23:38:51 [trutt]
Dug: Katy meant for them to be siblings.
23:40:47 [trutt]
Dug: I say make the text agree with the schema.
23:41:40 [trutt]
No objection to resolve Issue 8214 as proposed
23:42:21 [trutt]
Topic: Issue 8204
23:42:22 [trutt]
23:46:31 [trutt]
No objection to resolve Issue 8204 as proposed.
23:47:42 [trutt]
Topic: Issue 8178
23:47:44 [trutt]
23:48:03 [trutt]
Dug: this is superceded by Issue 8201.
23:48:15 [trutt]
No objection to close as supercedec by Issue 8201
23:49:24 [trutt]
Bob: It is time to get another snapshot. Can the changes get into the editor's drafts before the snapshot.
23:49:59 [trutt]
Yves: monday morning would be a good time for the snapshot.
23:50:28 [trutt]
Dug: I can do it by Monday morning EST.
23:50:54 [trutt]
Bob: Dug should tell Yves when he has incorporated the changes.
23:53:52 [trutt]
Topic: Issue 8176
23:53:54 [trutt]
23:56:28 [trutt]
Asir: I recall that this is reconsidering an issue from Hursley that we resolved.
23:56:52 [trutt]
Agreed to leave open to allow investigation of Hursley discussion
23:57:12 [Zakim]
23:57:47 [trutt_]
trutt_ has joined #ws-ra
23:57:53 [trutt_]
23:58:46 [trutt_]
Topic: Issue 8181
23:58:48 [trutt_]
23:59:19 [trutt_]
agreed to defer discussion since it is not editorial.
23:59:47 [trutt_]
Topic: Issue 8200
23:59:49 [trutt_]
00:01:00 [Zakim]
00:02:13 [trutt]
Dug: mex-all IRI can never appear in a metadata section. So the table is misleading.
00:05:37 [Zakim]
00:06:22 [trutt]
Asir: I need more time to invistigate why it was put in originally.
00:06:24 [trutt]
Dug: I think it was just a copy from the request table.
00:06:25 [trutt]
Agreed to keep issue open for more time
00:06:29 [fmaciel]
fmaciel has left #ws-ra
00:07:25 [gpilz]
gpilz has left #ws-ra
00:07:42 [Bob]
rrsagent, generate minutes
00:07:42 [RRSAgent]
I have made the request to generate Bob
00:07:47 [Zakim]
00:07:54 [Zakim]
00:07:55 [Zakim]
WS_WSRA(TPAC)11:30AM has ended
00:07:56 [Zakim]
Attendees were li, apis-db-stuff, J.Mischkinsky
00:08:58 [MartinC]
MartinC has left #ws-ra
00:30:54 [Zakim]
WS_WSRA(TPAC)11:30AM has now started
00:31:00 [Zakim]
WS_WSRA(TPAC)11:30AM has ended
00:31:01 [Zakim]
Attendees were
01:19:08 [Zakim]
Zakim has left #ws-ra