Web Services Resource Access Working Group Face to Face, Redwood Shores, CA

10 Jun 2009

See also: IRC log


Ashok Malhotra, Oracle Corp.
Asir Vedamuthu, Microsoft Corp.
Bob Freund, Hitachi, Ltd.
Bob Natale, MITRE Corp.
Doug Davis, IBM
Fred Maciel, Hitachi, Ltd.
Geoff Bullen, Microsoft Corp.
Gilbert Pilz, Oracle Corp.
Jeff Mischkinsky, Oracle Corp.
Li Li, Avaya Communications
Mark Little, Red Hat
Paul Nolan, IBM
Prasad Yendluri, Software AG
Ram Jeyaraman, Microsoft Corp.
Tom Rutt, Fujitsu, Ltd.
Vikas Varma, Software AG
Wu Chou, Avaya Communications
Yves Lafon, W3C/ERCIM
David Snelling, Fujitsu, Ltd.
Katy Warr, IBM
Orit Levin, Microsoft Corp.
Paul Fremantle, WSO2
Ranga Reddy Makireddy, CA
Sreedhara Narayanaswamy, CA
Bob Freund, Hitachi, Ltd.
Ashok Malhotra, Prasad Yendluri


<trackbot> Date: 10 June 2009

<Ashok> scribe: Ashok Malhotra

<Ashok> scribenick: Ashok

Starting on Wednesday June 10, 2009

Resuming yesterday.s meeting

Bob: I sent out a mail about 'mode'

<Bob> my mail this am http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0030.html

Bob: I tried to define what were called 'problems' yesterday

First, compositipn on 'mode' ... it is done as an attribute

scribe: extensions were suggested
... proposal is that extensions could be named as QNames

Bob: Do we agree that this is a way forward?

No disagreement

Bob: So we agree that a list of QNames would be a way to handle composability

Second problem is scope of the extensions

scribe: extensions apply to parent and children of element

Asir: So, in general, put extension where it belongs

Bob: ... as child of the thing it extends

Geoff: I'm concerned about this ... re.DeliveryMode
... you will agrue that all extensions go in NotifyTo or Subscribe and we don't need DeliveryMode

Bob: In aggregate the delivery mode you get is the result of the composition

<dug> <GB:Frog/>

Bob: that's the mode

Geoff: disagrees
... I accept that "we shd put things where they belong"
... I'm worried about the second-last problem

Bob: Let's wait till we get there
... Third, mode-not-supported fault ... what do we do abt that
... also the usecase 'I want to create a subcription only if all extensions are there"
... so I created boolean called 'strict' which says only create subscription if all extensions supported

Asir: I not sure all features you are trying to realize are useful
... you are trying to tighten the faulting mechanism

Bob: Sorta like mustUnderstand

Gil: Strict does not allow you to say these extensions are vital and these are optional

Ashok: Policy can be used to say what's required and what's optional

Geoff: There is the fault business that returns all this stuff ... we need fault to say that a delivery mode is not supported

Bob: We agree that we want a fault that the delivery mode cannot be supported
... we also agree there may be a usecase where a portion of the delivery mode is supported and that's acceptable

Asir: Differentiate between not understood and not accepted

Bob: You could use mustUnderstand faults in addition

Geoff: There is a concept of delivery and a fault that say I did not agree with how you want it delivered
... if we have lot's of delivery modes we must also have lot's of faults
... I did not understand how you wanted me to deliver stuff

Bob: We agree we need fault-tightening behaviour which also deals with composition problem

Wu: We want default of delivery mode as in the current spec

Tom: I'm trying to grasp the requirements
... I hearing strong attachment to this concept called "delivery"
... I want a fault that gives you the info yiu want
... Does not matter if it not called delivery

Dug: All will agree with fault that says 'I cannot meet yiur needs"
... but what is a dlivery need and what is a subscription need


scribe: why do you want a fault that says 'cannot meet delivery needs' and not just cannot meet your needs
... delivery need vs. subscription need

Dug: Do not classify faults .. we need we need a fault

