See also: IRC log
<trackbot> Date: 02 June 2009
<Bob> scribe: Ram Jeyaraman
<Bob> scribenick: Ram
Agenda approved with the addition of a discussion of 6429 and 6401 at the end.
The minutes from last meeting has been updated to reflect late attendees.
<Bob> http://www.w3.org/2002/ws/ra/9/05/2009-05-26.html
RESOLUTION: No objections. The minutes from May 26th, 2009 has been approved.
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.
Team 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.
<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.
RESOLUTION: New issue-6955 is accepted w/o>
RESOLUTION: Issue-6955 resolved as proposed w/o
<asir> Clean bowled!
<Wu> wow, record speed
<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.
RESOLUTION: New Issue-6956 accepted. No objections.
Bob: We will discuss this further on the mailing list.
RESOLUTION: Issue-6975
accepted. No objections.
... Issues-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
RESOLUTION: Issue-6986 is resolved as proposed without objection
<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: 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]
<li> thanks gil
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.
<DaveS> I support unifying the specs.
<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.
RESOLUTION: Issue-6916 is RESOLVED with latest proposal. No objections.
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.
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