See also: IRC log
<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
c/dlivery/delivery/
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
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
s/beuse/because/
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.
END OF MORNING SESSION. BREAKING TILL 1PM PACIFIC
<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
[Body]/wst:Create@ContentDescription
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)
agreed
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
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
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
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