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

<trackbot> Date: 01 October 2009

<Bob> still waiting for folks to show up in Hursley...

<asoldano> Bob, ok, I hang up, re-dialing once you're ready in Hursley

<Bob> we are dialing

<Bob> waiting for the scribe...

<Bob> folks are struggling with internet issues here

<Bob> scribe: Jeff Mischkinsky

<Bob> scribenick: Jeffm

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

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

new issue 7770

<scribe> new issue accepted

RESOLUTION: resolved as proposed

new issue 7774

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

<scribe> new issue accepted

doug: wants a more complete proposal

needs more discussion

and more extensive proposal

Issue-7426 IRI or URI http://www.w3.org/Bugs/Public/show_bug.cgi?id=7426

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

<Yves> http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/att-0103/uri-to-iri.txt

proposal at

http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0103.html

bob asks if any objection to accepting the proposal in 103

RESOLUTION: resolved 7426 by adopting proposal

in msg 2009Sep/0103.html

Issue-7588 Enumeration: Expires multiple data types creates interop

issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=7588 -Pilz

problem is same for eventing and enumeration

gil proposes using duration across the board

gil: makes things simpler
... can be confusion as to what time it is on various systems when using datetime

dave: supports gil's proposal -- impl experience his group had led them to using duration

<asoldano> I'm in favor of the proposal too

dave: if we have to go back to datetime, we have to mandate utc (or some specific timezone)

ram: should require the use of duration

<Yves> non tz-qualified time are indeed a huge source of interop issue

ram: datetime useful when the devices one is talking to know what they are doing, so leave it as optional
... use policy to indicate datetime support

dug: if we keep dt, need to have to use tz
... torn on the topic - use case - i want a subscription until midnite tomorrow
... time on the source
... not sure if we absolutely have to support the use case, but we should be aware that we will not be able to support it w/ duration only

bob: who specifies the tz- the client or server

dug: always use the source's tz

<MartinC> q

martin: in business env dt tends to be used more than duration - e.g. some "business event" finished by 11 pm
... regardless there are clock synch issues - no way to know how long msg delivery takes

gil: if u specifiy a duration of 1 hour, and 2 hours u get a response back, u know things are screwed up

martin: no reason to exclude dt

no objection that duration should be required

gil objects to support of dt, even as optional

jeff: suggests that if dt is supported then it must be unambiguously specified

katy: you might be in a closed system where u "know"

Directional Resolution: 1. implementation of duration is mandatory. 2. impl of dt is optional, 3. dt specified must be unambigous 4, must be policy mechanism to say if dt is supported

discussion on various ways to make the dt unambig - will be hashed out as part of the proposal

consensus is we don't want to get into clock synchronization issues

ram: why do we need to resolve the ambiguity, given that this is optional

gil: get interop problem if u don't make it unambig

