IRC log of ws-ra on 2009-03-31

Timestamps are in UTC.

19:28:47 [RRSAgent]
RRSAgent has joined #ws-ra
19:28:47 [RRSAgent]
logging to
19:28:49 [trackbot]
RRSAgent, make logs public
19:28:49 [Zakim]
Zakim has joined #ws-ra
19:28:51 [trackbot]
Zakim, this will be WSRA
19:28:51 [Zakim]
ok, trackbot, I see WS_WSRA()3:30PM already started
19:28:52 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
19:28:52 [trackbot]
Date: 31 March 2009
19:28:53 [Zakim]
19:29:12 [Bob]
zakim, [IB is Dug
19:29:12 [Zakim]
+Dug; got it
19:30:09 [Ashok]
Ashok has joined #ws-ra
19:30:18 [Zakim]
19:30:32 [gpilz]
gpilz has joined #ws-ra
19:30:56 [Katy]
Katy has joined #ws-ra
19:31:11 [Zakim]
19:31:31 [Bob]
19:32:00 [Zakim]
19:32:19 [Bob]
zakim, [Micro is Asir
19:32:23 [Zakim]
+Asir; got it
19:32:29 [dug]
Gil - I just +1'd your idea for Mode attribute - I think that's a good compromise.
19:32:29 [Zakim]
19:32:34 [Bob]
zakim, asir has ram
19:32:34 [Zakim]
+ram; got it
19:32:50 [Bob]
zakim ??P14 is katy
19:32:51 [Ram]
Ram has joined #ws-ra
19:32:59 [Zakim]
19:33:02 [Zakim]
19:33:03 [Bob]
zakim, ??P14 is katy
19:33:03 [Zakim]
+katy; got it
19:33:16 [Zakim]
19:33:18 [asir]
asir has joined #ws-ra
19:34:58 [DaveS]
DaveS has joined #ws-ra
19:34:59 [asir]
Scribe: Asir S Vedamuthu
19:35:09 [asir]
19:35:14 [Bob]
Roll 15 folks on the call
19:35:19 [asir]
Chair: Bob Freund
19:35:53 [Zakim]
19:36:02 [Zakim]
19:36:02 [SUmeet]
SUmeet has joined #ws-ra
19:36:11 [asir]
dialing back in
19:36:19 [asir]
pressed the wrong button
19:36:31 [Zakim]
19:36:41 [Zakim]
19:36:44 [asir]
19:37:03 [asir]
Topic: Opening
19:37:07 [Vikas]
Vikas has joined #ws-ra
19:37:16 [asir]
Resolution: unanimously approved the minute from March 24th
19:37:36 [asir]
Minutes are at
19:37:59 [asir]
Bob: describing the * | # | X notation
19:38:33 [asir]
Topic: Acceptance of New Issues
19:38:44 [asir]
Bob - can you type the list?
19:38:58 [Bob]
New issue 6739
19:39:50 [asir]
6739 accepted
19:40:02 [asir]
Assigned to Dug
19:40:55 [asir]
Infoset issues - WG wanted to review infoset notation for all specs prioring to adoption
19:41:36 [asir]
Bob: looking for owners
19:48:10 [li]
19:48:16 [Ram]
19:48:21 [Bob]
19:48:24 [DaveS]
19:48:27 [fmaciel]
19:51:10 [Bob]
scribenick: Gil
19:51:11 [gpilz]
Scribe: gpilz
19:51:13 [asir]
asir has joined #ws-ra
19:51:16 [asir]
am back
19:51:28 [asir]
let me dump the missing buffer
19:51:29 [asir]
<asir> Bob: looking for owners
19:51:30 [asir]
<asir> No owners ... these issues are in the "wanted drivers" lot
19:51:30 [asir]
<asir> Resolution: accepted issue 6739
19:51:30 [asir]
<asir> Topic: New Snapshots and WD time?
19:51:30 [asir]
<asir> Bob: time to create a snapshot
19:51:31 [asir]
<asir> Bob: Yves is not on the call. Editors do not touch the drafts
19:51:31 [Bob]
scribenick: gpilz
19:51:33 [asir]
<asir> Bob: plans to create a snapshot
19:51:34 [asir]
<asir> ... goal is review the incorporation of resolved issues
19:51:36 [asir]
<asir> q+
19:51:39 [asir]
<asir> s/is review/is to review/
19:51:40 [asir]
<asir> ... send your review comments to the WG mailing list
19:52:07 [asir]
19:52:09 [gpilz]
topic: 6730
19:52:18 [Bob]
ack asir
19:52:30 [gpilz]
aisr: will diffs be provided as part of the snapshots?
19:52:51 [gpilz]
dug: I can tag the CVS tree, Yves could produce diffs
19:53:07 [gpilz]
19:53:42 [Ram]
19:53:56 [dug]
create a tag called "WD-2008-03-31"
19:54:14 [Bob]
ack ram
19:54:16 [gpilz]
dave: at the time this was written this redundant text may have been necessary
19:54:28 [gpilz]
...: but, at this time, everyone knows how this works
19:54:41 [gpilz]
ram: spec has to define what base behavior is
19:54:52 [gpilz]
...: extensibility behavior should be defined
19:55:08 [Katy]
19:55:40 [gpilz]
ashok: are we asking to remove all occurences of this text?
19:55:45 [Bob]
ack katy
19:55:47 [gpilz]
dave: remove it in all places
19:55:49 [dug]
19:56:03 [asir]
cant hear Katy
19:56:17 [gpilz]
katy: if we are going to have this extensibility behavior specified, do we need to have it restated over and over?
19:56:25 [gpilz]
...: seems to make more sense just to state it once
19:56:29 [Bob]
ack dug
19:56:44 [gpilz]
dug: I see Dave's point; even saying it once is redundant
19:56:58 [Katy]
19:57:02 [gpilz]
...: we've already defined how extenisbility points must work across all specs
19:57:03 [asir]
19:57:10 [gpilz]
...: why is WS-Transfer special?
19:57:15 [Bob]
ack katy
19:57:22 [gpilz]
Bob: is it true that none of the other specs have this language?
19:57:24 [gpilz]
dug: yes
19:57:40 [gpilz]
katy: don't want to do this unless it is specified across all specs
19:57:47 [Bob]
ack asir
19:58:21 [gpilz]
asir: this outlines how to extend the transfer operations using the SOAP processing model
19:58:32 [gpilz]
...: we may need to refactor
19:58:39 [gpilz]
Bob: how strong is your objection?
19:58:48 [gpilz]
asir: I don't understand why we are removing this
19:58:57 [asir]
repetition should be refactored
19:59:11 [gpilz]
DaveS: the offensive text is repeating stuff that is already specified in the SOAP processing model
19:59:19 [asir]
am not aware of anything hidden
19:59:31 [gpilz]
...: readers may wonder why we are re-stating this? is there some special wierdness that they are missing?
19:59:47 [asir]
the important aspects are - use SOAP Processing Model and MUST NOT change teh base behavior
19:59:47 [gpilz]
...: it is worse than just being rendundant
20:00:00 [gpilz]
...: it is phrased slightly differently, which is bound to create confusion
20:00:09 [gpilz]
...: and possibly interoperability problems
20:00:13 [asir]
Circumvention is not the intent
20:00:16 [dug]
+1 to dave - it will confuse people - they'll wonder why we're repeating it - usually that's because something is different and that's not the case.
20:00:25 [gpilz]
...: may lead readers to the belief that WS-T is circumventing normal SOAP processing rules
20:00:31 [Ram]
20:00:40 [Bob]
ack ram
20:00:50 [gpilz]
Bob: in the legal world, if you restate something that is already stated, you do so to draw attention to a special distinction
20:01:10 [DaveS]
20:01:32 [gpilz]
Ram: (agrees that there is a sense of redundancy and some repitition)
20:01:39 [gpilz]
...: perhaps we could re-factor?
20:01:41 [gpilz]
20:01:43 [dug]
we already have an extensibility section
20:02:08 [dug]
section 2.4 of WST already has this info
20:02:17 [dug]
20:02:18 [asir]
not all
20:02:29 [Bob]
ack dave
20:02:31 [asir]
That section does not capture all bits
20:02:38 [Zakim]
- +0120756aabb
20:02:51 [gpilz]
Doug: we talked about this on last weeks phone call - we added a section on extensibility to all the specs
20:03:10 [gpilz]
DaveS: we need to outline where the extensibility points are
20:03:23 [gpilz]
...: but there is already a section on extensibility (added last week)
20:03:33 [Bob]
ack gp
20:03:52 [asir]
20:03:54 [gpilz]
Bob: we already have sections on extensibility in every spec
20:03:59 [Bob]
ack asir
20:04:03 [gpilz]
...: given that, how do people feel?
20:04:10 [gpilz]
Ashok: I'm ok with it
20:04:18 [gpilz]
asir: what is going to be removed?
20:04:25 [gpilz]
DaveS: the exact text that is quoted
20:04:42 [gpilz]
asir: I'm not sure about that
20:04:53 [gpilz]
Ashok: he has the exact paragraph that he intends to take out
20:05:16 [gpilz]
asir: I think there might be one or two words that are differnt in each paragraph
20:05:37 [gpilz]
DaveS: you can clearly see which paragraphs are copies
20:05:50 [gpilz]
dug: speaking as an editor, it is really obvious
20:06:01 [gpilz]
asir: it is not the same text, so I don't know
20:06:12 [gpilz]
dug: I'm pretty sure the editors can figure it out
20:06:17 [gpilz]
Bob: so where do we stand?
20:06:38 [gpilz]
asir: I propose that Dave provide us a detailed list of which paragraphs will be dropped
20:06:46 [gpilz]
DaveS: have that by the end of the call
20:07:13 [gpilz]
topic: 6499
20:07:33 [gpilz]
20:07:49 [gpilz]
dug: define an action URI for WS-Enum specifically
20:08:00 [gpilz]
...: WS-Enum is the only section that inlines fault definitions
20:08:11 [gpilz]
...: move these to a common section like all other specs
20:08:16 [gpilz]
Bob: any questions?
20:08:27 [gpilz]
Ashok: This would bring all 5 specs inline?
20:08:35 [gpilz]
dug: w/respect to how faults are defined, yes
20:08:40 [gpilz]
Ashok: excellent
20:08:44 [asir]
20:08:46 [dug]
and they rejoiced!
20:08:51 [gpilz]
Bob: any objections to accepting
20:09:07 [gpilz]
resolved: proposal to 6499 accepted by UC
20:09:13 [gpilz]
topic: 6413
20:09:22 [gpilz]
20:09:45 [gpilz]
Bob: I need to make sure that the text for all our proposals need to be on the W3C website
20:10:05 [gpilz]
...: I've copied the refernced material onto the W3C website
20:10:27 [gpilz]
Katy: (go back to March F2F) merge WS-T and WS-RT
20:10:33 [Bob]
proposal at
20:10:46 [gpilz]
...: key concern was what would be included etc.
20:11:01 [gpilz]
...: we took an AI to create a new proposal that just included the base WS-RT support in WS-T
20:11:20 [gpilz]
...: Doug, Dave, and I worked this and came up with the above proposal
20:12:02 [gpilz]
...: (describes proposal)
20:12:32 [Katy]
This OPTIONAL attribute, when present, indicates the dialect to be used in order to process the child element(s) of the wst:Get and the format of the wst:GetResponse element that is returned. This specification defines a standard dialect in Appendix A. Other dialects may be defined by other specifications.
20:12:32 [Katy]
A resource MUST generate a wst:UnsupportedDialectFault if it does not support the specified dialect.
20:12:32 [Katy]
When this attribute is not present, child elements of the wst:Get MUST be ignored.
20:17:57 [gpilz]
dug: the addition of the dialect attribute on the 4 operations, aside from the fragment support, is a good thing for WS-T
20:18:27 [gpilz]
...: a dialect attribute helps to disambiguate some situations that are ambigious in WS-T
20:18:48 [gpilz]
...: e.g. "actual representation" versus "template constructor"
20:18:52 [asir]
20:19:00 [gpilz]
Bob: comments, reactions?
20:19:04 [Bob]
ack asir
20:19:28 [gpilz]
asir: would like to walk through our objections (posted on email)
20:19:38 [gpilz]
asire: (walks through objections)
20:19:58 [dug]
HTTP has no influence on this WG. Neither the charter nor the Transfer specification mentions HTTP at all.
20:20:21 [gpilz]
20:20:22 [dug]
please stay within scope of the WG
20:20:59 [gpilz]
20:21:38 [Bob]
fir example this one
20:22:47 [Bob]
20:23:06 [Katy]
20:25:59 [gpilz]
Bob: anything that isn't implented by CR will get dropped
20:26:12 [gpilz]
asir: these things will end up "at risk"
20:26:54 [gpilz]
...: we found that some WS-RT features are unclear, broken, dangerous and harmful
20:27:06 [dug]
I don't recall what Asir said
20:27:15 [gpilz]
...: we don't recall asking for another proposal
20:27:29 [Bob]
Asir, pontification and repetition of history is not necessary
20:27:34 [gpilz]
...: this one seems to drop the controversial (???) feature
20:28:12 [Bob]
pontification is my relm
20:28:18 [gpilz]
...: it seems to add a new processing model based on attribute values instead of the standard SOAP processing model which is based on headers
20:28:27 [dug]
but repeating (your own version of) history allows for more time to be wasted
20:28:50 [gpilz]
...: looking back at the F2F, it appears to us we need to (a) fix inconsistencies between WS-T and WS-RT
20:29:03 [gpilz]
...: (b) don't endanger the "sweet spot"
20:29:09 [gpilz]
...: (c) wider update?
20:29:34 [gpilz]
...: we need to continue to explore and invent partial updat features that compose well with WS-T
20:29:39 [gpilz]
...: we need to do this right
20:29:43 [gpilz]
...: fix isssues
20:29:52 [gpilz]
...: do not endanger the sweet spot
20:29:58 [gpilz]
...: do things right
20:30:06 [Bob]
ack katy
20:30:19 [Ashok]
20:30:27 [gpilz]
Katy: on the concerns that Asir has raised: these concerns were raised and acknowledged
20:30:39 [gpilz]
...: we've gone to great lengths to address them
20:30:44 [asir]
20:30:55 [gpilz]
...: the fragment level support is optional and should not impact those that do not wish to support them
20:31:34 [gpilz]
...: huge parts of WS-RT are not in this proposal; none of the metadata, none of the qnames, none of the (??) dialect (i.e. the simplest dialect is the only one that has been pulled in)
20:31:48 [gpilz]
...: want to re-emphasize that this is an optional feature
20:31:50 [Bob]
ack ashok
20:32:01 [gpilz]
Ashok: Asir, you quoted an IETF draft?
20:32:07 [gpilz]
Bob: that was me
20:32:17 [gpilz]
...: Asire mentions "PATCH"
20:32:31 [gpilz]
...: that is a reference to the current draft for PATCH
20:32:45 [gpilz]
asir: (history of PATCH) no uptake on this
20:32:57 [gpilz]
...: recently it seems like the Atom community would like this feature
20:33:12 [dug]
But clearly there is "uptake" for fragment support in the WS* space since wsman and ws-fed use it
20:33:13 [gpilz]
...: I provided a lot of references on this
20:33:26 [gpilz]
asir: Katy said she addressed all the issues
20:33:29 [Wu]
Wu has joined #ws-ra
20:33:34 [Bob]
ack asir
20:33:38 [gpilz]
...: one issue was addressed (the controversial boxcarring)
20:33:49 [gpilz]
...: a merger is a merger and we don't understand why we need a merger
20:34:10 [gpilz]
...: it has consequences and impacts other communities and we need to consult with those communities
20:34:21 [gpilz]
Bob: we've heard one side w/regards to reservations
20:34:32 [gpilz]
...: is there someone willing to speak on the benefits
20:34:44 [gpilz]
dug: two aspects
20:35:01 [gpilz]
...: (1) the definition of a dialect - generally useful for WS-T
20:35:04 [asir]
20:35:16 [gpilz]
...: fragment support is a widely used feature in WS-MAN, etc.
20:35:30 [Wu]
20:35:40 [gpilz]
...: we need to provide guidance to the community on how to do this or we will end up with lots of different ways
20:35:45 [gpilz]
...: that would hurt interop
20:35:50 [DaveS]
20:35:58 [gpilz]
...: we want a single solution that is shared across domains
20:36:07 [gpilz]
...: not domain-sepific solutions
20:36:33 [gpilz]
Bob: if, at the end of this process, there isn't the proper number of impls
20:36:41 [gpilz]
...: this feature will be marked "at risk"
20:37:03 [gpilz]
...: this is true regardless of whether these features are part of a separate spec (WS-RT) or in WS-T
20:37:15 [gpilz]
DaveS: does the same thing apply to optional features?
20:37:17 [gpilz]
Bob: yes
20:37:29 [gpilz]
...: even if a feature is optional, we need to prove interop
20:37:41 [Bob]
ack asir
20:37:48 [gpilz]
asir: that's an important point (interop or "at risk")
20:37:59 [gpilz]
...: none of the benefits result from merging
20:38:07 [gpilz]
...: they still have value
20:38:09 [gpilz]
20:38:12 [dug]
not true - we lose the linking of the features
20:38:16 [gpilz]
20:38:38 [gpilz]
Bob: are you saying the dialect feature could be added regardless of frag support?
20:38:46 [gpilz]
asir: yes, that could be in a separate spec
20:38:57 [Bob]
ack wu
20:39:10 [gpilz]
Wu: I remember during the F2F meeting at Raleigh, this issue was discussed
20:39:25 [gpilz]
...: I saw a proposal that I thought was very good - we don't want to merge at this point
20:39:39 [gpilz]
...: develop each as a separate spec, and see if we want to merge at the end
20:40:18 [gpilz]
...: the important thing is to develop WS-T and WS-RT
20:40:36 [Bob]
ack dave
20:40:37 [gpilz]
DaveS: value of including frag support in the main spec
20:40:58 [gpilz]
...: within the community there are a lot of different approaches to doing fragments at various levels in the stack
20:41:05 [gpilz]
...: this is about demonstrating leadership
20:41:06 [asir]
20:41:24 [gpilz]
...: if we leave this out that leaves the ws community w/out guidance
20:41:42 [gpilz]
...: the proposal here is very conistent with ws architecture w/respect to identify a resource
20:41:52 [gpilz]
...: (no reference parameters, etc.)
20:42:27 [gpilz]
...: demonstrate leadership, uniform frag support, don't worry about implementations (they will come)
20:42:41 [gpilz]
asir: leadership is not a function of merging
20:42:59 [gpilz]
...: people will take our leadership seriously
20:43:07 [gpilz]
...: leadership is not a function of merge
20:43:17 [gpilz]
..: leadership is not a function of merge
20:43:34 [gpilz]
Bob: let's take a straw poll on the essence of the proposal
20:43:52 [asir]
Yves is not here to represetn w3c
20:43:56 [gpilz]
...: everyone clear?
20:44:04 [gpilz]
...: "yes" is "in favor of"
20:44:06 [Wu]
20:44:14 [gpilz]
...: "no" is "not in favor of"
20:44:15 [asir]
20:44:16 [Bob]
ack wu
20:44:27 [gpilz]
Wu: it is very hard for us to make decisions
20:44:35 [gpilz]
...: because we don't know the consequences
20:44:56 [gpilz]
20:45:21 [gpilz]
20:45:31 [gpilz]
Bob: everyone clear?
20:45:38 [asir]
Yves is not here to represent W3c
20:46:00 [gpilz]
Oracle - yes
20:46:08 [gpilz]
Microsoft - no
20:46:10 [gpilz]
IBM - yes
20:46:20 [gpilz]
Fujitsu - yes
20:46:25 [gpilz]
SoftwareAG - yes
20:46:46 [fmaciel]
20:47:13 [gpilz]
Avaya - abstain
20:47:23 [Zakim]
20:47:35 [gpilz]
SoftwareAG - yes
20:48:15 [gpilz]
Bob: one 'no', a bunch of 'yesses' and one 'need more time'
20:48:16 [asir]
Yves is not here
20:48:21 [gpilz]
...: Wu, would one week do?
20:48:44 [asir]
am very concerned about how we build consensus
20:48:46 [gpilz]
Wu: two weeks would be great
20:48:56 [DaveS]
20:49:01 [gpilz]
Bob: we'll give Avaya two weeks
20:49:09 [Wu]
20:49:14 [gpilz]
...: in the meantime, maybe we can move closer to consensus
20:49:20 [Bob]
ack asir
20:49:25 [gpilz]
asir: it's too late
20:49:29 [Zakim]
20:49:34 [gpilz]
...: I wanted to mentioned that yves is not here
20:49:42 [gpilz]
...: we don't seem to be building consensus
20:49:44 [Bob]
ack dave
20:49:55 [gpilz]
DaveS: point of order - I've posted an update to our previous issue
20:49:57 [gpilz]
20:50:04 [Bob]
ack wu
20:50:19 [gpilz]
Wu: I would also hope that IBM and Microsoft could communicate on this issue - that would help us
20:50:23 [Zakim]
20:50:39 [gpilz]
topic: 6730
20:51:37 [gpilz]\
20:51:44 [gpilz]
20:52:06 [gpilz]
DaveS: (describes update)
20:52:23 [Ram]
20:52:26 [gpilz]
...: the text to be removed is definitely redundant
20:52:36 [gpilz]
Ram: thanks to Dave Snelling
20:52:39 [gpilz]
...: it looks fine
20:52:41 [Bob]
ack ram
20:52:46 [gpilz]
...: I have one question
20:53:03 [gpilz]
...: Section 2.4 of the editors copy talks about extension points
20:53:18 [gpilz]
...: I was wondering if this notion of extension points has been identified in WS-T
20:53:30 [gpilz]
DaveS: this issue was solved a couple of calls ago
20:53:38 [dug]
xs:any and ... are the extension points
20:53:44 [gpilz]
...: all specs call out what their extension points are
20:53:57 [gpilz]
Ram: have the extension points for WS-T be described?
20:54:06 [gpilz]
...: I'm fine with Section 2.4
20:54:17 [gpilz]
...: but I'm worried about extension points
20:54:30 [gpilz]
...: I'd like to look at the proposal and reply by email
20:54:42 [gpilz]
Bob: we don't usually decide things by email, would you like more time?
20:54:49 [gpilz]
Ram: can we wait a couple of days?
20:54:57 [gpilz]
DaveS: it's a simple thing
20:55:04 [gpilz]
(other): concur
20:55:12 [Ram]
20:55:27 [gpilz]
Bob: I recognize that some folks may need to talk to the mother ship, but this issue has been kicking around a while
20:55:38 [Bob]
ack ram
20:55:42 [gpilz]
Ram: it is generally good to have a concrete proposal a couple of days before the call
20:55:49 [gpilz]
DaveS: the original proposal was precise
20:55:58 [Ram]
20:55:59 [gpilz]
...: people just called on more precision for this call
20:56:05 [gpilz]
asir: can we have a week
20:56:15 [gpilz]
Bob: yes, but any more time is going above and beyond
20:56:17 [Bob]
ack ram
20:56:27 [DaveS]
20:56:39 [gpilz]
20:56:58 [Bob]
ack ram
20:57:18 [gpilz]
DaveS: could people actually talk to their product people?
20:57:48 [gpilz]
...: because it seems unlikely that anyone asked their product people about the previous incarnation
20:57:58 [Bob]
20:58:03 [gpilz]
dug: if people need more detail, they should say so before the concall
20:58:19 [gpilz]
...: not wait until the day of the concall to say they need more detail
20:58:37 [gpilz]
Bob: people should look at the issues with proposals and be prepared to discuss them
20:58:53 [gpilz]
...: it seems that people are capable of using the email list to discuss proposals
20:59:12 [gpilz]
...: when I don't see any debate, I get the feeling that people are in general agreement
21:00:48 [Zakim]
21:00:49 [Zakim]
21:00:50 [Zakim]
21:00:51 [Zakim]
21:00:53 [Zakim]
21:00:56 [Zakim]
21:01:02 [Zakim]
21:01:03 [Zakim]
21:01:10 [Zakim]
21:01:31 [Bob]
rrsagent, make logs public
21:01:49 [Zakim]
- +1.212.642.aaaa
21:01:51 [Zakim]
WS_WSRA()3:30PM has ended
21:01:53 [Zakim]
Attendees were +1.212.642.aaaa, +0120756aabb, Tom_Rutt, Bob_Freund, [IBM], Dug, fmaciel, Gilbert, [Microsoft], ram, Vikas, Ashok_Malhotra, katy
21:02:16 [Bob]
rrsagent, generate minutes
21:02:16 [RRSAgent]
I have made the request to generate Bob
22:42:29 [gpilz1]
gpilz1 has joined #ws-ra
22:42:40 [gpilz1]
gpilz1 has left #ws-ra
23:18:45 [asir]
asir has joined #ws-ra