See also: IRC log
<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.
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.
Task team progress:
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.
<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.
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.
Also refer to example 5.1.
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
... 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
<DaveS> I support unifying the specs.
<li> must transmit the fault :-)
<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
... 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?
<li> composition vs. geneative approach
<li> wu: composition would support generative
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Wu/Li/ Succeeded: s/Generating/kind of generating/ Found Scribe: Ram Found ScribeNick: Ram Found Scribe: Ram (Microsoft) Scribes: Ram, Ram (Microsoft) WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: Administrivia Ashok_Malhotra Bob Bob_Freund Dave DaveS Doug_Davis Geoff Gil Gilbert JeffM Microsoft P12 P6 Snelling Tom_Rutt Vikas Wu_Chou Yves aabb aacc asir dug gpilz joined li scribenick trackbot ws-ra wu You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jun/0004.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 02 Jun 2009 Guessing minutes URL: http://www.w3.org/2009/06/02-ws-ra-minutes.html People with action items: item WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]