bob: it is up to the source (the source

(the source's clock) to determine expirty

expirey

bob: an unambig dt must include the date, time AND tz

dave: discussion makes my case for why we shouldn't do dt -- been down this rathole

<scribe> ACTION: pilz to produce concrete proposal based on direction for issue 7588 [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-113 - Produce concrete proposal based on direction for issue 7588 [on Gilbert Pilz - due 2009-10-08].

ssue-7553 Eventing: GetStatus Fault messages http://www.w3.org/Bugs/Public/show_bug.cgi?id=7553

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

<Katy> my ip

<dug> test

<Katy> 195.212.29.83

<Yves> that ip is not blacklisted on our side

gil: don't want to require remembering state of expired subscriptions

<dug> email from katy: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Sep/0066.html

<Zakim> asir, you wanted to ask a question

ram: katy's proposal is scoped to the case hwere the subscription mgr is still alive

martin: if subscription mgr is not avail, then can't tell anything :-)

ram: if the subscription has expired or been deleted, then the subscription mgr for that subscription may not be alive

<dug> If the subscription manager is exists but the subscription is not valid, the request MUST fail....

<asir> what does it mean to say not valid

<asir> suggest 'unknown'

<dug> If the subscription manager exists but the subscription is not valid, the request MUST fail and the subscription manager MUST generate a wse:InvalidSubscription fault.

<dug> If the subscription manager exists and the subscription is not valid, the request MUST fail and the subscription manager MUST generate awse:InvalidSubscript ion fault.

<asir> suggest replacing not valid with unknown

<dug> If the subscription manager exists and the subscription is not valid, the request MUST fail and the subscription manager MUST generate a wse:InvalidSubscription fault.

<asir> If the subscription manager exists and the subscription does not exists, the request MUST fail and the subscription manager MUST generate awse:SubcriptionDoesNotExist fault

discussion evolves into what are the states of subscription

martin: there are really 3 states - expired, unknown, deleted (unsubscribed)

more discussion about existential existence (as opposed to existetial non-existence ;-) of deleted subscriptions

katy: need a state diagram

martin: if a getstatus(subscription) is done -- if you have no history, a fault is generated,
... if you have a history, and its been deleted, then you don't generate a fault, you return the proper status

<DaveS> Satae suggestion:

<DaveS> Valid:

<DaveS> �� - Created

<DaveS> �� - Renewed

<DaveS> Notvalid

<DaveS> �� - Expired

<DaveS> �� - Cancelled or deleted

<DaveS> �� - Unkonwn

martin: only one fault - unknown subscription - everything else is a known state

<Ram> How about we change "Valid" to "Active" and "Invalid" to "Inactive".

wu: have a generic fault with sub-fault codes that reflect the state
... sub-fault codes are optional

<DaveS> Status with Ram's suggestion:

<DaveS> Active:

<DaveS> �� - Created

<DaveS> �� - Renewed

<DaveS> Inactive:

<DaveS> �� - Expired

<DaveS> �� - Cancelled or deleted

<DaveS> �� - Unknown

<DaveS> GetStatus never faults.

katy: agrees with martin

ram: we need to define the "structure" of the get status returns

dave: need a form of status which doesn't fault

i'm not +1'ing

asir: expired and deleted are internal states of the event source
... how can this be tested?

jeff: what we are really talking about is whether a "bad" subscription faults from get status
... or it always returns "normally", with a substatus

bob: dave's proposal is unless there is some internal disaster, get status always returns normally
... major status returned are "usable"/"unusable", or active/nonactive
... try again -- 2 major "uber status": active/unactive and then there is detail info which further elaborates

discussion ensues -- on what is the difference between not knowing of a particular subscription and knowing that it existed in the past and has been expired/deleted

<asir> confused is a possible state as well :-)

<dug> its a perpetual state

<asir> :-)

bob: should server fault with a bad subscription? 2
... should server not fault , but would return as a status "unknwon subscription"

redo

confusion reigns

bob: if a subscription which is the subject of a get status op is not known (for whatever reason) should the operation a)fault or b)return info?

<Yves> to me a) and b) are fine... it's basically a style issue. However we should be consistent across specs when we encounter that kind of case

<Yves> chad?

<Bob> thanks, Yves

ram: at highest level - is the subscription manager present - if it is not, then all bets are off (outside of the scope of the WG)
... question is what to do when the sub mgr is present
... a)fault b)send direct response saying deleted, expired, unknown
... when you do a Transfer.get you don't get a fault (ignoring low level protocol faults), you get back a repsonse

martin: conflating sub mgr and the subscription

<asir> Doug => resource does not exist == subscription manager does not exist

<dug> not necessarily for all impls - to some a non-existent subscription could still point to a sub mgr

<asir> That is true from a subscription point of view

