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

<trackbot> Date: 02 June 2009

<dug> on a cell so thing could be screwy

<Bob> scribe: Ram

<Bob> scribenick: Ram

<scribe> Scribe: Ram (Microsoft)

Agenda approved with some changes to issue processing order.

The minutes from last meeting has been updated to reflect late attendees.

<dug> http://www.w3.org/2002/ws/ra/9/05/2009-05-19.html

<Bob> http://www.w3.org/2002/ws/ra/9/05/2009-05-26.html

No objections. The minutes from May 26th, 2009 has been approved.

Administrivia:

F2F is next week. Jeff Mischinsky has provide the logistics to WG email list.

We will work on key issues and close others as well.

Gil: Will look into head count information and do the necessary.

No further discussion on F2F logistics.

Bob will post the link to the logistics email to the Administration site for the WG.

Task team progress:

6401.

Gil has provided an updated proposal.

<dug> +1 to a new closing issue :-)

Gil: We can discuss this at the end of this call.

Wu: I have posted an email responding to Gil's proposal. I am not sure if we can discuss this issue this week.

Bob: I would like to see progress on 6401 since there are a number of issues behind it.
... Please make progress on 6401.

Dependent issues: 6430, 6661

<asir> Probably 6401, 6430 and 6661 are all the same!

Gil: There is a lack of clarity on some use cases in Wu's comment.
... BP says don't do solicit-response MEP.

Next discussion item: Preparation for issues on delivery mode cluster.

Geoff: We will be ready by end of this week.

Bob: How about T/RT merger?

Geoff: Geoff and Doug are working on an assessment/analysis due before end of this week.

<scribe> New issues discussion

6955 (from Geoff Bullen)

<dug> just s/create/manage/ right ?

Geoff: The proposal is to change the description for SubscriptionManager.

The change is just about s/change/create in the description.

<asir> Clean bowled!

The issue is accepted.

No objections.

Issue resolved.

<Wu> wow, record speed

6956 (from

Geoff)

<dug> bob - I'd like more time on this one

Geoff: Ambiguity on what is expected when enumeration context expires and can one tell if the context has expired.
... The state may not be store in the server.
... It is not clear when the enumeration context will expire.
... Section 3.2 needs clarification.

Issue accepted. No objections.

Bob: We will discuss this further on the mailing list.

6975 (from Gil Pilz)

Issue accepted. No objections.

6980 and 6986 are accepted. No objections.

6986 has a proposal.

Doug Davis: WS-Eventing does not define a Topic based filter. Change the specification to use XPATH based filter.

Refer to Example 4.1 line 43 WS-Eventing.

<li> http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Table4

Also refer to example 5.1.

<li> http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Table13

Issue 6986 is resolved.

Discussion on issue 6429.

<Wu> Wow, another good progress on 6986

Wu: This WSDL is defined by Event Source and used by Event Sink.

Dug: The challenge is how to get the separate WSDL (if it is made separate).

Wu: It is OK to close with issue,

Li: This is dependent of 6401.

<asir> we are dialing back in

<dug> LOL its all Geoff's fault - minute that!

Geoff is button challenged!

Apologies accepted :)

Bob: We need a new issue here.

<li> +1 gil

<dug> well, it is in the spec as of now

Bob: This is right now in the WSDL doc.

<DaveS> Snelling back

<dug> zakim who is making noise?

<scribe> ACTION: ITEM to Gil to file a new issue (relating to 6429) to move the wrapped events and put in a separate WSDL. [recorded in http://www.w3.org/2009/06/02-ws-ra-minutes.html#action01]

<trackbot> Sorry, couldn't find user - ITEM

<li> thanks gil

Discussion Issue 6916.

Dug: I have provided a proposal today.

Gil: kind of generating a fault is misleading.
... Generating provides no guarantee what the endpoint does with the generated fault. It is essentially unverifiable.
... No need to transmit the generated fault.

Li: If the server generates a fault but does not transmit a fault what does the client see?

Bob: The service may not transmit a fault if it does not trust the client.

<gpilz> or if there is no mechanism for transmitting the fault

<gpilz> e.g. one-way operation with the HTTP back-channel closed

<dug> +1 any kind of fault isn't ok with security folks - even letting them know that something went wrong is too much info

Dave: What we are trying to say is if a fault is transmitted then a specific fault MUST be transmitted.

Gil: MUST generate a specific fault is sufficient. This is independent of the decision to transmit.

<dug> anyone else hearing static?

<dug> mixing voices?

Yes, there is static.

<dug> oh good, not just me

<li> too much statics

<gpilz> that's not static

Can Dave type in his comment?

<gpilz> that's dropped packets

<dug> LOL

<DaveS> I support unifying the specs.

<li> must transmit the fault :-)

<asir> :-)

<DaveS> I might raise a separate issue tom clean up the ambiguity around "generate" vresus "transmit"

Geoff: There are a couple of other specific cases as well.

In WS-Enumeration section 3.2

what do we do with this? Does this need any clarification?

There is also ambiguity relating to 6956 in the WS-Enumeration specification.

Geoff: I take back my comment. I am fine.

6916 is RESOLVED with latest proposal. No objections.

Issue 6712 discussion.

Dave: The implementation and presentation layer need some close coupling to process this.

Geoff: I gave two examples. It seems to me that a wrapper does the same thing and has the same problems.
... The choice between what is a literal value and what is an instruction is complicated.

<Geoff> that is correct

Bob: HTTP PUT operation does not have any expectation on the content/payload. Why do we need to define the content?

Dug: To me why this is different is because WS-Transfer talks about two things: One is XML representation and the other is the instruction.
... If the WS-Transfer were to remove this distinction, then we don't need this.

<asir> modeled after HTTP

Dug: WS-Transfer does NOT say that it is modeled after HTTP.

Bob: It may be in the charter though.

<DaveS> Interesting note: The iPhone text correction function corrects 'WSRA" to "WARS" :-)

<asir> ws-transfer does not talk about Doug's use case

Dug: There is nothing in the WS-Transfer spec that GET must return a wrapper response.

<Bob> acl gpi

Gil: How can I do anything useful if cannot interpret the XML?\
... How do I interpret the blob?

<dug> Ram - he's saying the opposite - he's saying there _are_ cases where you don't want to interpret it

Gil: We should stay away from defining what the instruction is without any interpretation. We want the service to do the interpreration.

Geoff: It is a very specific use case. A DB client and DB service. The DB service takes a BLOB and stuffs it in the DB.
... There is a tight coupling between the DB client and DB service.
... By creating a dialect we are forcing a service to interpret it.
... How do I know if my BLOB is going to be interpreted or not?
... How does the client know what the service expects?

<asir> just like HTTP!

Geoff: The service is the one that defines the XML representation / instruction.

<asir> Server is in control!

Dug: I am asking for a mechanism for the service to distinguish what the client is sending in.

Dave: We can find a compromise.

<dug> dave - my default was NO ATTRIBUTE

<asir> this is nothing to do with existing impl

Dave: Define a default that is closer to current mechanism.

Bob: Let us pause on this issue and move on to 6401.

Gil: Once i have a dialect, i can know what nofication types are supported.
... By adverstising notification types, it is easy to filter based on notification types.

Geoff: Your proposal has a strong reliance on MEX. Maybe you could placate my concern.
... Do I need to have a running service to issue a MEX call against?

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

<li> composition vs. geneative approach

<li> wu: composition would support generative

- DRAFT -

Web Services Resource Access Working Group Teleconference

02 Jun 2009

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output