Web Services Resource Access Working Group Teleconference -- 02 Oct 2009

<trackbot> Date: 02 October 2009

<dug> yves - I'm blocked again - could you look at the logs?

<Bob> scribe: Ram Jeyaraman

<Yves> dug, I only have access to the black lists

<Yves> and the ip you gave was not in it

<dug> 195.212.29.67

<dug> try that one

<dug> yves, is 195.212.29.67 in the blacklist

<Yves> yep, clearing it

<Yves> done

<dug> fixed! thanks

<Ram> scribe ram

<Bob> scribenick: Ram

<Bob> agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0008.html

7088 implementation

<Bob> proposed xsd/wsdl at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0010.html

RESOLUTION: XSD/WSDL from Doug looks good. No objections to publishing WS-Fragment as a FPWD.

6721

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

<dug> proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/att-0011/wst-implicit.doc

Doug: The text in 7.2 is the old text; says you can advertise the policy.
... In the new text, I changed policy to metadata.
... This is an initial pass at what we discussed day before.

Asir: Two comments.
... These two paragraphs there are a continuation of the para under 7.2. When a dialect URI is defined we need to provide an identifier. Not defining is fine but we need to call it out.

Doug: There were some reading flow issues; so i did it this way.
... I am fine with rearranging it if it improves the flow.

Asir: There is one semantic change relating to the identifier; identifier is not defined.

No objections so far on the suggested change.

Jeff: why does this proposal still talk about XML SOAP URI?

Doug: We don't have a standard version for it.

Bob: The WSDL dialect is defined in the MEX specification.

Jeff: Should the dialect URI use a WS-RA namespace?

Bob: You should consider filing an issue.

<dug> http://www.w3.org/Bugs/Public/attachment.cgi?id=761

Jeff: When are the operations exposed.

Asir: When the applications want to expose them.

<Bob> from comment #2 of Issue-6694 (directional decision during the August F2F)

<Bob> RESOLUTION: (directional) everything is implicitly defined with WS-Policy

<Bob> assertions, optionality of operations to be indicated by assertions or some

<Bob> other appropriate WS-Policy mechanism. In addition the wsdl will be in the

<Bob> specs

Katy: If a decision had been previously made not to put explicitly in the WSDL, the quoted resolution does not contradict it.

Wu: My understanding is that by using the policy assertion the endpoint is declaring implicit support for all the operations.

<gpilz> s/indicate that a certain security algorithm is needed to use the WS-Transfer operations./indicate that a specific security mechanism is used to protect the WS-Transfer operations for this endpoint./

Asir: Two a concrete change. Change 'while' to a 'when';

Gil: Should there be a statement that operations cannot explicitly appear when the policy assertion is used?

Asir: This is in the first paragraph of section 7.

Wu: I want to see a clear declartion that I support WS-Transfer operations.

Bob agrees with Asir's comment.

Wu does not agree with Gil's point.

Bob: We have already agreed that if the policy assertion is present, then all operations are implicitly supported.

Wu: The policy assertion section covers many things beyond just the implicit behavior.

<Yves> implicit declaration doesn't forbid explicit and more tuned declaration

Doug agrees.

<Yves> implicit means "it's not defined, resort to using this"

Katy: The text already covers all the possible options. Transfer is implicitly defined, explicitly supported, not suported.
... Not supported implies Not a Transfer resource.
... It strikes me that there has been a clear decision about not openly supporting explict option.

Bob: The specification does not require use of policy or WSDL.
... Although we have said that policy is not the exclusive way, but if policy is used, that implicitly defines the operations.
... True or not?

Martin: It is ambiguous whether it is implicit or explicit.

Bob: The meaning of the existence of the policy indicates Transfer is supported. Implicitly or explicitly supported is undefined.

<Wu> There should be a specific policy assertion to indicate that the operations are implicitly supported.

Bob: Do we agree that when the policy assertion is present, the operations are implicitly defined?

Doug: Whether policy is used or not has no bearing on whether it is implicit or explicit.

Bob: If the policy assertion exist, what does it mean?

Doug: All it means is, service is advertising support for transfer. Meaning, transfer operations are supported.

Asir: The policy assertion indicates you are supporting the required operations and with the policy params it supports the optional operations.
... When an endpoint supports policy, and Transfer, and uses policy assertion, it is indicative of the operations being supported implicitly.

Bob: We don't want to revisit earlier agreements. The resolution to 6694 indicates that when policy assertion is engaged implicit support of operations is expressed.

Gil is describing an use case.

Gil is defining an application WSDL that contains the Transfer operations. The policy appears in the WSDL as well.