martin: if get_status request gets to the subscription mgr, by definition the subscription is not unknown (otherwise it wouldn't have got to the subscription mgr)

<asir> but from a endpoint point of view, resource does not exist == subscription manager does not exist

bob, dave: no you won't -- there is not necessarily a 1-1 between sub mgr and subscription

<dug> nope

<asir> why?

<dug> there could be on subscription mgr for a ton of subscriptions

<asir> no disagreements on that piont

<dug> Dug: I'd like to discuss the state tables first

bob: martin raises the issue of the existence of the thing we are trying to query
... in other words what is the window of existence?

After a long discussion, we may agree on the following:

bob: there is only one active state for a subscription
... Before that active state exists, the renew req, get_status req, unsubscribe req must fail and may generate the invalid subscription fault.

katy: need definition of subscription in the spec

bob: need to tidy the language in get_status operation that seems to indicate that there is a distinction between invalid and expired (i.e. collapse them)

<scribe> ACTION: katy to produce a redline proposal consistent with the above principles [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action02]

<trackbot> Created ACTION-114 - Produce a redline proposal consistent with the above principles [on Katy Warr - due 2009-10-08].

reconvene in 1 hour and 5 minutes

<Bob> we resume...

<Bob> scribe: Katy Warr

<Bob> scribenick: Katy

Issue-7554 Eventing: Unsubscribe Fault http://www.w3.org/Bugs/Public/show_bug.cgi?id=7554

<Bob> -

Katy: This may require updates based on discussions this morning

Martin: Why would this be any different from any other WSDL fault why not return SOAP receiver fault
... This is a generic fault

Asir: Why would we need EventSourceUnableToProcess

Katy: This is already in the spec but specific to Subscribe
... ... it has Retryafter detail

Asir: But Soap receiver fault indicates that you can retry any time after

<li> are we discussing 7554?

Martin: Should only ave faults for aspects specific to eventing

li - yes

Ram: Invalid receiver fault is when the fault is not due to the content of the message

DaveS: Non Soap fault would be useful for additional info too

Doug: Like REtryAfter

<dug> yves - I'm blocked: 195.212.29.75

Li: Can we use info set with SOAP 1.1?

Asir: Is this a more general concern regarding the use of eventing with soap 1.1?

<asir> Receiver The message could not be processed for reasons attributable to the processing of the message rather than to the contents of the message itself. For example, processing could include communicating with an upstream SOAP node, which did not respond. The message could succeed if resent at a later point in time (see also 5.4 SOAP Fault for a description of the SOAP fault detail sub-element).

<dug> yves??

The question is: Do we ned the SubCode of the EventSourceUnableToProcess

<dug> I'm being blocked: 195.212.29.75

Katy: Do we need the RetryAfter?

<dug> working now

Bob: I think we can use the generic fault

DaveS: Need to step through faults

<Yves> this ip is not blocked

<dug> just started to work

InvalidExpirationTime: Keep (don't replace with generic)

<dug> who is that?

<Yves> you at the office; 0

UnsupportedExpirationTime: Keep

FilteringNotSupported: Keep

<Yves> so most probably a proxy

<dug> no - at IBM hursley

FilteringRequestedUnavailable: Keep

SubscribeRequestInvalid: ?

Martin: What's invalid, if you can't be precise, don't keep it
... This is a candidate for removal I think

EventSourceUnableToProcess: Definitely goes - generic soap fault

UnableToRenew: ?

DaveS: I htink this is the same as EventSourceUnableToProcess so should have same action
... again question is is there genuine value in retry after?

Martin: Can put that in the generic fault

INvalidMessage: Generic SOAP fault

DeliveryFormatRequestUnavailable: Keep

Asir: InvalidMessage adds some value

Doug: This message is not referenced from the spec
... It may have been moved or be added as a generic message

DaveS: InvalidMessage should go

DeliveryFormatRequestUnavailable and EmptyFilter: Keep

Doug: UnusableEPR is is the EndTo contains something like FTP that's not supported

Ram: Should retain UnusableEPR

Doug: InvalidSubscription should probably be renamed as Unknown as part of 7554

General agreement to this.

<asir> Consensus: s/InvalidSubscription/UnknownSubscription/

<asir> Consensus: s/InvalidSubscription/UnknownSubscription/g

<asir> Summary:

<asir> a) s/InvalidSubscription/UnknownSubscription/g

<asir> b) s/InvalidMessage//

<asir> c) s/EventSourceUnableToProcess//

<asir> d) s/UnableToRenew//

