See also: IRC log
<trackbot> Date: 12 May 2010
<Bob> scribenick: Tom_Rutt
All three new issues were accepted unanamously
No objection to accept proposal
RESOLUTION: close 9712 by resolving as proposed
-Issue-9713 GetStatusOperationSupported and UnsubscribeOperationSupported parameters not needed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9713 -Pilz
Gil: they must be supported by all subscription managers. There is no optionality.
Wu: when did we decide to make these madatory?
Ram: the definitions of the
operations state they must be supported.
... we decided to do this two face to face meetings ago, in Santa Clara
No objections to accepting resolution..
RESOLUTION: Issue 9713 resolve by accepting proposal
-Issue-9717 Frag: Add pre-defined dialect for Xpath 2.0 http://www.w3.org/Bugs/Public/show_bug.cgi?id=9717 -Freund
Dug: Is this only for Frag. We define Xpath 1.0 in eventing as well.
Bob: It is intended for all three specs.
Dug: should the new section be written just like the 1.0 section of these documents.
No objection to applying to eventing, enum, and frag
RESOLUTION: Issue 9717 resolved as proposed
Dug: he is looking for info in get
metadata response as to what supported types are
... He does not want to rely on policy
Gil: I do not understand why a get client who asked for a type, would be interested in other types.
Dug: If the client can deal with other types, they can use an "all" in the get metadata. He did not seem happy with this suggestion
Ram: It seems that a fault, with the additional information, would satisfy him
Dug: a fault is not appropriate,
since there might be multiple metadata types in a single request,
to fault all of them is not useful
... I think relying on interrogating policy is the best approach.
... I would not like to tweek the protocol, when policy can meet the need
Gil: I agree with Dug. Policy is the way to do this. If this a problem that people want to profile out, why not just remove the content attribute?
Dug: we need to give the client a way
to select which types it wants
... I cannot accept removing the attribute. Let them rely on policy
... for each dialect you support, you can list the type and format you support. In section 12
Gil: content attribute is optional, they can just say conformant profile clients cannot send the optional attribute. However, the server must be able to accept the attribute.
<gpilz> we don't like using the mics
Bob: I am hearing that the mechanisms are available, and their profile can require that clients not send the content attribute.
<gpilz> we're shy
No objection to close with no action
<Yves> gil :)
RESOLUTION: Issue 9700 closed with no action
<scribe> ACTION: Ram will write the response to the originator of issue 9700 [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-157 - Will write the response to the originator of issue 9700 [on Ram Jeyaraman - due 2010-05-19].
Dug: I modified the text around the getWSDLResponse/xs:any to allow references as well as the wsdl itself
added text description
When the GetWSDLResponse element contains any child elements, the first element MUST either be the WSDL metadata document, or a reference to the WSDL metadata document, of the endpoint. Any extension elements MUST appear after the WSDL document/reference. The absence of any child elements indicates that the endpoint does not have any WSDL document, or additional metadata, associated with it.
<Yves> How can a small device gain something by retrieving the same data using a new request/response insted of having the data inline. the mex env is not that big
Dug: the use case is that the endpoint does not have the entire copy of the wsdl, however they have a pointer to where the wsdl can be obtained
His third sentence seems to imply he is concerned about the server's requirements, not the client's
<Yves> returning a reference might help caching as well
Dug: we could suggest that the first choice is the raw data itself, only sendting the location or reference is the data is not available
Gil: If we are concerned about the
client requirements, we may need an attribute on the request, like
the content attribute
... Antoine's concern is for the server. The client can do get metadata. Leave it to the service to decide. The client would use whatever means it is presented with in the response.
Tom: what if the server wants to decide not to send the data for a short period, say due to network load. I think a mandate as to the preferred way to respond is untestable anyway
Dug: I can live with it being totally up to the server
Bob: is accepting the proposal acceptable to everyone?
No objections raised
RESOLUTION: Issue 9709 resolved as proposed
<scribe> ACTION: Dug to write the response to the reviewer Antoine [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action02]
<trackbot> Created ACTION-158 - Write the response to the reviewer Antoine [on Doug Davis - due 2010-05-19].
Dug: why call it a pseudo event?
Bob: also correct the spelling
Gil: I would think that a reasonable implementation would try to poke the event source before it returns the success response to the verify, otherwise a fault could be sent.
Tom: did you define a specific fault?
gil: in soap 12 speak it would be a receiver fault.
Tom: could we add a note on the intent of the success reponse
<gpilz> Note, it is expected that implementations will not send the VerifyResponse until they have taken the necessary actions to cause the notification of the verify event to be transmitted.
<gpilz> This allows the implementations that are experiencing internal errors to transmit a fault in response to the Verify request.
Dug: what fault would you send?
Gil: a receiver fault indicating an internal error would suffice
Dug: what is the difference between this fault, and the sequenceEnd with an EndTo present
Gil you can get this fault to the verify, but still consider the subscription as being active. It could be a short term error condition
Li: would would be the infoset for the verification event. There is no parts for the message.
Gil: an empty soap:Body is ok, since the information is in the WSA:Action value
Gil I do not understand the relevance of InfoSet in this matter
Wu: the verification event could contain information about the subscription
Gil: the verify event is the same as any other event which can be sent from the event source, other than the fact that is is never filtered
Wu: carry in the verify event which particular verify request invocation is being responded to
Tom: he seems to be asking that the verify event report carry the message id for the verify request that stimulated it
Dug: why would we need that
Wu: It could give information on the delay between the request and the event emission. It would also allow detection of verify requests which never resulted in a verify event. More diagnostic information is available
Dug: Wu's proposal requires more complexity in the communication between the subscription Manager and the event source. Also it implies a complicated set of analysis by the event sync
Wu: I would prefer that we have time to think about this further
Gil: This extension to correlate
verify event with the verify request is going beyond the
requirements behind this issue. Timing aspects of the path
verification are not required for the use case.
... I do not see the relevance of the infoset problem.
<gpilz> Note, it is expected that implementations will not send the VerifyResponse until they have taken the necessary actions to cause the notification of the verify event to be transmitted. This allows the implementations that are experiencing internal errors to transmit a fault in response to the Verify request.
Dug: I can live with the implementation note. However, I would like to see more information on the types of fault that may be returned. When would that fault not be bad enough to kill the subscription?
Tom: there might be a temporary condition causing the lack of communication between the sub manager and its event source.
Gil: The client receiving this fault without a subscription end would tell the client it can try the verify again at a later time, with the potential of success
Wu: we would like time to consider extension to the simple proposal, which may make it more useful for other use cases
<gpilz> ws-man v1.1 says this about the heartbeat event: "The heartbeat event itself is simply an event message with no body and is identified by its wsa:Action URI as follows: . . ."
Ram: we could modify the get status semantics to require that the sub manager only return a success if it knows the event source is alive. That would cover this requirment
Tom: Ram's suggestion covers half of the requirement for heartbeat, It would not also verify the communication path between an event source and its event sync, in the case where the event source is at a different sending port than the port used by the subscription manager get status response
Gil: it is not possible for the event source to verify its link to the event sink.
<Yves> do we need to check everything, from the path between the sub manager to event generator, to the even generator and receiver?
Bob: to turn this into a network diagnostic would require a lot of additional mechanisms to be in place.
Dug: there may be proxies between the event source and the event sink
Bob: it is difficult to think of all
the possible failure modes in this kind of a "ping" mechanism. We
need to restrict our discussion to finding a proposal to meet the
needs that issue originator brought forward, with sufficient
widespread use to make it part of the base eventing spec.
... they are asking for a heartbeat mechanism to figure that both the event source is alive, and also that the communication channel between source and sink is functioning.
Gil: I would hate to see this issue hold up our specs. If we cannot agree to a simple solution that meets there needs, I would prefer to close with not action
Wu: how about modifying the get status operation to have the get status response be returned from the event source to the event sync
Gil: That would cause more problems than it solves. The get status requester may not be the same as the event sink
<Yves> get status through the event sink is a bad solution, even delivery and status checking are two different things
Gil: perhaps the verify feature could be triggered by an extra parameter to the get status.
Dug: I think that it makes sense to have the information on the get status response to be returned in the verify response. Why do we need two operation types, if an option on get status could add the triggering of verify event
Bob: who in in favor of changing the proposal to adding an optional verify element to get status to also do the verify event trigger.
Several indicate that if we do anything for the verify, we should merge it as a feature of get status.
Only Fujitsu and Oracle indicated that this new verify feature be added to get status.
Wu: I could accept such an addition if if did more than the simple proposal.
Bob: can we have a decision by Thursday morning?
Agreed that we will schedule decision for Thursday morning of F2F.
-Issue-9675 Eventing: Clarify attachment of NotificationWSDLs to the EventSource policy assertion http://www.w3.org/Bugs/Public/show_bug.cgi?id=9675 -Mensch
Dug: I did what we agreed to yesterday.
Gil: I would like to remove the word "only" in the second line of the explanation for the example.
Dug: I can live with removing the word "only", it is true but I agree not necessary
No objection to accepting amended proposal
RESOLUTION: Resolve Issue 9675 with proposal as amended by striking word "only"
dug: there is no requirement for event source to understand anything other than NotifyTo element. He wants a fault when the event source cannot accept an extension
Bob: we had this discussion at past
F2F regarding the usual soap extension model.
... why do we need a fault, why not just eliminate the sub manager epr from the response?
Dug: we are really trying to say that there must be some delivery mechanism present. However the wording puts it in xml speak. He would rather have a fault, rather than just creating the subscription after ignoring extensions
Gil: they want new fault, "I recognize there is something extra in the request, but I do not know what to do with it"
Dug: define "no delivery mechanism fault" when there are not children elements, or no elements which are understood by the event source
Gil: but I might understand, but do not want to support the mechanism.
Bob: Fault when no delivery mechanism has been established.
Agreed to have Dug write a full proposal which reflects the discussion above.
RESOLUTION: Resolve Issue 9701 by adding new Fault "NoDeliveryMechanismEstablished" with appropriate explanatory text
<scribe> ACTION: Dug to write response to issue 9701 reviewer explaining our solution to his issue [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action03]
<trackbot> Created ACTION-159 - Write response to issue 9701 reviewer explaining our solution to his issue [on Doug Davis - due 2010-05-19].
Gil: Antoine seems to assume you can profile out features that the base spec states you MUST support
Dug: you have to understand these attributes, while you do not have to support all the values
Gil: this is a sender optional
feature, thus the service must be capable of handling it when
present. They could profile as "conforming clients in this profile
MUST NOT include this in the request message
... they seem to be worried about clients which do not conform to the profile. The only way to give him what he wants is to change the definition of this feature being both client and server optional
... you would have to add a policy parameter for this, and also add a fault to indicate the server does not support it.
Dug: what if the server supports the syntax, however it never can satisfy any value in the expires. It can send the existing fault all the time
Gil: we could make the entire expiry mechanism to be server optional. The policy and fault would be indicating non-support of entire expiry mechanism. The other alternative resolution is close No Action
Dug: another alternative is only allow a duration for expiry. Get rid of min and max
<Dug> and exact
Bob: for servers that do not support ranges of time, they will simply respond to the max value
Gil: the server can just pick the max and give it to the subsription
Dug: they want to have the server to
be able to pick the expiry time, irregardless of what the client
... the spec requires that the server check that min is smaller than the max, otherwise fault the request
... how about "no expires element -> server choice" , "Exact time, if present must be honored to create subscription"
... also have expires be server optional
Gil: I would like to get rid of date/time, and rely on duration only
<Dug> Expires is server optional, add a fault for when its not supported, add a ExpiresSupported policy assertion, Subscribe w/o Expires == server chooses, Subscribe + Expires == match the time/duration or fault
No object to the above as a directional resolution
Agree to finalize decision on Thursday morning
Reconvene at 1:08 PM
Dug: if the content attribute is not
present, the default is any format. However, they cannot profile
out the server behaviour when the content attribute is present but
... when the content attribute is present, the server must support it or not accept the request.
Review event descriptions and their attachment mechanisms
Dug: one thing Antoine is concerned
about is the potential duplication when the same event type is
associated with more than one wsp:Policy assertion type
... he wants an element in the wsdl descriptions doc which has list of event types. This element is referred to in the wsp:Policy.
... he is adding the wse:Notification element to policy eventSource which has an attribute pointing at that element in the descriptions doc.
... He wants to be able to have everything in a single document, and also have reuse of the definitions in that single document.
... rather than adding this notifications element to the policy assertion, have the mex:Location to have a relative URL so it can point to EVDs that are embedded within the same doc.
... this would be a change to the mex spec to allow relative url, and also to the event spec to allow multiple event description elements within the event source assertion.
... I have some concerns about the relative URL. we would have to use the wsu:Id attribute
Gil BP does not allow wsdl description extensions to be required.
Dug: I like this relative URL better
than using a QName pointer mechanism
... my proposal would still put the event description in the wsdl, but changes the way it is pointed at.
... for the Notification WSDL , his QName points to a port type
... my proposal again allows mex:Location to be relative. the mex:Location would have a Type attribute.
... notion of relative URI for mex:Location is a change which can be justified on its own right. The change is allowing more than one event description to appear, and a reference for the wsdl element.
... our event source assertion needs to describe what happens when there are multiple instances appearing inside it.
Gil: I would like some time to think about this one.
Agreed to defer decision until Thursday at this F2F
In addition to the edits in Katy's
proposal, the following additional things were changed:
- Updated xsd
- Updated wsdl
- Added Content to DeleteMetadata request (more below)
- Added the Fault boilerplate text to the new "Faults" section
- Added the boilerplate text to the Notational Conventions section about
- Added a ref to the WSA SOAP Binding spec - due to the new faults section
- Added ... to GetMetadataResponse pseudo-schema
Dug: ... I want everyone to be aware of the changes I made, and to ensure that I did not make any mistakes during editing
I've included two word docs - one is a diff of the final mex spec against
the mex spec prior to these edits, and one is a diff of the mex spec
against Katy's proposal. This will allow people to see the edits from two
different perspectives. FYI - some of the diffs in the *-katy-diff.doc
are due to the other issues we resolved today not being part of Katy's
version - so you can ignore those change bars.
Gil: We have a proposal on the table of the BP group on this topic, and are working hard to partitioning the section on wsdl into two sections: Changes to Wsdl spec vs Profiling of WSDL requirements.
Bob: open issues include 8284, Heartbeat/verify, Expiration time not supported, Event descriptions attachment mechanisms
All but 8824 are scheduled for decision Thursday of this F2F
Bob: our charter requires for each
feature in spec, in order to exit CR we need to have two
independent implementations that implement those features
... we need to get an Idea of which parts of the spec companies are not planning to implement
Key: ? = Thinking; X = Won't; I = Intend, date uncertain; Date is date for schedule availability
Bob: I propose to all to look at
SoapUI as a tool to employ for testing
... we need to get the people from each company who will be doing the test implementations together
... we will be testing the spec in a behavioral sense. Not a man in the middle network sniffing based approach (such as done in WS-I)
... for each of these specs we have to determine on a feature by feature basis which features will be implemented by at least two implementations
Bob: we need to convert all the Intentions into a specific date . What is the Date that we have Dates ready by?
<scribe> ACTION: Gill to catalogue eventing with an eye to which features might be at risk [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action04]
<trackbot> Sorry, couldn't find user - Gill
<scribe> ACTION: Gil to catalogue eventing with an eye to which features might be at risk [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action05]
<trackbot> Sorry, couldn't find user - Gil
<scribe> ACTION: gpilz to catalogue eventing with an eye to which features might be at risk [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action06]
<trackbot> Created ACTION-160 - Catalogue eventing with an eye to which features might be at risk [on Gilbert Pilz - due 2010-05-19].
Bob: Features in the CR marked at
risk, will not be included in the Final Rec, if they have not met
the implementation bar. Features that have not been marked at Risk
in CR, will prevent the spec from reaching Rec status until those
features reach the implementation bar
... how can we distribute out the specs to people to define the test scenarios and methods to test each feature in the feature catalogue
Dug: can the scenario doc be the same template for each ws-ra spec?
Gil: can we agree to basic principles
for each scenario.
... E.G. any person who is not a member of the WG should be able to understand the contents of each test scenario
<scribe> ACTION: Dug to create a template for test scenario Doc to use for all of the WS-RA specs [recorded in http://www.w3.org/2010/05/12-ws-ra-minutes.html#action07]
<trackbot> Created ACTION-161 - Create a template for test scenario Doc to use for all of the WS-RA specs [on Doug Davis - due 2010-05-19].
Gil: Mex needs a primer.
Bob: Katy has volunteered to write the primer on MEX
Feature Catalog volunteers:
Gil: Eventing, EVD
Katy - MEX
Ram - Transfer
Dug - Frag, SA
Dave S - possibly for Enum
<Bob> Please indicate your agreement or disagreement to this resolution by a reply to this email
Agreed we need to add above sentence to each response
Agreed to send response on 9607 to Gil with the added sentence
agreed to add the additional para to Tom's suggestion: "the WG
believes that the number of potential items in the enumeration, while
interesting, isn't nearly as valuable as the total size of the
enumeration (total byte count of the data, not just the # of items).
This would allow for better pre-allocation of resources than simply
knowing the number of items. However, since calculating the total
size of the entire enumerated data set could be very expensive, the
cost of doing this at Enumerate() time didn't seem to be worth the
additional cost." as well as the boilerplate last sentence
Also make the bug number correct in the response (9608)
Agreed to send proposal from Gil on response
Dug: I an not happy with the first paragraph, since there is nothing in the spec which states you can put multiple event reports in a wrapped format (even if they have the same action value)
Wu: however we can do this today, without violating the ws eventing spec
Gil: I would not accept this unless we had a paragraph in the spec regarding whether the order is significant (e.g., switch open/ switch close / switch open). It would be dangerous to imply you can do this unless you have text stating the assumptions on ordering in time
Dug: we also have to be concerned about the faulting of specific event reports in the batch. We have not thought about this in the spec, so I do not like us implying this as a possibility in our response
Bob: how about removing the second sentence of first para
Also, remove "Beyond that, the group feels:" as the second para intro
Add the boilerplate last sentence
Wu: why cannot we add text to the spec regarding using wrapped to do some form of batching?
Bob: that would have to be raised as a new issue, it is not available at this time to put in a response to the ws-management group
agreed to send with additional boiler plate last sentence
Agreed to send as is with addition of final boiler plate sentence
<Ram> Proposed response: The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states  that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a fault for the service to indicate it does not support
Ram: I posted my proposed response just above
<Ram> The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states  that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a fault for the service to indicate it does not support a particular conten
Dug: in the compliance section of every spec we state that an optional element of a request MUST be able to be handled by a server, Unless the Spec has specific text allowing it as a server otion
<Ram> of Content attribute allowing a service to return any content type.
<Ram> The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states  that when the Content attribute is not present it defaults to any content type.
<Ram> This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format.
<Ram> Hence, there is no need for a fault for the service to indicate it does not support a particular content type. Thus, a profile could remove the use of Content attribute allowing a service to return any content type.
<Ram>  ÒWhen not present the default value is "http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any".Ó
<Bob> The WG discussed this and decided to close this issue with no change. This is because the WG felt that since the specification currently states  that when the Content attribute is not present it defaults to any content type. This allows a client to NOT use the Content attribute that would allow the service to send back the metadata in any content type/format. Hence, there is no need for a...
<Bob> ...fault for the service to indicate it does not support a particular content type. Thus, a profile could remove the use of Content attribute allowing a service to return any content type by a client.  ÒWhen not present the default value is "http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any".
Add first para: in the compliance section of every spec we state that an optional element of a request MUST be able to be handled by a server, Unless the Spec has specific text allowing it as a server option
<Ram> Further, if the client wants a particular content type or format, it can request that by specifying that in the GetMetadata request.
Bob responded to Frederick Hirsch on this
<Bob> recessed until tomorrow at 9:00