Asir: It is redundant.

Gil: Is it illegal?

Doug: The policy assertion is indepent of implicitly.

Bob: We discussed that we had previously discussed that what is infrastructure for one person is infrastructure for another person.
... The resolution text for 6694 stands.

Katy: This was a mechanism for operations that do not explicitly appear in the WSDL.

Dave: The red text in the proposal is capturing the cases that are not covered by the resolution to 6694.

Martin: If you have a policy and dialect explicitly defined, there is no clarity.

Bob: That is a separate discussion.
... Does the proposed modification sufficiently addressed 6721?

<paul> I took myself off the queue. I personally don't agree that WSTransfer is purely 100% infrastructure, but that is a side issue

Asir: Let us remove the phrase "While the WS-Transfer operations are not exposed in an endpoint's WSDL" from the red text in the proposal.

<asir> Paul - I don't agree that Transfer is just infrastructure. Bob said it well ... one man's infrastructureis another man's app

<paul> i thought we resolved this on wednesday?

Doug: Use a MUST: "While the WS-Transfer operations MUST not exposed in an endpoint's WSDL"

Dave: This is not core to 6721.
... I am fine with the text as it is. I suggest using a separate issue to revisit or make adjustments to previous resolutions.
... I am not too particularly attached to one particular manifestation.

Martin: I don't like the word 'version'.

Delete "Own verion of the" phrase.

No objections to Martin's change.

Doug: I don't agree that changing the first paragraph should be handled via a separate issue.
... I think it is in the spirit of the earlier resolutions.

Bob: We agreed to the resolution to 6694 irrespective of the various (mis)interpretations.
... If people have an issue with the agreed to text for 6694 let us reopen that issue.
... I suggest that we do NOT elaborate on teh 6694 any further since it is not central to issue 6721.

Asir: The second paragraph in section 7 is not central to 6721.

Bob: Is there any objection to agreeing to just the part below.

Proposed text/extract: "an endpoint MAY choose to expose its own version of the WS-Transfer WSDL by using the following WS-MetadataExchange Dialect URI:"

"http://www.w3.org/2009/02/ws-tra/TransferWSDL"

"This version of the WS-Transfer WSDL can be annotated to indicate any endpoint specific metadata that might be needed by clients interacting with this service. For example, the WSDL MAY have policy assertions to indicate that a particular security mechanism is used to protect the WS-Transfer operations for this endpoint."

Dave: There is need to clarify about dialects.

Doug: One or more WSDL need to be considered.

Bob: Does the above text work for every one?

<Yves> annotating... meaning SAWSDL?

<Bob> s/\/:/

No objections to the amendment from Gil noted above.

Doug to post a new doc with some revisions:

<Wu> how about s/is used to protect /for/ the WS-Transfer ...

<dug> http://www.w3.org/Bugs/Public/attachment.cgi?id=767

<Katy> Hi Yves, please could you unblock 195.212.29.75?

<Yves> done

<Katy> thanks

<Yves> but ask your system people to fix this ;)

<Katy> I will try, something has certainly changed in the last few months

The proposed resolution will appy to all specifications except MEX. Specifically, resolution applies only to Transfer, Enumeration, Eventing specs.

This also applies to MEX.