RESOLUTION: Combine the above discussion with the 7553. SubscribeRequestInvalid, EventSourceUnableToProcess, UnableToRenew, InvalidMessage become genericsoap fauls
... InvalidSubscription renamed as above

Doug: Should make it clear where to put the retry in the generic fault - i.e. that it can be used in the detail space

RESOLUTION: Agree above

<dug> yves - I'm blocked again

Issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=7586

Bob: Subject to action on Gil from earlier

<dug> 192.212.29.75

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7589

<Yves> this one is not blocked and has never been

<dug> 195.212.29.83

Gil: Need to define how to compute this URI if it not there

<Yves> dug, this one is not blocked

<dug> sigh

<dug> can't get to anything

Gil: A.1.2.1 and A.1.2.2 require text describing how to compute the ActionURI if it is not present in the event description

<gpilz> The [Action] property of the Notification has the value of the actionURI attribute of the wse:eventType element corresponding to the type of the Event being transmitted.

<gpilz> The [Action] property of the Notification has the value of the actionURI attribute, if present, of the wse:eventType element corresponding to the type of the Event being transmitted.

<dug> dunno if its caching

<gpilz> If the actionURI is not present, this property has a value that is the concatentation of the wse:EventDescriptions targetNamespace attribute and the wse:eventType name attribute separated by the '/' character.

Doug: Will this apply to all bindings?

<gpilz> This attribute provides a value for the various 'action' properties and attributes which, depending upon the format of the Notification used to transmit the Event, serve as a potential aide to identifying the semantics implied by the message.

<gpilz> This optional attribute provides a value for the various 'action' properties and attributes which, depending upon the format of the Notification used to transmit the Event, serve as a potential aide to identifying the semantics implied by the message. When not present the implied value of this attribute is the concatentation of the wse:EventDescriptions targetNamespace attribute and the wse:eventType name attribute separated by the '/' character.

Gil: This saves changing it in both A121 and A122

Asir: Does this address your concern about bindings Doug?

Doug: Yes

RESOLUTION: Text updates as agreed above and also ensure that schema is updated with '?' appropriately

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

Issue 7207

Li: Need to maintain the semantics of push in the eventing spec
... it is a very important concept in eventing
... proposal is to add an indication of the type of delivery that is supported by the event source

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

Martin: What is the definition of push in this context?

Li: The event delivery is initiated by the event source so there is no dependency on messages from the event sink for the delivery of events

Bob: Push is the default way that the spec operates using an EPR

Asir: This is not the default. The NotifyTo is not required in the spec.
... What Li is proposing is a way to say that you require the NotifyTo

Doug: Is this to say event source supports or client requires Push?

li: The former. B.3 is not part of this discussion.

Doug: All you are looking for is a way to say 'I support the NotifyTo'

Li: Yes

Doug: I don't think that the source can fault because it doesn't understand notifyTo
... Definition 4.1 indicates that an EventSource must support notifyTo
... So we don't need a policy to indicate this

Asir: Looking from the metadata point of view. The text says when NotifyTo is there, receiver must do this.
... As an EventSource, I need a runtime-independent way of indicating support for NotifyTo
... EventSource tells subscribers if you are talking to me then use NotifyTo

Martin: This is a flag to say only NotifyTo is supported
... is my interpretation

Asir: We could add a sentence to explicitly state that all eventsources must support notify to

DaveS: Text under 4.1 indicates support. I think that this issue is for the EventSource to indicate that *only* NotifyTo is supported.

Bob: Is the sentence in 4.1 clarity enough to say that NotifyTo must be supported?
... Do we need 'All EventSources must support NotifyTo'

Doug: But we'll need to do that for all optional client behaviours

Martin: The current 4.1 text is unambiguous. If client passes a notify, must send

Wu: It does not say that it is required

Bob: The first question is: Do we make it clear enough in the spec that the event source must support notifyto?

Wu: I would like a clarifying sentence in 4.1: "EventSource must support NotifyTo"

Doug: If we really want to do this, we should clarify in the compliance section to say that optional client behaviour by default means required service behaviour

Martin: RFC2119 says should be clarified for sender and receiver

