See also: IRC log
Corrections to 2005-06-27 minutes?
Minutes approved (no objection)
AIs: Anish, Umit done. DHull LC76: Needs to be more concrete. Due 15 July.
AI: LC107 (Marsh). Draft, not
mailed yet. Editorial issue will be resolved. Marked as
done.
... LC68 (marsh) Done.
Marc: Only issue not incorporated is 107. All other issues should be in editor's draft. Please let Marc know if that's not the case.
Anish has made proposal, discussion is active.
Anish: Made draft of spec with
abstract model of EPR.
... several +1s. Marsh would prefer to close no action but OK
with it. There has bee nmore email in last 5 minutes.
MNot: Two related issues. Getting rid of abstract model for EPRs, and for MAPs.
Marsh: Only object to MAP part.
Anish: Issue is only about EPR, but did MAP too to see what it would look like.
Marsh: Collapsing EPR model makes
sense. Collapses two concepts, not just sections of document.
Infoset is not conveying that much extra information. Just
isn't that much independent of the infoset.
... Anish has shown that collapsing will work. Bummer is that
it's no longer consistent with MAP description.
... Not against getting rid of EPR section.
Mnot: Prasad, would you be OK with separating out EPR part, dropping abstract model in EPRs.
Prasad: No problem with
that.
... Some editorial inconsistencies to be taken care of. No
objection to collapsing.
Anish: Where?
Prasad: Section 2.1
Mnot: So some editorial work.
Prasad: [address] in metadata, for example.
(missed much of the detail there)
Umit: Comment on MAP change. What does separate abstract model enable? In WSDL, we talk about includes, imports etc. No comparable concept with EPRs. In favor of collapsing. We should look at MAPs the same way: What benefit to additional layer that infoset does not cover. Can separate issues this way. 101 and 104 appear to be only EPRs, not MAPs.
MNot: Anyone against EPR changes?
Hugo: Have some concerns about how it's written.
Katy: There are some advantages to abstract model, esp. for documenting. but not against collapsing.
Marc: Same camp as Prasad. Not violently opposed, but like consistency with MAPs. As far as MAPs, have we broadened the discussion? (Mnot: No) Would be against for MAPs. No editorial problems. Some strange items to sort out, e.g., we're talking abougt address and metadata, not XML elements.
<anish> yes, the editors have full license to change the title ;-)
Hugo: Same position as Marc.
Uncomfortable with section 2.1 "EP representatation" Not
representation, but definition. Can see this as editorial
problem, or mixing representation with definition.
... Mildly uncomfortable with this. Like having abstract
props.
Marsh: A couple other items: Don't have to solve 101 or 104 to declare victory. No implementation consequences. Stability of document is important. Can live with status quo.
Anish: Editors have full license
with editorial changes. Do think 101 and 104 are important. We
have created abstract model, claim extensibility, but don't say
how. Don't say how to reverse map infoset to abstract,
specifically for EPR. EPR infoset is extensible, but what about
abstract model? Not clear what happens. Katy's example is the
first I've heard where someone wants to...
... actually do something with abstract model (but think
documenting infoset would be as easy). Don't see reason for
having abstract model. Documentation alone is not enough, given
101 and 104.
<Marsh> I note that we've successfully using the (extensible) Infoset abstraction without over-architecting the extensibility model
Tom: I like the proposal. Not do or die. Simplifies by having only one level. Always know where to put text.
Gudge: Don't think one-way mapping is a problem. Common in specs, e.g. SOAP 1.2 datamodel. We've discussed "how does extensibility work?" It's up to other specs to say how it works. Fond of keeping abstract models; it's cleaner. Pure infoset does not make life better.
MNot: Does anyone feel very strongly about this?
Anish: Have to address extensibility issue.
MNot: That's 101, right?
Anish: 101 and 104 go hand in hand.
MNot: Of course, but on table now is collapsing. Would solve 101 but there are other ways. Do you feel strongly about this, Anish?
Anish: This is a good way to go. Need to resolve 101 and 104 somehow.
Gudge: What about doing nothing.
Anish: Not happy with that.
<mnot> Prasad's proposal: "The information model of an end point reference is extensible in that additional properties and attributes on the properties may be added. See the XML Infoset model section for a formal specification of the extensibility points at the XML Infoset level."
Umit: Prasad sent message today
about extensibility. Would need to add something to abstract
model per what prasad said, saying that abstract extensibility
follows infoset ext.
... Would this meet Anish's requirement? As AI owner, I was
going to propose something much like this, so think Anish's
proposal is viable for EPRs.
Glen: Prasad's was about what I was going to say. Tells extension writers to update abstract model as well. (except for Must Understand :-)
<uyalcina> Let me add though I like collapsing 2.1 and 2.2 better.
Anish: Whole issue is what happens to abstract model? We're handwaving as it is. Can use attribute, any, whatever, with no guidance.
Glen: How else can you do it?
Anish: What is value of abstract model?
MNot: Old argument.
... What do people think of Prasad's proposal?
Umit: Chad?
MNot: More complex than that. This discussion is to see if group wants to revisit issue. But there is still a lot of doubt.
Umit: We were talking about
extensibility of MAPs, not EPRs. MAP extensibility was the big
item, not EPR. This is a bit different.
... 101 and 104 is talking about EPR, not MAP. Anish happened
to do extra work for MAPs. Doing one and not the other would be
inconsistent, but collapsing EPR doesn't reopen MAP issue.
MNot: Not talking about MAPs, but about vote on collapsing out abstract model. If group doesn't have a problem, not a problem. But if there are doubts, we need a higher standard.
Anish: Not trying to raise abstract model issue again. But if we do have one, we need to address extensibility if we want interoperability. Handwaving now. If there is value in abstract model, there is more work to be done.
Mnot: for group to decide.
... Proposals on table (EPRs): Collapse abstract model, or
Prasad's proposal to map infoset extensions to abstract
model.
Anish: As the proposal stands, properties in abstract model are extensible, see infoset for infoset extensibility, but doesn't address extension to abstract model.
Glen: THink it needs tweaking as well. Not hard.
Umit: If collapse, don't need to do anything.
<mnot> scribe: mnot
<pauld> option 1: colapse abstract model and EPRs
<pauld> option 2: tweak text make extensibility per extension
<pauld> option 3: status quo
<pauld> question: way forward for LC104
<pauld> chad, question: way forward for LC104
<GlenD> vote: 2, 3, 1
<pauld> chad, option 1: colapse abstract model and EPRs
<pauld> chad, option 2: tweak text make extensibility per extension
<pauld> chad, option 3: status quo
<GlenD> vote: 2, 3, 1
<anish> vote: 2
<anish> vote: 1
<Nilo> vote: 1
vote 2,1
<dorchard> vote: 1
<TonyR> vote 3, 2, 1
vote: 2,1
<marc> vote: 2,3
<Katy> vote 2, 3
<andreas> vote: 1
<PaulKnight> vote:3
<hugo> vote: 2, 3, 1
<prasad> vote: 2, 3, 1
<mlpeel> vote: 3, 1, 2
<TomRutt> vote:1,2
<Katy> vote: 2, 3
<abbie> vote: 3
<scribe> scribe: dhull
<TonyR> vote: 3, 2, 1
<bob> vote: 3,2,1
<vinoski> vote: 2, 3
<anish> vote: gudge: 3, 2
<uyalcina> vote: 2, 3, 1
<pauld> vote: 3, 2
<Arun> vote: 2, 3
<steve_winkler> vote: 2, 1, 3
<pauld> chad, count
<chad> Question: way forward for LC104
<chad> Option 1: colapse abstract model and EPRs (5)
<chad> Option 2: tweak text make extensibility per extension (10)
<chad> Option 3: status quo (7)
<chad> 22 voters: abbie (3) , andreas (1) , anish (1) , Arun (2, 3) , bob (3, 2, 1) , dhull (2, 1) , dorchard (1) , GlenD (2, 3, 1) , gudge (3, 2) , hugo (2, 3, 1) , Katy (2, 3) , marc (2, 3) , mlpeel (3, 1, 2) , Nilo (1) , pauld (3, 2) , PaulKnight (3) , prasad (2, 3, 1) , steve_winkler (2, 1, 3) , TomRutt (1, 2) , TonyR (3, 2, 1) , uyalcina (2, 3, 1) , vinoski (2, 3)
<chad> Round 1: Count of first place rankings.
<chad> Round 2: Eliminating candidate 1.
<chad> Round 3: Eliminating candidate 3.
<vikas> vote: 3
<chad> Candidate 2 is elected.
<chad> Winner is option 2 - tweak text make extensibility per extension
<pauld> chad, count
<chad> Question: way forward for LC104
<chad> Option 1: colapse abstract model and EPRs (5)
<chad> Option 2: tweak text make extensibility per extension (10)
<chad> Option 3: status quo (8)
<chad> 23 voters: abbie (3) , andreas (1) , anish (1) , Arun (2, 3) , bob (3, 2, 1) , dhull (2, 1) , dorchard (1) , GlenD (2, 3, 1) , gudge (3, 2) , hugo (2, 3, 1) , Katy (2, 3) , marc (2, 3) , mlpeel (3, 1, 2) , Nilo (1) , pauld (3, 2) , PaulKnight (3) , prasad (2, 3, 1) , steve_winkler (2, 1, 3) , TomRutt (1, 2) , TonyR (3, 2, 1) , uyalcina (2, 3, 1) , vikas (3) , vinoski (2, 3)
<chad> Round 1: Count of first place rankings.
<chad> Round 2: Eliminating candidate 1.
<chad> Round 3: Eliminating candidate 3.
<chad> Candidate 2 is elected.
<chad> Winner is option 2 - tweak text make extensibility per extension
<TonyR> chad, details
MNot: will this cover both 101, 104?
Omnes: various
<mnot> ACTION: Glen to review proposal for LC 101; due EOW [recorded in http://www.w3.org/2005/07/11-ws-addr-minutes.html#action01]
<scribe> ACTION: Dhull to provide concrete faults writeup. [recorded in http://www.w3.org/2005/07/11-ws-addr-minutes.html#action02]
Anish: Haven't discussed MAPs (but don't expect support for that).
MNot: Does anyone want to speak for the MAP aspect?
(silence)
MNot: LC 101. Can we discuss this now, or wait for Glen's proposal?
Glen: Just need to tweak text. Corresponding parts in abstract and infoset descriptions.
Umit: +1
Mnot: Deferring discussion of 101, 104
Mnot: semantics of anon URI.
Dhull made proposal for "return to sender" semantics. Not much
discussion yet.
... Where do we sit?
<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jun/0117
glen: In wsdl, we had a discussion of the breadth of reply; we came up with text. Should we refer to that?
dhull: there's only a paragraph here, let's go over it
tomr: name change may be a problem, but otherwise like it
glen: seems more restrictive than WSDL
glen: restricts it to the underlying transport facilities.
glen: that's OK; wouldn't refer back to wsdl.
dhull: I think the touchstone is that if the receiver gets anon, would it know what to do? In HTTP, it has a nice, well-defined place to throw the message.
glen: I can imagine a system that replies to a fixed queue, and therefore I don't need something on the wire; in that case you'd use another URI. I like this.
dhull: Right; we'd define other pseudo-URIs.
glen: I like the crisper URIs.
Tony: as far as the name goes, I don't like anon; I prefer sender.
<TomRutt> I can live with the name change to "sender"
<marc> sender could be taken to imply that one should send the reply to the [source] endpoint
<TonyR> and shouldn't that be the same?
Marsh: I have concerns that some semantics are lost; before, it was 'use the underlying layer', now there are some cases taht can't be covered.
<marc> so the Source EPR should have a 'sender' address - seems a little recursive
<TonyR> good point
<TomRutt> Sender is not the correct word. We need to connote use of an underlying back chanel
dhull: there are two different levels; there's the transport level, and the higher MEP level where I would like anon to mean 'send it right back to me.'
dhull: there might be multiple ways to realise that at the transport level.
dhull: there are differnet meanings, depending on how you look at it.
dhull: either way is valid; but I'm uncomfortable leaving it open.
<GlenD> +1 to David
dorch: I agree that it's not quite right, but I can't think of anything better.
dorch: I think sender is worse than anon.
dorch: unless somebody can come up with something better; I don't see us doing it anytime soon.
dhull: I think sender is the right way to say send it back to the sender; we probably want to say both.
dorch: I could come up with a protocol that has a back channel that goes somewhere other than the sender.
dhull: in that case, you'd use anon
dorch: feels like angels on a pin
dhull: no, there are two different meanings being thrown around
dorch: do we have two words now?
dhull: no
<mnot> ACTION: David Hull to revise proposal lc20 [recorded in http://www.w3.org/2005/07/11-ws-addr-minutes.html#action03]
<scribe> scribe: dhull
<TomRutt> If we have two different uri values, we have to decide which is the "default" for reply to, and "to"
Mnot: Jacek's issue: Mandatory reply-to. Reopened I50. Katy has put forth two proposals.
<TonyR> the binding might specify which is default
Katy: Wrote up proposal for "no
reply" URI. Did two proposals because there were two
interpretations of proposal.
... Wanted to see it all written down. Suspect that everyone
would be happy with one or the other. Does make things more
complex. There is a general issue of whether introducing
another URI is a good way to go, then discuss particular
proposals. Does fix problem, but at expense of complexity. Is
there a better way? The two proposals are very similar. No
point in discussing them...
... without disucssing larger issue.
... Do support the proposals. No specific preference. But is
there an easier way?
... Maybe attributes? Specifically, would address Paco's
concern.
Glen: Does solve problem. More common use case (and solution) is going to be that "no reply expected" will generally be captured elsewhere. Adding new URI addresses concern, not complicated, but probably won't be used.
MNot: Will this be required if no reply expected?
Glen: I hope not.
MNot: Is "no reply EPR" required if no reply expected?
Katy: Should be fine, I think.
Marc: Default is anonymous.
Glen: decided at higher level.
Marc: Question: is meaning "not-valid URI"? Or more like "dev null" (can't send to it, vs.can send to bit-bucket). More comfortable with /dev/null.
Katy: Missed that. Slightly different semantics.
MNot: Very good question. Popping up, is everyone comfortable with general direction.
Gudge: not required to use it if you don't expect a reply?
Mnot: yes.
Gudge: Why is it useful.
Mnot, Glen: Gets us to CR.
Umit: Gudge has point? What is usage pattern. Recommended?
Tom: Avaialbe for use.
Mnot: Loss of information if default is anonymous.
Glen: Interestingly, doesn't let you default to From:. If you want that, put it in explicitly.
MNot: Jacek and WSDL say that anonymous is common case. Paco doesn't want to lose information with defaulting.
Glen: Could get default to From: anyway.
Mnot: Two subquestions. Which proposal is better, fault vs. /dev/null.
Katy (summarizing): First introduces new URI for "no reply" for [reply endpoint]. Second says more general URI OK for [reply ..] [fault ..][source ..] whatever.
<marc> my preference is for general purpose URI (reply and fault) that means > /dev/null
MNot: Reply only or more generic.
Tony: Not a small difference. No fault URI is weird.
<TomRutt> I like general uri
Marc: Thus general URI for reply, fault or both.
Tony: What does it do?
Gudge: How can you send with no address.
Marc: By default.
MNot: Allows you to say "drop faults on floor".
Tony: Maybe we need two new URIs (one for fault, one for bit-bucket)
MNot: That's second subissue.
Tom: Faults coming from sender? 3-way handshake?
MNot: Don't think so.
Marc: What is use case for "faulting" URI.
Tony: If you're inside Axis or whatever, if it attempts to send to reply to that's sent to faulting URI, service implementation will get fault/exception. /Dev/null will be silently used.
MNot: Let's go back to first
subissue (good point, though).
... Where do we sit on making it generic, or just specific to
replies.
<TomRutt> usefull to be generic
Marc: Generic
+1
MNot: Specific, anyone?
... Looks like generic "not-valid" URI. Subissue 2: Bit-bucket
or faulting behavior?
... Tony, cases for both versions?
Tony: Prefer having a selection of standard URIs rather than one-size-fits-all.
Marc: What happens if you put faulting URI in fault to?
Tony: Back-channel.
Mnot: There might be cases that don't work.
Katy: Some cases have unconstrained behaviour.
Marc: Effectively the same as /dev/null.
Mnot: Might be useful in reply
TonyR: It's the case of idiot web service, framework is smart and does appropriate thing (e.g., guns web service)
MNot: So proposal is two variant URIs.
Marc: second would say "I don't want replies", first (?) would say "I want fault if someone tries to reply"
Tom: Don' tunderstand that faulting behavior.
Marc: Don't see point of it either. Shouldn't care if someone tried to send a reply, as long as I don't get it.
TonyR: Doesn't make sense with only two parties, but WSs will live in frameworks.
Tom: Don't we already have afaults for unsupported to: address?
MNot: Who thinks faulting version is a good idea. Everyone seems to like /dev/null version.
Tony: Just realised ... Now
speaking against my own topic ... If we do have /dev/null,
framework can still chastise web service.
... (or its author)
Mnot: Anyone else still
interested in faulting version? No.
... Proposal is now "generic not-valid URI, /dev/null
semantics".
... (currently faults)
Katy: Correct. Shall I write this up?
MNot: Trying to close the issue
right now. Can write this up after the fact.
... Proposal understood.
Omnes: Silence.
<steve_winkler> Mark, Are you going to ask about dates for August F2F?
MNot: Would close I50, LC69, LC108. Jonathan, is this likely to be OK with WSDL group?
Marsh: THink so.
Marc: Captures text to be edited, but needs work. Think not valid is a bad name. Can I change?
Tony: Still like /dev/null.
Mnot: None is better. Give editor license!
<TomRutt> I like none better than null
Mnot: Any objections?
... None. Issue closed.
... Thanks Katy for detailed proposal. V. helpful.
TOPIC LC 55, 87
Marc: Two buckets of comments.
Tweaks and nits, e.g., used property not in EPR, meant one in
EPR. Significant discussion around whether section should be
normative.
... Idea was to specify mechanism that SHOULD but not MUST be
implemented. If in use, this is how you should garner trust.
Pushback: Two sentences is not nearly enough. Shouldn't specify
anything, just give example. A couple of +1s to that.
MNot: This is re-opening an issue. Had had shoo-in to re-open and close with this. Is that still the case or is there controversy. Can those who opposed normativity speak to this?
Anish: Clarification: Normative if you choose to use it, right?
MNot: Does it require testing?
Hugo: Marc summarized accurately.
Basic security model is an improvement on status quo. May need
minor tweaks. Spoke with security experts at W3C. They were
worried that it was underspecified. E.g., talks about domain
comparison, several ways to do this in X509. Need to hammer out
deatils for interop. Two sentences is far from what we need for
that. A lot of effort/expertise...
... required, maybe more than we have in this WG. If we
recommend a mechanism, need to test that it works.
... Introducing significant new text, so back to working
draft.
MNot: This discussion is re-opening an issue. Can we incorporate this proposal quickly and easily? Are we comfortable? Talk about it now or next week?
Marc: Clarification: Considering whole of text, or parts? Can we accept as-is and discuss taking normative bit out?
MNot: Don't think we can do that.
Could get into nasty situation about normativity.
... Hugo -- is non-normative version OK?
Hugo: As example, won't impact CR, will improve model.
MNot: Others?
Omnes: nadie
Marc: Would prefer not to make normative section example.
MNot: Intention for F2F is to ask if people are for or against re-opening. We'll see what group decides. If we can't come to consensus, suppose we won't re-open. Will have discussion F2F.
MNot: Proposal just needs to be
more concrete. Get crackin'
... Plan going forward. Very few LC issues on SOAP and Core.
Rest seem to have clear way forward. Will look at expanded
faults, maybe adjust. LC 5 is utility of source. LC 69 Jacek
responded with possible modification. A few more ends to tie
up. Hope to close rest of LC issues on Monday.
... Then need to do other things to get into CR. Implementation
and testing schedules, PR entrance criteria. Want to have docs
ready for CR at or near end of F2F. Come ready to vote. Will be
worried if we can't get out of LC by end of last meeting. If
so, break for meetings in August.
... Then back into WSDL doc, depending on timing. May be able
to leave F2F early instead. Start on WSDL in September. Still
need host.
... Will provide dates soon. Probably last half of week of 5
Sept. Or maybe week preceding.
Marsh: WSDL wanted week of 12th.
MNot: Won't be able to do that, won't need to co-locate.