<Bob> proposal is (i.e. retrievable by using a WS-MetadataExchange GetMetadata with a Dialect URI of http://schemas.xmlsoap.org/wsdl/). An endpoint MAY choose to expose the WS-Transfer WSDL by using the following WS-MetadataExchange Dialect:

<Bob> Dialect URI @Identifier value

<Bob> http://www.w3.org/2009/02/ws-tra/TransferWSDL Not defined

<Bob> The WS-Transfer WSDL can be annotated to indicate any endpoint specific metadata that might be needed by clients interacting with this service. For example, the WSDL MAY have policy assertions that indicate a particular security mechanism used to protect the WS-Transfer operations supported by this endpoint.

<dug> http://www.w3.org/Bugs/Public/attachment.cgi?id=768

The latest modified version of the proposal in above.

No objections to the above proposed resolution.

Issue 6721 is resolved.

RESOLUTION 6721 is represented by comment #6 in bugzilla.

7013

<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0012.html

No objections to closing 7013 with no action.

Resolution 7013 closed with no action.

<dug> http://www.w3.org/Bugs/Public/attachment.cgi?id=762

7207

Concrete proposal is at http://www.w3.org/Bugs/Public/attachment.cgi?id=762

s/concrete proposal/concrete manifestion of proposal/

s/concrete manifestation of proposal/concrete manifestation of resolution/

<Yves> optional but mandatory features looks weird

Bob: Any objections to the concrete manifestation of the resolution?

We will revisit this after lunch.

<dug> eventing: http://www.w3.org/Bugs/Public/attachment.cgi?id=765

We are continuing to look for changes made by the editor relating to correctly describing optional elements/features.

Wu has a question about making fault reason as optional.

Wu is satisfied with the explanation.

<Bob> lunch break will re-start at 1:00

<Katy> Message for those dialing in: The folk here have gone on a quick tour of Hursley site so we will commence a little after 1pm

<Katy> I guess it'll be about 1.20 before we restart

<Katy> (i.e. 23 mins from now in duration time)

<asoldano> ok, thanks Katy

<Bob> we aew slowly gathering...

<Bob> scribe: Gilbert Pilz

<Bob> scribenick: gpilz

Bob: has everyone considered the latest text?
... does anyone need more time?

Asir: it's not very clear what is optional and what is not
... maybe we need to do a little homework before accepting such a global statement

Kary: concern is with optional operations

Asir: suggest we do more homework and be ready to discuss next meeting

<scribe> ACTION: Ram and Katy review latest text for 7207 and determine whether there is any ambiguity [recorded in http://www.w3.org/2009/10/02-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-117 - And Katy review latest text for 7207 and determine whether there is any ambiguity [on Ram Jeyaraman - due 2009-10-09].

7586

Bob: there is a proposed resolution

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

DaveS: describes proposal

<dug> pong test

<Bob> my pong broke ages ago :-)

Martin: seems bloated - having to have 3 time values to specify an expiration

DaveS: "exact" seems to be a minority case

<Bob> yes

Martin: most programming uses exact times - hints etc. are the exception

<Yves> +1 to differentiate hints and non-hints

Gil: would like to flip hint and non-hint syntax

Daves: taking away default values makes the whole thing more complicated
... right now, with a default min=0 and a default max=infinity, things always make sense

Doug: it depends upon your point of view
... for example, what happens if I include a min attribute, but no max attribute

Wu: like this proposal

<Yves> Dave's proposal, using attribute to give multiple non-hints and value for the hint (one target) seems optimal

Wu: if it's difficult to support "any" because of schema, don't do it (no one seemed to care about any)

Ram: I like the proposal

<Bob> Chair notes that a +1 would suffice

<Yves> gil, the client might always trash or not process things that are not getting back within the wanted range

<Yves> (if @min and @max are not supported)

Gil: need faults etc. to handle "wrong" cases

yves: that's just how we got here in the first place . . . we wanted something better than Subscribe, check SubscribeResponse, Unsubscribe

Asir: some question whether empty tag can be specified for "any" case
... all we have to say is 'nillable="true"'

(some discussion about how nillable works, difference between empty tag and xsi:Null

<Yves> nillable optional elements... oh joy :)

Martin: there's a big deal being made about replicating current behavior
... is there agreement about what the current behavior actually is?

Doug: what is the fault for when the three values are hosed?

(all) some sender fault

Doug: we need an exact fault

<asir> For folks who would like to understand how to use nillable and xsi:nil, please see IBM/David Fallside's excellent documentation, http://www.w3.org/TR/xmlschema-0/#Nils

Doug: why nillable is not appropriate

Bob: is anybody speaking against this general approach?

(all): no

Katy: the problem is not with the number of characters, it's the processing involved with comparing three values

<Yves> <Expires @exact=1h>1h</Expires> ?

Katy: we need a shorthand that means "exact"

Yves: it's not checking the number of characters, it's comparing three values

think about 3 xs:dateTimes each with different timezones

<Bob> Yves, Touche

compare all three and figure out if they are the same

<dug> still shorter than a 1 gig xml file

<Yves> gil, see proposal above ot have an @exact as a shorthand for @min @max

<asir> Yep .. XML Schema says that you normalize dateTime and then compare

<asir> ordering is defined in XML Schema

Bob: can we agree to provide a shorthand for exact?

<Katy> How about <Expires @exact>1h</Expires> ?

Wu: seems to make sense

<asir> if you are using a schema library, you don't have to do anything

<MartinC> +katy

<MartinC> +1 to katy

Daves: don't think a shorthand is necessary

Bob: (repeating) can we agree to provide a shorthand for exact?

Ram: Katy, I think your concern is all the extra processing of comparing three values

Katy: it's not a make or break thing

Bob: is it acceptable to leave it as it is

Katy: if no one else cares, I'm willing to bend

Bob: anyone else care?

Doug: I do, I'd like to make the obvious case as easy as possible

<MartinC> revesre it to <expires non-exact> 1hr </expires>

<Yves> so by default you expect that all clocks are synchronized perfectly?

Bob: add the @exact attribute to the proposal - "@exact is shorthand for min, max, and value all being equal"

Yves: no

<Yves> @exact="xsi:boolean"

<Ashok> Default ?

<MartinC> q

suggest wse:InvalidExpirationTime

it already exits in the spec

<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7586#c3

<Ashok> INF is defined in XML Schema

<asir> Yep

If this attribute value is "true" the @min and @max attributes MUST be ignored and the wse:Expires element evaluated as if @min, @max, and the value of wse:Expires had identical values.

<Yves> sounds good

<asoldano> +1

<DaveS> The default value is "false" in which case this attribute has no effect. If this attribute value is "true" both @min and @max attributes MUST be ignored and are assumed to have the same value as the wse:Expires element.

If the wse:Expires element in not present and the event source is not able to grant an indefinite subscription, it MUST generate a wse:ExpirationTimeExceeded fault.

<Ram> +q

this has to go away : If the wse:Expires element in not present and the event source is not able to grant an indefinite subscription, it MUST generate a wse:ExpirationTimeExceeded fault.

<asir> can use the same 'Expires' tag by disallowing min, max and exact attributes in a *Response

<Yves> well why would those occur in a response?

<asir> they won't

<Yves> and at worst if they occur in a response it will be ignored

<Bob> If they occur in a responce, it should be directed at a random w3 server

<Yves> ...and be blocked ;)