DaveS: We should check each optional/musts

Bob: Would this be sufficient to clarify that for all of the sender optional things described, receipt of these optional aspects is required by the receiver

Wu: This is a good step forward

Ram: What if I really want a subscriber to send me a NotifyTo

Doug: If in your policy you don't include any other mechanisms for notification then that indicates that only NotifyTo is supported

Asir: What is the fault if the sender does not send a notifyTo when that is required

Bob: Do we have an agreement that we will clarify the conformance section regarding optional sender aspects

Wu: Yes. This will satisfy our first concern

Martin: In response to Asir's question - we need to be clear as to what fault is returned

Bob: What other aspects need to be considered Li?

<Bob> acl li

<Wu> This "OPTIONAL" clarifying is needed, because it beyond the original def of "Optional" as in RFC 2119

Li: If you want to do Push from the EventSource, how does the EventSource know that there's nothing more than the EPR required to send to the sink?

Bob: Li, is your question the EventSource requires no further stimulus other than the occurence of an event to send a notification to an EPR
... ... is that written in the spec? My belief is that the spec covers this.
... I believe the question is WHEN is the notification sent. Is this correct Li?

Li: yes

Martin: You can't say how long it takes to reply to something.

Gil: How about filtering or batching? This would take time

Bob: I think that Li's issue is regarding the wording of Push

<dug> scribe: Dug

Wu: missing async unsolicited

<gpilz> how can in be unsolicited when you asked for it by sending a Subscribe request?

Bob: async with respect to what?

Wu: async with respect to the event sending behavior

<scribe> scribe: Katy

Bob: When we first looked at the definition of 'Push' we found it undefinable which is why there was support to remove it
... The current spec uses an EPR and there is nothing that the source needs to do other than send the messages. The spec is clear now

Martin: I can't see what other normative text could be added for this behaviour

Li: As the current spec already implies the behaviour of push, I think this works.

RESOLUTION: Add text to the conformance section to clarify optional sender behaviour means required receiver

<scribe> ACTION: Doug to come up with proposal across all 4 specs and also to uppercase OPTIONAL [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action03]

<trackbot> Created ACTION-115 - Come up with proposal across all 4 specs and also to uppercase OPTIONAL [on Doug Davis - due 2009-10-08].

Issue http://www.w3.org/Bugs/Public/show_bug.cgi?id=6402

Wu: We are happy with this direction and think it's a good step forward. We may propose additional augmentation as new issue if required.

RESOLUTION: Resolve 6402 with comment 7 and schema update

Issue 7478

Yves, please could you unblock me? - 195.212.29.92

<Yves> katy can you retry?

<dug> Wu's proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/att-0001/7478-7587_proposal_v2.doc

Yves thanks working now

<dug> Gil's proposal: http://www.w3.org/Bugs/Public/attachment.cgi?id=760

Wu: Starting with proposal uses boolean attribute in section 1
... can support existing use of expires
... need to add attribute in schema in 4.1
... called exact and this optional attribute has value of true then MUST create with the expration time or else fault
... if it has value of FALSE, then expiration time needn't be exact
... This ensures that the eventsource must honour expiry if that's required but also gives flexibility if the exact expiry is not required

Martin: If you say exact=false, what does that mean?
... I understand the true case

<asir> suggest that we don't call other participant's use case silly

<dug> can we call each other silly?

<gpilz> it's not the use case that is silly, it's the behavior

<dug> its probably tamer than what we'd like to say :-)

Gil: A problem is that there's nothing to say that the eventsource will give a close value if the exact flag is not specified
... a hint is semantically meaningless in this context

<asir> I would like to ask Gil a clarification question

Gil: so exact=false is going back to the current behaviour where the client has no say
... A client needs to be able to set a lower limit on what it can live with if the exact=true is not specified

Ram: The existing behaviour makes a lot of sense in devises world
... In that environment it makes sense for the client to request a time, but if that's not possible then the service offers what it can
... the client can choose the service that gives the best service. e.g. printer services
... I appreciate that we might need min too but we should make all the use cases work

