See also: IRC log
<trackbot> Date: 24 March 2009
Fred Maciel is scribe
<Bob> scribe: Fed Maciel
<Bob> scribenick: fmaciel
Agenda approved w/o
RESOLUTION: Minutes of 2009-03-17 approved with no objections
RESOLUTION: All new issues accepted and assigned to reporter, except for external editorial comment (6725) which will be assigned to Doug who has already made a proposal w/o
No volunteers, will remain unassigned for now
<Bob> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/0077.html
RESOLUTION: Issue-6595 resolved with proposal (proposal #2, comment #4 in bugzilla) without objection
<dug> proposal: http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Mar/att-0076/00-part
Asir: considers this to be a substantial change and he requests a migration strategy but thinks the proposal reasonable
<dug> katy - did we do that? I don't recall that
<Katy> The text is there but unchanged - awaiting this issue
<dug> ah - so just ws-eventing had it removed?
<Katy> I didn't remove it from any as the resolution said we'd not address this under the notational conventions issue
<dug> s/must not/do not/
<dug> as an editor - I'm ok with that
<dug> +1 to katy - its just a copy-n-paste and makes it easier in the long run to have the specs look similar.
<Zakim> asir, you wanted to talk about http://www.w3.org/Bugs/Public/show_bug.cgi?id=6587
<DaveS> Suggestion for fixing the language problem I am worried about: Senders MAY indicate the presence of an extension that has to be understood through the use of a corresponding SOAP Header with a soap:mustUnderstand attribute with the value "1".
<gpilz> how about "an extension it requires to be understood"?
<dug> seems fine
<asir> what is the proposed editorial change to Gil's proposal
<gpilz> Senders MAY indicate the presence of an extension that has to be understood through the use of a corresponding SOAP Header with a soap:mustUnderstand attribute with the value "1".
<Zakim> asir, you wanted to ask a question
<dug> although, we can probably say MUST NOT since the receiver MUST adhere to SOAP and mU=1 is part of SOAP.
<dug> never mind - I see Dave's point
<dug> that's fine - and let's apply it to all specs :-)
<Bob> [1]proposal: The elements defined in this specification MAY be extended at the points indicated by their outlines and schema. Implementations MAY add child elements and/or attributes at the indicated extension points but MUST NOT contradict the semantics of the parent and/or owner, respectively. If a receiver does not recognize an extension, the receiver SHOULD ignore that extension. Senders MAY indicate the presence of an extension that has to be understood through the use of a corresponding SOAP Header with a soap:mustUnderstand attribute with the value "1".
RESOLUTION: Issue 6648 resolved with proposal[1] above without objection
Bob: And we should record the second resolution
RESOLUTION: the text[1] above shall be applied to all specifications without objections
<asir> How would you distinguish a NotifyTo EPR from a MakeConnection type EPR?
<gpilz> you don't
<gpilz> that's the whole point of WS-MC
<dug> bob - I'd like to ask Wu a follow-on question
<dug> I still don't see the diff between NotifyTo and ReplyTo and I think it would actually be a mistake to imply they're different
<DaveS> +1
<DaveS> What Doug said
<dug> ws-e doesn't mandate that PUSH mode is a one-way
<DaveS> But we still don't have a use case for any Mode other than push mode.
<dug> granted a Notification is a one-way but not PUSH mode
<dug> its broken because we're adding confusion and duplicate semantics
straw poll on removing push mode from specification (accepting Dave's proposal):
5 votes for, 2 against, 1 abstain
<asir> Wu and I mentioned that 6432 need to be resolved first
<gpilz> I object also everyone else obviously disagrees
<dug> +1 to gil
<DaveS> +1
<DaveS> We ned to se use cases for Mode not equal to Push Mode to better understand whay it is needed.
<dug> Wu - you can never stop someone from putting a MCanonURI in the NotifyTo
<Bob> ACTION: Wu and Asir We need to use use cases for Mode not equal to Push Mode to better understand why it is needed. [recorded in http://www.w3.org/2002/ws/ra/9/03/2009-03-24.html#action01]
<trackbot> Created ACTION-53 - And Asir We need to use cases for Mode not equal to Push Mode so WG better understands why it is needed. [on wu chou - due 2009-03-31].
<scribe> postponed to next week due to lack of time
Bob asked participants to review IRC for incomplete contents or corrections