Asir: Agree we ned to tighten faulting mechanism. We can define detailed faults later.

Bob: We also need to talk abt contents subscribe/response
... need to specify waht you got
... Let's talk abt Delivery Mode
... may be affected by more than one extension

Bob draws Subscribe box with NotifyTo and EndTo children

Bob: The concept of delivering stuff is NotifyTo + extensions plus other extensions that affect delivery (Delivery Concept)

Dug: Filter can also be part of delivery mode

Bob: Is EndTo part of delivery mode

Dug: If you cannot tell me why subscription ended prematurely that part of delivery mode

Bob: Delivery concept is everything subscription mgr must know to fulfill its contract with you

Tom: Delivey is in the eyes of the beholder

Asir: 2 cycles ... subscribe then response and end subscription and response

Wu: Separate delivery from subscription

Gil: Trying to classify extension as delivery extension or subscription extension is not useful

<Wu> We can view WS-E with three semantics components: Event subscription, Event Generator and Delivery engine

Dug: Suppose we kept the <delivery> element and decided that <frog> was a delivery extension
... now we put <frog> outside delivery ... waht what happen ... would system fall apart

Asir: Folks said WS-MAN put in extensions here that there, we need better guidelines

Dug: We have extension points and can put extensions in different places

Bob draws generic diagram of event source

scribe: six boxes all involved in my delivery
... do we need wrapper around extensions to each of the six bozes?
... Should it be possible to put an extsion at the subscribe level and affect everything?

Dug: Yes

Wu: Need to provide structure and people add etensions in a strctured manner
... I like current spec. Each element has an extension point

Bob: Are talking abt delivery element

Dug: I diagree that elements inside map to implementation bits
... need to tell what each extension applies to ... so put in appropriate element

Gil: We only talk abt EPR to EPR communication ... not abt implementation structure

Geoff: But we talk abt event source and a subscription manager in spec. So we separate them
... 2 separate concepts

Bob: EndTo is not related to delivery
... is there anything abt delivery concept not inherenetly connected to NotifyTo?
... is there any need to have an element associated with concept of delivery?
... NotifyTo EPR is essential

You specify 'push', 'push-with-acks' in the NotiFyTo EPR

Asir: Today PUSH is built into the spec as default
... if something is specified then that's the delivery mode
... today you can ignore evrything other than the address of the EPR
... If we say delivery mode needs to be inferred we need to say whare it is inferred from
... today if you say mode='something' then you must understand the mode

Bob: Anything in the scope affects its parent
... somesubset of the element you want to call a Delivery Concept

Asir: Delivery and NotifyTo

Geoff: Default is the 'push' mode. If we delete mode there is no way to say that

Bob shows how to do that ... put PUSH as final child of Subscribe

scribe: Format and Filter are separate elements
... I don't think Delivery element it dangerous. May not be necessary
... Mode is dangerous

Gil questions need for delivery element

Dug: Cannot classify extensions
... is Format a Delivery extension or a Subscription extension

Asir: It's an implementation problem

Gil: Supports Dug
... cannot classify extensions ... distinction does not affect anything

Bob: Asks if the delivery wrapper elemnt is removed is that a lie-down-in-road issue?

Wu: Yes

Geoff: Yes

Bob: If delivery element is not removed is that a lie-down-in-road issue?

Dug, Gil, Tom: Yes

Mark: Yes

Asir: Maybe we shd focus on delivery element some more to try and get consensus

Geoff: Where shd people send slides

Bob: To the public list

<asir> His name is Hemal Shah

That's the speaker coming up

WS-Man issues

Josh_Cohen: In 2003 customers meet with hardware vendores and asked for facilities to manage hardware independent of specific hardware
... DMTF took on this challenge with SMASH and DASH
... Intial feeling was Web Services stack was too heavy
... We now have 3 specs with Web Services profiles and features

Hemal: I work for Broadcom
... I started with WS-MAN in 2005
... folks were sceptical because spec was heavyweight and resources limited

<dug> Prasad: http://www.w3.org/2002/ws/ra/edcopies/wst.html#Factory_Create