Gil: But why would I bother to specify an expiration at all if I can just accept what is being given?

Ram: I believe that the proposal allows both behaviours
... We think we can add sufficient words to clarify what Exact=false means
... If we do this can we make some progress on this issue?

Doug: In the proposal is there a way of saying 'I don't care about the expiry time'
... I wonder whether we should cover all 4 cases 1) Exact time (Exact=true), 2) Indefinite time (no no expires specified), 3) Hint (Exact=false) 4) I don't care

Wu: the proposal doesn't cover 4

<asir> Ram said that 4) is the same as 3)

Wu: Typically a subscriber will ask for the maximum - which we have covered
... When Li and I went through use cases there is no real benefit to specifying a minimum time because a server will always choose the minimum time in order to save its resources

Doug: Do we have a use case for 'don't care'?

Gil: 4- If it was so important for you that the subscription succeed that you will accept any expiration

Wu Ram DaveS Bob: Do not see a use case for 4

Martin: The current spec says nothing - the source can pick any time it wants
... I don't understand the use case for a hint

Gil: The use case for a non-hint is that I would like to specify boundaries to the expiration time and hint does not give me this. I'd prefer to say fault the subscription if you can't do min expires.

<asir> Martin - why allowing the hint use case is harmful?

Gil's proposal http://www.w3.org/Bugs/Public/attachment.cgi?id=760

Gil: This is based on yesterday's discussions

<MartinC> thr trouble with hints is anything can be given, and some may not be acceptable, so hint is a weak "don't care"

<asir> k .. is that harmful?

Gil: 1) Leave expires element out = accept anything, 2) Expires says = this is what I want 3) Expires with min attribute = specify expires but this is what I can live with
... This satisfies the use cases presented and client is clear what is accepable

Ram: Problem is that the event Subscriber doesn't really know what the range is

Gil: then don't constrain with the min attribute

<asir> I have not heard any rationale as to why the WG should disallow the hint use case

<dug> old vs gil's

<MartinC> personlally i think gil's has it wring way i..e 12 is min with an optional max

Doug: <expires min=0>12pm</expires> will give the hint use case in Gil's format

Wu: We do not think that the min/max duration is a use case because the event source will always honour the minimum duration

Gil: But without the minimum, you could just give any expiry to save resource in the service

Bob: The difference between the proposal is that proposal B places control of the minimum on the client
... If it is the behaviour that the client will alway provide the minimum, the client could specify its minimum as exact=true

DaveS: I have identified 5 use cases 1) Exact (Both proposals) 2) Best Effort (Both) 3) Infinite/Indefinite (Both) 4) I don't care (Gil's but could be added to Wu's) 5) Range (Gil's only)
... So Gil's proposal is more complete but Wu's proposal is closer to current behaviour
... So if I was starting from scratch I would go with Gil's proposal but it would mean more impact to current implementations

Ram: What if we accommodated min/max in Wu's behaviour so we get (5) above but without inverting current behaviour so minimum impact to current spec

<Expires Exact=boolean | minimum=duration|dateTime> duration|datetime </Expires>

DaveS: How about we start with Gil's proposal but invert the behaviour?

Bob: Replace exact with minimum attribute. If min=expiry time then the exact time is required

Doug: If this now supports don't care we will be now be changing behaviour as missing expires behaviour will change

We: Wu don't care about don't care

<scribe> ACTION: DaveS to prepare new proposal for 7478 [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action04]

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

<scribe> ACTION: Dave to prepare new proposal for 7478 [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action05]

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

<scribe> ACTION: DavidS to prepare new proposal for 7478 [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action06]

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

<scribe> ACTION: Snelling to prepare new proposal for 7478 [recorded in http://www.w3.org/2009/10/01-ws-ra-minutes.html#action07]

<trackbot> Created ACTION-116 - Prepare new proposal for 7478 [on David Snelling - due 2009-10-08].

<Bob> rrs, generate minutes

<Yves> trackbot, end telcon

- DRAFT -

Web Services Resource Access Working Group Teleconference

01 Oct 2009

Attendees

Contents