<asir> :-)

<DaveS> Need a new response type wse:GrantedExpires

<DaveS> (xs:dateTime | xs:duration)

<DaveS> </wse:GrantedExpires> ?

<DaveS> The value of this element indicates the expiration time (or duration) granted by the event source. If this element is missing the expires time is indefinite.

<Wu> If expir element is missing, min=0, max=inf, expir=inf?

<Wu> In other words, they all take their default value

(all): discuss the use of a new GrantedExpires element in the SubscribeResponse

<Ram> The <GrantedExpires> must have the same schema type definition as the existing <Expires>

Li: would like Event Source to provide policy for min and max supported expiration times

<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7586#c4

Ram: what about Renew operation?
... exact same semantics?

(all): must be identical

<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7586#c5

RESOLUTION: comment #5 resolves 7586 - also applies to Renew
... apply the same resolution to Enumeration

Note: above issue is 7587

Complete notes: 7586 and 7588 were addressed yesterday (action to develop proposal that includes the use of both dateTime and duration)

<Bob> acl li

the above two issues are, in fact, 7478 and 7587

Doug: discusses mixing data types of @min, @max and Expires

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

issue 6407

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

RESOLUTION: 6407 resolved as proposed

note with the standard policy yadda, yadda stuff added

issues 7553, 7554

<Katy> 7553 and 7554 Proposal here http://www.w3.org/Bugs/Public/attachment.cgi?id=769

<Katy> Subscription

<Katy> A registration of interest in receiving Notification messages from an

<Katy> Event Source. Subscriptions may be created, renewed, expired or

<Katy> cancelled.

<Katy> If the subscription is not active, the request MUST fail and the subscription manager MAY generate a wse:UnknownSubscription fault.

<Bob> 7554 was consolidated with 7553

Katy: (explains proposal)

<Katy> Subscription

<Katy> A registration of interest in receiving Notification messages from an

<Katy> Event Source. Subscriptions may be created, renewed, expired or

<Katy> cancelled. A Subscription is active when it has been created but has not been expired or cancelled.

<Katy> If the subscription manager chooses not to renew this subscription, the request MUST fail, and the subscription manager MUST generate a SOAP 1.1 fault or a SOAP 1.2 Receiver fault indicating that the renewal was not accepted.

<li> yes, soap 1.1 fault => soap 1.1 Server fault

<li> soap 1.1 Server == soap 1.2 Receiver

<Katy> The following element MAY be used to convey additional information in the the detail element of a SOAP 1.1 fault or a SOAP 1.2 receiver fault.

Doug: The following element MAY be used to convey additional information in the detail element of a fault.

<Katy> http://www.w3.org/Bugs/Public/attachment.cgi?id=770

Bob: Any objections to resolving 7553, 7554 with above

Wu: Would like more time

Bob: Meeting of 10/06 is cancelled
... Next concall will be 10/13/2009

- DRAFT -

Web Services Resource Access Working Group Teleconference

02 Oct 2009

Attendees

Contents