Hemal: Start with WS-Eventing issue on removing 'mode'
... We are using 'mode'. We have defined several modes in WS-MAN
... If you remove mode you lose function which is in many implementations

Bob: As a single attribute is not composable
... proposal to replace mode with a set of QNames so they cam be composed
... you look for an extension QName
... there would be a set of elements rather than one attribute

Josh: Are there other elements also? Asks scope question

Bob: The scope of extension is the parent and its children
... the faulting behaviour needs to be tightened up
... it is optional so not reliable
... has unbounded list of elements and namespaces
... need to generate fault saying waht cannot be honored
... Folks divided in whether we need a delivery element and what shd be in it
... We have not decided on categories, whether we need them, what they are?

Hemal: We have implementations. If the info is in another element it will break the implementations.

Bob: Other changes we have agreed on will break wire protocols

Hemal: Keep the mode and also provide other facilities and allow both mechanisms

Bob: Mode as it is currently non-composable
... you would add elements e.g. Push-with-acks

Jeff: You will have to change becuse namespace will change and there will be other changes


scribe: we shd shift to how to migrate
... you could map extensions to modes

<asir> we should not worry about namespace name changes because wire compat is not a requirement .. feature-wise backward compat is a requirement

Gil: Extensibility model in WS-Eventing has change. Now ignore what you don't recognize not fault

Bob: We have moved <format> out and moved it higher up

Hemal: What possible extensions?

Gil: Relaible messaging or security for example
... argues composability requirements

Asir: We shd not talk abt security and reliability as extensions

Bob: Cannot anticipate extensions
... also need to be flexible abt scale of implementations

Hemal: If you add RM, and security that's not WS-Eventing.

Bob: We need to support composability

Hemal: People can extend values of mode attribute

Bob: E.g. push-with-acks is defined as specific URI value that can be used as value of mode.
... equivalent is a push-with-acks element. This could combine with other features such as queue management

Wu: You several good points. We are still discussing.

Hemal: My concern is removal of 'mode'
... if you remove it I worry about existing implementations and transition path

Asir: Keep RM and Security out of mode discussion. They are different.

Bob: Disagrees

Jeff: Mode does not compose and MS has been pushing 'composable specifications'

Bob: I would like to hear all of Hemal's concerns

Jeff: We are trying to ensure reasonable clean migration path but we don't have an absolute requirement to have backwards compatibility

Tom: The mode that has been defined is 'push'
... WS-Man has added others and they can define 'push-with-ack'

Hemal: Next point 6413 - T/RT merge
... didn't completely understand proposal. Is it trying combine Enum functionality

Bob: Current proposal is to move frgment support from RT and make that an optional party of T or possibly a separate spec.
... or possibly another form of fragment support
... still open on details
... no agreement yet

Hemal: Fragment level transfer poses signifact challenges in resource constrained envvironment
... more we can deal with this in headers the better

Bob: If frag level transfer is presented as a feature with a mustUnderstand type feature that would work for you?

Hemal: We can gennerate a fault

Bob: We are propsing it as an optional feature

Heaml: Is it going in body or header?

Dug: Currently in body but being worked on

Bob: You want to be able figure with minimal processing if you don't support it

Asir: We say it is optional but current proposal is not optional. We have raised an issue against the current proposal.

Moving to 6724

Geoff: Subscribe as a Resource

Hemal: You can get to instances once you have subscribe.

Bob: We will not remove GetStatus and Renew. Those are off the table

Dug: Eveting spec defines minimum function. Implementaions can extend

This would allow you get full properties of the subscription and even update subscription properties

Hemal: For the SIM case this will not provide any more information

Dug: Are you talking abt enumeration instances?
... this allows you reterive subscription properties. GET may not give you back what you need.

Bob: Has SIM extended Transfer to get this info
... what spec defines represenation of the subscription

Josh: With any SIM class you can manipulate subscription info

Bob: There is no conflict with that.

Josh: We want to make sure it is aligned with SIM or CIM can be put in it

Dug: I think we are talking abt something different. Please send mail so we don't lose your idea of possible conflict

