See also: IRC log
<scribe> scribe: PaulKnight
any corrections to minutes?
face-to-face minutes accepted
wait until next week to approve last week's meeting minutes
suggestion to defer cr10 due to W3C representatives not being present
discussion of "on the web" definition -
Mark N: need to defer this discussion until W3C reps are here
Mark N: let's be prepared to make a decision next week, continue on email discussion
Umit: describing her proposal 1
uyalcina: wsaw:Async element may have three distinct values, â€œfullâ€, â€œneverâ€ and â€œalwaysâ€. Discussing behavior of end point with each value.
anish: question - anonymousUse Element at binding level?
Umit: no, at child level
anish: must set non-anonymous EPR? (if using addressing)
uyalcina: yes, does this need to be changed?
anish: WSDLRequired set to true in this case?
<Zakim> dorchard, you wanted to ask about problems of attribute extension
dorchard: attribute extension instead of element use?
uyalcina, others : use element notation so BP1.1 is not required
discussion of requiring BP1.1 rather than WSDL 1.1
what current products would have issues?
dorchard: allow extensibility point
<Zakim> marc, you wanted to ask about HTTP 202 stuff in WSDL binding doc
marc: section 3.1.2 - somewhat repititious
uyalcina: it was written from perspective of anonymous usage
marc: is it in right place? it does not really have to do with WSDL, but with SOAP. Maybe move it to SOAP or adendum to SOAP binding?
uyalcina: depends on how we want to position it, that might be okay
<Zakim> dhull, you wanted to propose separating markup issues from semantics
<dorchard> Marc, I agree with the gist of where you are going with this..
dhull: separate semantics, based
on my alternate proposal
... in context of SOAP... but don't want to address this in middle of conversation on markup
... talk first about angle brackets, then address the proposal (SOAP over HTTP) separately
... deal with section 3.1.3 separately, (still in WSDL doc)
... two separate subissues of i59
markN: what do people think?
uyalcina: this is a big change, not clear what dhull is proposing
dhull: 3.1.3 mentioned earlier is probably now 3.1.2
uyalcina: maybe it will be editorial, not adding a section
dhull: maybe no conflict,
... what do people think?
dorchard: seems like two separable things
dhull: proposed asynch text is to give rules to say exactly what goes on wire
markN: we discussed this at F2F, seemed to have an agreement to go forward using the combined proposal. concerned about competing proposals on the table now.
<uyalcina> the chair reflects my understanding as well.
markN: suggest dhull expresses his text as a delta against the agreed text
dhull: I am trying to do
... want to be able to handle both cases if it can be done easily, hoping to get opinions on the technical feasibility
... there may be no conflict, just trying to get opinions, and hope to hear where my proposal might fit in
markN: let's proceed with other decisions and syntax, get that finished, then come back to this.
dhull: okay, I do want to see this discussed at some point, not want to disrupt momentum
uyalcina: not want to rehash earlier decisions
<Zakim> Jonathan_Marsh, you wanted to ask whether specification of default values is really necessary.
Jonathan: getting complicated; can we remove the defaulting attribute?
uyalcina: considered it, it makes sense, would simplify proposal
Jonathan: would it be inconvenient not to have the default
Jonathan scremed and disappeared
Jonathan: in anonymousUseDefault,
can we say that you specify one of three values, otherwise it
will be allow. (?)
... can we get rid of ... ( can someone post the proposal?)
anish: we discussed some sort of marker for this
Jonathan: are there simplifications we can make?
gpilz: if you get rid of this, it makes the spec more clear
mnot: is this needed or syntactic sugar?
can we get rid of it or do we need multiple properties that need to be reconciled at run time?
Jonathan: unless restricting anonymous is the main case, we should consider this
gpilz: these issues can be skirted if there is no defaulting mechanism
mnot: jonathan wants to get rid of the attribute, umit can go either way...
anish: the default should not cause restriction on the values of the attribute vs. the element
mnot: should we keep the attribute byDefault?
anish: it should be a syntactic roll-up
mnot: can we remove the attribute for now?
Marc: is there still a default for ReplyTo?
mnot: any problem with dropping defaultUse attribute?
uyalcina: it appears several places
<marc> UsingAddr means either anon or non-anon if other element not present
<marc> right ?
mnot: we are asking Umit to remove this item, then look at this to see if it causes other issues
uyalcina: allowed, always, never - should we keep these values, or modify?
anish: I have a use case where
defaulting is useful
... response going back on HTTP response channel... (describes use case)
<Zakim> marc, you wanted to ask if there is a default if we drop the attribute
mnot: still syntactic sugar?
mnot: still at a point where we can ask Umit to remove this for now
no objections to action item for Umit for this.
<mnot> ACTION: Umit to revise i059 sub-proposal 1 to remove defaulting attribute [recorded in http://www.w3.org/2005/11/28-ws-addr-minutes.html#action01]
uyalcina: syntax of element?
???: required, prohibited, optional
<marc> +1 to johnathan, i proposed exactly that at the end of the F2F
support for using Jonathan's suggested values
does not work well with operation level granularity
Katy: can we keep ....
Jonathan: support 3 elements, no operation level support
mnot: this sounds like we are reconsidering the F2F agreement
Katy: at F2F, we said we needed a separate proposal?
<mnot> ACTION: keep syntax option 3 up-to-date as alternate proposal [recorded in http://www.w3.org/2005/11/28-ws-addr-minutes.html#action02]
anish: reconsider decison from F2F on operation level granularity?
mnot: decisions were to help us
move forward, but we can consider all proposals as they come
forward, one by one
... focus for now on Umit's proposal
anish: decisions independent of proposal - are we reconsidering them?
uyalcina: these are not just my proposals, I'm incorporating the decisions made at the F2F
TomRutt: having this available does not mean everyone has to use it
but this may bear on how conformance to the standard is measured
mnot: moving forward, we'll take Umit's proposal as the baseline going forward, with additional proposal by Jonathan to be considered later
dhull: is the one-element solution compatible with re-using the same elements in policy assertions?
mnot: what else do we need to do to address i59?
<mnot> ACTION 2=Jonathan to keep syntax option 3 (three elements) up-to-date as an alternate proposal
mnot: how do people feel about WSDL dependency? to include MEPs
dhull: MEPs beginning with in are easy to define, but those with out are harder, no clue..
dhull: i have already done the
action, see the proposal
... flowing into Umit's text is the main issue
mnot: please look at how to flow it into Umit's text
dhull: okay, this is fairly well covered now
xmlp recharter is expected after AC meeting
mnot: reformulation of option 1
by Umit due Friday
... look at David Hull's proposal
... hopeful we can close i59 by end of year
... only a few more meetings this year
... any other thoughts on i59? none
PaulD: will have regular meetings for remainder of year
mnot: any other business?
vikas: recent email on async cases? does it fall under i59? How source routing works?
mnot: anyone want to respond? It's not part of i59, which is async in general; this is not in scope for us.