Josh: We can followup with emal.

Bob: Someone shd open an issue. Very interested in follwing up with you.


<Bob> link to Josh's slides

<Bob> http://www.w3.org/2002/ws/ra/9/06/w3crawsman.ppt

<PrasadY> scribe PrasadY

<PrasadY> scribeNick PrasadY

<PrasadY> Starting the afternnon session

<Bob> scribenick: PrasadY

<Bob> scribe: Prasad Yendluri


Bob: Doug sent his write up on 6712 to the list

<Bob> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0031.html

Bob: That was the proposed resoloution to Issue 6712


When this OPTIONAL attribute is present it conveys additional information that can be used by the service to correctly process this message. If the service can determine the correct actions to take it MAY choose to ignore this attribute, even if the URI provided is not known. However, if the service needs this information, for example to determine if the child elements of the wst:Create are the literal resource representation or an instruction, but the a

Ashok: Why not call the "implied" value "default" value

Dug: I have seen both used but, ok

Geoff: What does the default/implied value http://www.w3.org/2009/02/ws-tra/ContentDescription/Representation mean?

Bob: As stated there is no way not to have a value

Agreement - Change the last sentence to say "no default value"

Asir: "Corretly" in 1st sentence should be dropped

Consensus: agreed

<Bob> When this OPTIONAL attribute is present it conveys additional information that can be used by the service to process this message. If the service can determine how to process the message it MAY choose to ignore this attribute, even if the URI provided is not known. However, if the service needs this information, for example to determine if the child elements of the wst:Create are the literal...

<Bob> ...resource representation or an instruction, but the attribute is not present or the URI is not known, then the service MUST generate an invalidContentDescriptionURI fault. There is no default value.

Asir: Name is contentDescription the fault also should be called the same (no URI in the end)


Asir: wants to name the attribute, contentDescriptionHint

Dug: Does not think the word Hint is needed. The description conveys that

Yves: Hint also means it is not trustable

Bob: Hints can be wrong

Ashok: Server can send a fault it wants. It is explained in a complex way
... Say, "if the server does not understand the att, it may send a fault'

Dug: we need to call out the two cases described explicitly
... if you needed the att to process the message

Ashok: does it matter to the client / user?

Dug: The spec needs to be clr on when the fault is generated

Gil: if you get a fault, you need to be able to look up the spec to understand when the fault is generated

Ashok: I am not going to make a big issue. Just i would have written that way

<asir> here is what we agreed yesterday

<asir> OPTIONAL Hint that describes the content, CONTENT DESCRIPTION. If the service needs a hint and the CONTENT DESCRIPTION is not known, then service MUST generate a fault (to be defined). If the service does not need a hint then may ignore the CONTENT DESCRIPTION and MAY NOT generate a fault. Type(CONTENT DESCRIPTION) = xs:anyURI

Dug: does not think hint is well-defined

Bob: In the version I have I have not added the Hint language

Asir: We agreed to it yesterday

Bob: I am happy to leave it as is, even though we used that word yesterday

<Bob> When this OPTIONAL attribute is present it conveys additional information that can be used by the service to process this message. If the service can determine how to process the message it MAY choose to ignore this attribute, even if the URI provided is not known. However, if the service needs this information, for example to determine if the child elements of the wst:Create are the literal...

Dug: I already added the fault to spec. I will change it to match above

<Bob> ...resource representation or an instruction, but the attribute is not present or the URI is not known, then the service MUST generate an invalidContentDescription fault. There is no default value.

RESOLUTION: Issue-6712 resolved with text above along with parallel modifications to the associated fault

Back on Issue 6692, Delivery concept

Bob: describes where we stand

in depth discussion on different ways to place the delivery bracket and if there is a value in having it or not

Bob: Suggests "stamp" element that qualifies the EPR (NotifyTo)

Wu: Stamp is equivalant to Delivery

Geoff: The Eventing spec saya there is a difference between subscription and event source. The arh boxes the concepts
... 2nd pt. Every one accepts push mode, yet we have no defined way to change it

Bob: We talked about Delivery.. Could you come-up with a concept of "Delivery"?

Dug: As an extension writer, I should be able to tell if it goes in Delivery or not

Geoff: accept that

<Geoff> the definition for delievery we should start with can be found in an email sent by Asir

<Geoff> the link is here: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0132.html

Dug: does not think Pull fits the above (MEP part)

Asir: Thinks it does

Bob: Can we simply define: Delivery is rules for transportation of Notifications from source to sink

Dug: How about batching?

Asir/Bob: That is formatting not transportation

Delivery is rules for conveyance of Notifications from source to sink

Ashok: Suppose we agree on this, how does it change things?

Tom: The from and To would be part of this

Gil: Thinks it is hard for people outsite this room to figure out whether an extension goes with delivery or not

Bob: With this definition Notify:to comes back into the bracket

Dug: Does not solve the EndTo problem

Bob: If no more arguments, we are going to decide

Asir: Not all directional proposals from this am have translated into concrete proposals

Tom: Rules don't go into the "Stamp", the effects of rules do

Not all effects may go into stamp also

Bob: Within the subscribe Msg - a Yes vote supports the directional decision to define an element that acts as a container for all extension QNames defined by this spec or externally, and data necessary fro conveyance of Notfications from Source to Sink

Dug: This is an incomplete soultion does not address EndTo

<li> i'm on queue

Li: WS-Eventing is a pt to pt protocol - establishing a channel from source to sink

Subscription establishes 2 links, between source and sink and subscription manager and client

Bob: Any other concerns before wew vote on the directional proposal?

Asir: Want to account for EndTo?

Dug/Gil: No need. May raise as a separate issue

Bob: Vote Yes - to support the wrapper

Avaya - Yes

Fujitsu - Yes

Hitachi - No

IBM - No

MS - Yes

Oracle - No

Redhat - No

Software AG - Yes

W3C - Yes

Yes - 5

No - 4

<li> one link = one wrapper

Bob: yes carries => Directional proposal
... We want to rest this and let it season for a bit
... Need a concrete proposal

Geoff: Will do in couple of weeks

Bob: Need it before 23rd so that people can look at it
... I have received a notification that Redhat has given proxy to Oracle for the duration of the F2F

Issue 6401

Gil: Recaps where we are

<Wu> http://www.w3.org/Bugs/Public/show_bug.cgi?id=6401

Wu: Issue, WSDL in WS-E does not confrom to WS-I BP

<Wu> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0127.html

Dug sent the above in March

Wu: Using Policy to link out bound operations with source is a clean solution

<Wu> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009May/0170.html

Li: Two proposals from Gil, (1) BP compliant (2) Make WSDL <....>

You link Event Source WSDL with Notification WSDL

<gpilz> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/att-0026/wseventing_6401.html

Geoff: Your proposal is centered around wrapped mode. Pls address why wrapped mode changes things

Gil: Details his proposal at the above URL

Geoff: Why do need this rather than WSDL

Gil: WSDL msg types etc define notification type - other parts are for raw notifications

<Bob> ACTION: Geoff to write a concrete proposal to capture the decisions to-date on Issue-6692 [recorded in http://www.w3.org/2009/06/10-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-70 - Write a concrete proposal to capture the decisions to-date on Issue-6692 [on Geoff Bullen - due 2009-06-17].

Dug: Describes why he found WSDL was not good enough

<Zakim> asir, you wanted to ask a question, what aspect of wrapped notifications did not fit into WSDL?

Asir: Wants concrete examples of why WSDL alone is not enough

Gil: Can provide

<dug> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/att-0026/wseventing_6401.html#NotifDescripSchema

Bob: Gil is ferminting[sic] the proposal and we have another proposal from Wu

Link to today's IRC log: http://www.w3.org/2009/06/10-ws-ra-irc#T19-05-17

Bob: Recessed until tomorrow

Summary of Action Items

[NEW] ACTION: Geoff to write a concrete proposal to capture the decisions to-date on Issue-6692 [recorded in http://www.w3.org/2009/06/10-ws-ra-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/06/29 16:37:56 $