See also: IRC log
Discussing process of handling formal objections
JeffM: protesting the method of handling the formal objection as an abuse of process
Glen: will want some time to discuss the Async TF results
Chair: other Administrivia
Chair: want to take a break in August
Chair: note that one organisation has three representatives on the WG
Chair: MS has added a third participant (Mark Goodner)
Chair: note that the charter does not restrict the number of participants
Chair: note that this does allow organisations to bring their QA people into play to assist with the CR process
Chair: keeping an eye on the issues relating to good standing rules and the question of weighting straw polls
Chair: if necessary, will move straw polls to one/organisation
Marsh: reason for including an extra person - Gudge may be moving on, and Marsh may have trouble attending. We want to make sure we maintain active participation.
Glen: possible to use the "invited expert"
means of involving others
... may want to do this to involve someone from Apache
Chair: looks like best week will be week of September 26th
Omnes: rumblings of date clashes
Chair: still looking for a host
Looking rather urgently for a host in the Bay Area
scribe: Tentative dates are 27th and 28th - hope to settle this this week
Next F2F after this would be November - week of the 7th or 14th
scribe: Week of the 14th looks problematic - consider the week of the 7th.
Week of November 7th - any problems?
Next one after that would be January - week of the 9th or 16th
And after that is W3C Tech Plenary - end Feb / start of March - pretty much set in stone - in Nice
January will probably be US east coast
November is likely to be overseas
Possibilities for November are: Tokyo, Sweden, and London.
Omnes: Tokyo looks good!
Chair: looks like the week of November 7th in Tokyo
Bob: Hitachi is willing to provide facilities for WSDL as well as WS-Addr
Chair: looking for a host for January - probably week of 9th of US East Coast
Chair: willing to consider mid-US
Chair: defer consideration to tomorrow
Chair: done
Chair: response from originator to closure with no action - suggesting changes to language
Jacek's suggestion is accepted
<scribe> ACTION: Mike to respond to Jacek [recorded in http://www.w3.org/2005/07/18-ws-addr-minutes.html#action01]
DaveH: providing a standard means / language
for returning a fault - not mandating format, but suggesting things that
could be included in the detail element
... Proposal suggests content to include with any of the four "standard"
faults
... Attach language to the binding in Section 7
... Minor issue with mechanical details of how to include this.
... main objective is to make faults more useful / informative
mixed discussion of origin of faults, content
<Zakim> Marsh, you wanted to ask about MismatchedAction content
PaulD: if we mandate these we must test for them. Fair enough to have them as suggestions, but not mandatory
DaveH: not mandated - just suggestions - if you
want to include this information, this is standard way to do it. SHOULD not
MUST
... there are occasions when one may wish to omit the detail (eg: list of
supported actions), hence the SHOULD
... most of this goes in the InvalidAddressingHeader - added after the QName
that is the standard content of that header
... will probably need to wrap the QName
SteveW: is this an exhaustive list?
DaveH: fine to add some language which indicates that this is not exhaustive
PaulD: concerned about putting this into the Core - perhaps it should be published as a Note or Adjunct
DaveH: Perhaps
<Zakim> Marsh, you wanted to ask whether we expect interop on the difference between malformed IRI and relative IRI.
<pauld> sees this as a bi-product of writing a test assertions document
Umit: in favour of this proposal - good to have standard error information format
<Marsh> +1 to a bit over the top!
Marc: concerned that this is a bit too detailed
Discussion of testing and the need to test all of the error conditions
PaulD: may need to add error codes as we develop the tests
Umit: interop depends on standard descriptions of faults / error content
Steve: yes, never finish with errors, but
having well-defined errors is helpful
... we can add more errors in an extra document, but let's include the ones
we know now
PaulD: does this mean we have two lists of errors?
TonyR: but it is not the list of faults we're discussing - the faults are agreed - we are talking about the detail
DaveH: have never seen an error message that was TOO detailed... Concerned that this isn't fully baked yet
Chair: can we change a list of errors during CR without kicking back to LC?
Hugo: probably not count as a substantive
change
... unlikely to violate the rule about "affecting some-one's implementation
or review experience"
<yinleng> abstain
<mlpeel> abstain
Straw poll: 11 in favour, 3 against, 3 abstain
PaulD: likely to change, shouldn't be in the spec
Marc: it's overkill
TonyR: asking those against: OK to include faults, but not the detail?
Marc: yes
PaulD: yes
Chair: can we get the proposal "baked" to increase it's acceptability?
<pauld> seems like accepting this will prevent us being able to vote on leaving CR tomorrow. Expensive "wouldn't it be nice if ..." :-(
Marsh: prefer to not get this in rather than
waste lots of time on it
... question on detail of one fault
<pauld> s/one fault/detecting the difference between relative and malformed IRI/.
Omnes: perhaps we should drop the "non-absolute
IRI" fault - treat it as a malformed IRI
... include the non-relative information as a detail information
Marc: should we have a subcode for SOAP 1.2?
DaveH: good idea - perhaps we should use subcodes for several
Marc: we already describe detail content for some of the faults - relationship of the existing content to these new contents?
DaveH: discussing particular cases
Marc: make the new content siblings to the
existing content?
... the text is rather generic at the moment - we would need to be more
specific. This is a reason why this proposal seems "inadequately baked".
DaveH: that's why I'd prefer to make this an appendix
Chair: appendix or separate document? Appendix must be included when going to CR; separate document can be published any time
Chair: does moving the details to appendix / sep document affect CR?
Marc: can have multiple detail elements - perhaps leave current detail content in first detail element, include this new stuff in extra detail elements?
Omnes: discussion of separate document vs
including in spec; discussion of process
... discussing mechanism for including this into the spec
Chair: need a volunteer to lead a short-lived group to design this proposal - preferably someone other than DaveH - coordinate with Marc to ensure inclusion of his ideas
Omnes: guilty shuffling
Chair: we'll convene some people at lunch to attack this problem.
Marsh: perhaps we can build some of the differences between Faults into the names of the properties, and make things more generic
DaveH: that makes sense
Marc: we have some of that already
Umit: can be issues with using sibling elements
DaveH: nervous about including this stuff right now because it needs refinement
<Zakim> Marsh, you wanted to ask about @property
Chair: we'll meet at lunch and discuss tomorrow.
<uyalcina> I would prefer child elements since the parent contains info about the property already
Chair: break now - back at 11am - will move on to LC20
Chair: break REALLY now
Restarting
Chair: originally raised by Jonathan - clarifying the semantics of the anonymous URI
Proposal by DaveH
<mnot> http://www.w3.org/mid/42D8778C.9040402@tibco.com
DaveH: introducing the proposal
... a selection of symbolic URIs - starting with anonymous vs sender
<Zakim> Marsh, you wanted to note this proposal has little relation to the original comment.
Marsh: this does not address the original issue, indeed, it seems this was deliberately NOT the intent
DaveH: thought the complaint was that anonymous was too vague; introduced sender to address the sending of a message down the back-channel (if any)
Chair: would it be acceptable to say this is addressed by the binding? Push it to the binding document?
Marsh: would be happier to close with no action
DaveH: but then we have no hook to hang the
back-channel on
... better to have sender to use for this
Glen: could make this a feature of the underlying binding - HTTP supports this feature
DaveH: but "sender" can go further
Paco: the core can specify that the meaning of anonymous is specified by the binding
<Marsh> +1 to Paco - not gaining much.
DaveH: but anonymous can be different from sender, defined by binding
Chair: do more people feel that anonymous should be stated in the core as meaning defined by the binding
DaveH: problem - anonymous being defined by the binding could change the meaning of an address when moving from one binding to another
Umit: discussing difference between anonymous meaning "deferred to another spec" and meaning "out-of-band"
DaveH: but anonymous is used for "out-of-band" today
Discussion of current meaning / possible meaning of anonymous
Lots of discussion of value of "sender"
Anish: wondering if we should remove the anonymous URI altogether from the core spec, and defer it to the SOAP spec
<Nilo> I'd like two
<prasad> +1 to two
Straw poll: Do we need one URI, two URIs? One: 7ish, Two: 5, Abstain: 4ish!
SteveW: should we define just one URI, but allow the definition of more at a later time?
<steve_winkler> ala our wsa:RelationshipType...
discussion on meaning of anonymous once we have a new "sender"
Chair: if we do have sender, should ReplyTo / FaultTo default to sender
Omnes: Yes
Anish: if we move this to HTTP, and say what it means, what do we lose?
Marc: we lose ability to default in the core - must move infoset to the SOAP binding
Paco: so we only care about the SOAP / HTTP
case? What about SOAP / TCP?
... we must define this again in each binding document?
Anish: yes
... they are free to define what this means in their case
Umit: the anonymous URI is a forward pointer - must look at the binding document to determine meaning
SteveW: we should point out that we support multiple IRIs explicitly
MNot: always thought that was implicit
JeffM: if we go down this path we must ensure we define the IRI in all the bindings we define
Marc: we can define anonymous in core / specify its meaning in binding
Chair: we define one or more URIs in the core, defer semantics to the binding (except for "none" - defined in the core)
Omnes: yes
Anish: per underlying transport binding we have
a meaning of the IRIs
... can we have just one, and call it "sender"?
TonyR: No, because sometimes we want to send the request to "anonymous" - that's not the same as "sender"
<anish> +1 to one anon URI
<RebeccaB> Another +1 to one anon URI
Discussion of whether sender is useful / required / desirable
TonyR: can we specify in the core that an underlying transport binding must define the Anonymous IRI?
Anish: cannot require the binding to define the anonymous IRI, because the binding may not permit the use of anonymous - perhaps "the underlying protocol binding must specify the semantics of the anonymous IRI"
circling discussion - difficult to capture
TonyR: how do we distinguish symbolic IRIs from real addresses?
Chair: you require an enumerated list of the symbolic ones
SteveW: how do we define something like a special IRI for the use case Glen suggested (determine the address from the digital signature) - do we give it a new symbolic name?
Paco: anonymous can cover that
Anish: if that travels over HTTP, how do we distinguish these cases?
<steve_winkler> Slgiht correction: there are two semantics overloaded with current definition of anonymous: out of band and transport specific. Defining a URI for each and making the text more crisp, while illustrating that more URIs could be added, might be a better way to go.
General discussion reaching almost consensus on returning to Jonathan's proposal
<Nilo> The IETF makes everything URNs
Chair: so we need a volunteer to capture a proposal for this
<Nilo> That was just FYI
Glen volunteers
<scribe> ACTION: Glen to present a new version of the proposal for LC20 this afternoon [recorded in http://www.w3.org/2005/07/18-ws-addr-minutes.html#action02]
Lunch break to 1:30 US EDT, may extend depending on progress of subgroups
<mnot> Lunch extended for 15 minutes (possibly more)
<GlenD> When the *foo* URI is specified, the underlying transport binding MUST provide a backchannel for the reply message. Any underlying protocol binding supporting the SOAP request-response Message Exchange Pattern (@@uri@@) natively provides such a backchannel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
<steve_winkler> Scribe: steve_winkler
Glen: describes above proposal.
Paco: you're defining the foo URI in the core in the binding?
Glen: No, this means the semantics are defined by the underlying transport.
Paco: That wasn't my understanding of what we
were going to do.
... I think it was clear that we didn't agree on the sender part.
Mark: we kind of came to a place where it was protocol specific.
Paco: It may be transport specific, but it doesn't make the connection that the URI isn't stable/resolvable which is what we have today.
Glen: We could make back channel more specific, by saying that it delivers the reply message to the sender.
Mark: I thought we wanted to be able to use this not only in the ReplyTo but also in the To as a default.
<GlenD> When the *foo* URI is specified, the underlying transport binding MUST provide a backchannel for the reply message. Any underlying protocol binding supporting the SOAP request-response Message Exchange Pattern (@@uri@@) natively provides such a backchannel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
Marc: If that URI is in the reply message, does that mean that you have to provide a back channel for a reply message (reply to a reply)?
Glen: Yeah, you have to deal with that
anyway.
... One option is to say, don't do that.
Marc: It could just be a DWR (Do What's Right).
Glen: That's hard for interop.
Marc: Just act if it wasn't there. Do what you do anyway.
Glen: That sounds fine if we can say that somehow.
Anish: Aren't we getting into trouble by not defining the context. We define the meaning, but not depenedent on where the URI is found.
Glen and Paco go back and forth. Anish adds his 2 cents...
<bob> more like to and fro
Paco: We are trying to give a provisional name for something that doesn't have a name.
Anish: I tend to agree, but we are also saying
something specific when it's used in ReplyTo
... It seems that we're trying to define it in a more general way.
... In the soap binding all we need to talk to is what is done when this URI
appears in the ReplyTo.
... If the same URI appears in To, the SOAP binding has nothing to say about
it.
Glen: Because it's the guy on the other end of the binding.
Paco: you can't make it relative. It's absolute within the context of an exchange.
Mark: 3 proposals
... 1 = act as if addressing wasn't here
... 2 = Transport-specific; 'to the unnamed'
<mnot> When the *foo* URI is specified, the underlying transport binding MUST provide a backchannel for the reply message. Any underlying protocol binding supporting the SOAP request-response Message Exchange Pattern (@@uri@@) natively provides such a backchannel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
Mark: 3 = Transport-specific; 'use the back channel'
Anish: 4 = Combination of 2 and 3.
Glen: Any of these MAPs, they only become interesting in the context of an MEP.
<dorchard> I propose changing "transport" to underlying protocol.
Paco: We want to keep the part about the endpoints for which you can't assign a URI.
Anish: Weren't we going to remove the part about NAT, DHCP, etc?
general nods of agreement by the group.
Glen: This text isn't so bad, it just doesn't
say what to do in Req-resp over HTTP.
... We just need to capture that somewhere.
Anish: Why can't we just say that in the SOAP binding?
Glen: Am I allowed to send it somewhere other than up the http resp when anon is in the replyto?
Anish: No. You have to send it back on the back channel.
Glen reads to himself out loud.
<bob> And the binding said unto the transport I AM THAT I AM: and it said, Thus shalt thou say unto the children of thy message I AM hath sent me unto you.
Mark: Would we put that in the core or the soap
binding?
... Do we need something for the to?
Marc: If we do that, we'll need to talk about whether it's an HTTP Req or an HTTP Resp.
Umit: We need to say something in the SOAP binding that relates it back to the anon URI that is defined in the core.
group wordsmithing ensues.
<mnot> Core: http://www.w3.org/@@@@/@@/addressing/context-specific
<mnot> Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the context of use; e.g., in a binding of Addressing to a specific protocol.
<mnot> SOAP Binding:
<mnot> When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
<Marsh> @@URI@@ is .../context-specific?
Paco: It should still be 'anonymous' and not context specific.
<Marsh> +1 to anonymous
Anish: Why do we use 'context' instead of transport binding?
Marc: Why can't we say in a protocol to which WS-A is bound?
<prasad> +1 to anonymous; BTW, where is this text going in the spec?
<mnot> Core Table 2-1: http://www.w3.org/@@@@/@@/addressing/anonymous
<mnot> Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol.
<mnot> SOAP Binding:
<mnot> When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding provides a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
Rebecca: what is the optionality on the word 'provides'?
Glen: In the first sentence, MUST is ok, in the second, it's ok.
DaveO: When it says any underlying protocol
that supports SOAP req/resp MEP, this could cause problems...(sorry dave,
couldn't quite catch)
... It doesn't work to use anonymous in that case.
Anish: If you're using WSA to enable that, you'll never use it anyway.
DaveO: That's my point.
Glen: You have to separate your concerns.
... If you try to overload it, it's inappropriate.
... If you want to do something else, that's fine, because it correctly
layers under the SOAP MEP.
Anish: If you did overload, your binding would prevent you from doing anonymous.
DaveO: What's the point of the second sentence?
Glen: We're trying to resolve LC20, it's never
specified how to send a response for http on the back channel.
... This tells you that the reply message is going to go in the response
because of the req/resp MEP.
... For Req/Resp MEP, there exists a back channel for every binding.
<mnot> Core Table 2-1:
<mnot> http://www.w3.org/@@@@/@@/addressing/anonymous
<mnot> Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol.
<mnot> SOAP Binding:
<mnot> When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding MUST provide a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
Glen: At least this way, we cover all transport bindings...
Umit: One of my concerns is that we have covered SOAP 1.1 and 1.2, and I don't like that to be explicitly called out.
<dorchard> I wonder about the use of the word "channel". I'm thinking of Umit's "two connection" binding, and whether another http connection is a "channel"
<prasad> Does the binding need to "define" the precise meaning of the URI?
DaveH: If you're doing req/resp and you switch transports, you're still probably ok.
Mark: Can I get a show of hands as to who cares
about this distinction.
... result = 3 people. Let's resolve this quickly.
Umit: I just didn't want to tilt it towards SOAP 1.2. With 1.1 there is no definition of MEP.
Glen: describes some crazy cars versus bike transportation analogy.
Mark: straw poll. A, B, don't care.
<dorchard> I don't see umit b
<mnot> Core Table 2-1:
<mnot> http://www.w3.org/@@@@/@@/addressing/anonymous
<mnot> Some endpoints cannot be located with a meaningful IRI; this URI is used to allow such endpoints to send and receive messages. The precise meaning of this URI is defined by the binding of Addressing to a specific protocol.
<mnot> SOAP Binding A:
<mnot> When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding MUST provide a channel to the specified endpoint. Any underlying protocol binding supporting the SOAP Request-Response Message Exchange Pattern (@@uri@@) provides such a channel. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
<mnot> SOAP Binding B:
<mnot> When (@@URI@@) is specified as the address of the ReplyTo or FaultTo EPR, the underlying SOAP protocol binding MUST provide a channel to the specified endpoint. For instance, the SOAP 1.2 HTTP binding (@@uri@@) puts the reply message in the HTTP response.
<yinleng> don't care
A - 6
B - 1
<mlpeel> don't care
<dorchard> upon reflection, glen is right about A.. It does work for the 2 connection binding
<Marsh> don't care
<GlenD> ...as long as the binding correctly implements the req/resp machinery itself
C - 13
Mark: final thoughts? Does anyone object to this as a resolution?
RESOLUTION: Option A is accepted as resolution to LC20.
Jonathan is on the phone and doesn't object.
Anyone object to closing I50 (replyTo, FaultTo issue), we needed to reopen that to close LC issues.
Group affirms that I50 is closed.
RESOLUTION: I50 is closed for the same reason that the related LC issues were closed.
<mnot> http://www.w3.org/mid/012FE7D1-0024-4F98-8849-50ACDE73E524@Sun.COM
Marc: Fixed editorial topics from Hugo. Also
put in two versions of the establishing EPR trust.
... Main controversey is whether we should specify normatively how people
should determine the trustworthiness of an EPR.
... If we just made it an example, we wouldn't have to test it in CR and we
wouldn't have to go into great detail.
... downside is that we don't have a standard way of determining a minimum
level of trust and people won't implement it.
... I favor defining it normatively and going into more detail if
necessary.
Hugo: I like non-normative because normative
requires great level of detail and security expertise and review from the
security community.
... We don't have the necessary expertise in the working group. Rich and
Abbie (security experts) agree.
Anish: Do you smell a note?
Hugo: We could make a note.
Anish: The note could provide those details and separate it from the timeline that we have here.
Marc: Someone will end up doing this. We are defining the protocol and should specify how we secure it. If we don't, WS-I or some other group will.
Anish: Do you think we need more details, and if so, should that be in the main spec?
Marc: Yes and yes.
Phillipe: Could it be made into an appendix instead?
Marc: A note would be acceptable. General standards consumer doesn't really differentiate.
Mark: So we have a packaging issue, but you want to have something you can normatively refer to.
Hugo: I would prefer not to have this in the main document. It will have a major impact on the timeline of the main document.
Paul: It would be useful if such a document was produced by CR for testing purposes.
Mark: If we were to decouple, would we want to include the non-normative in the spec and the normative in the note?
Marc: Yep.
Phillipe: We would need to invite other people.
<pauld> Philippe expresses concern about participation from security experts
Bob: There are many mechanisms, and they're very complicated, so I don't think that the normative version will work in this document.
Marc: I should point out that there is no requirement to implement security.
Bob: I don't think that a normative version can be right or complete for this document.
Marc: Having something rather than nothing seems valuable. It wouldn't be the only one, but it would be the one defined in the spec.
Mike: The second paragraph, doesn't seem necessary.
Marc: It was there only if we don't do anything else. If we have another note or something, it can go.
Mark: Seems like we're leading towards number 2.
<dorchard> I would have liked to say something like "If you are going to use ws-security, here's what you must do".
No objections, version 2 becomes basis of discussion.
Mark: To do a note, we'd have to write it and
agree to publish it, but we don't need a charter change.
... If we wanted to make it a rec, we would have to consult the team, the
group, etc.
... Notes don't fall under the patent policy, but recs do.
Mike: I think we should do a note, and include security, etc. almost like a primer.
Bob: These things will be used in a higher level protocol. Security issues are going to be relevant for these higher level protocols as well.
Marc: Yes, but there are specific things that ws-a introduces.
Umit: Why is it only limited to ReplyTo and FaultTo, shouldn't Action or ReferenceParams be included as well.
Marc: It does.
DaveO: I didn't like mandating security, but I would like to say if you use WS-Security, do it this way.
Marc: Second paragraph is ok, but I won't lie down in the road.
<mlpeel> I don't have a problem with it
<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0115.html
Mark: Are there modifications/suggestions for any other part of Marc's security section proposal?
Hugo: The problem I had was point 2 said that
to trust and EPR you need to trust the EPR source and that this source had to
have authority over the uri of the EPR.
... However I may not have authority on the service, but you still might want
to trust me, and therefore the EPR.
... There were 3 aspects for deciding trust (may not be exhaustive): trusted
source, epr source has authority, address of epr is a trusted destination.
Tony: I'd be concerned about DOS.
Hugo: as rsalz put it, trust is not black or white.
Paco: How about Refps?
Marc: they're just opaque, right?
Paco: When we say the source, this should be
the minter, but with refps this may not be the case.
... Isn't a problem to trust the source of the EPR and not care about the
source of the runtime message?
Hugo: I always thought there were 3 actors: minter, source, and recipient.
Marc: It's who I'm getting it from that matters.
Bob: All the words around trust here have nothing to do with the application semantics of the message.
Marc: Not true, we say that the EPRs have to be cryptographically bound to the message.
Bob: round the clock trading use case. trust
mechanism to authorize trading has dimensions well beyond signature of a
particular message.
... We may be conflating the issues of EPR integrity and trustworthiness.
Marc: I don't think so.
Bob: I do.
... Is it proper to be concerned about the potential abuse of the EPRs
independent of the security of the message?
... By combining them I think we're having conflicting statements.
... I don't think that we can trust a message just because we trust an
endpoint.
Marc: I don't either, and I don't think we're saying that here.
Bob: It needs to be more explicity.
DaveH: Don't attribute to malice what can be explained by stupidity.
15 minute break. Will reconvene at 3:40
<dhull> (Meaning, some "security" scenarios can come up through simple mistakes, not just security breaches. E.g., bad code causes an authorized sender to flood the network)
<Marsh> (But in the name of security, we have to assume the worst...)
<plh-bedford> [starting again]
Resume discussion of Marc's security proposal
Paco: I'll send minor edits to the list.
Bob: The intro has to do with the fact that
security implications for applications dealing with one or more protocols go
well beyond anything we can state with these elements.
... Essentially it's trying to carve out that this relates not to the
complete application or whole protocol stack, but is merely one part of the
solution.
... It's kind of a disclamitory intro.
Mark: Any objections to that?
... Fairly editorial, so Marc and Bob will take care of it.
<prasad> I am good
Mark: Any objections to accepting the proposal as the resolution to the issue?
Hugo: My comment was substantive, is it included?
Mark: yes.
RESOLUTION: Proposal accepted as
resolution to LC 87.
... Proposal accepted as resolution to LC 55.
Glen walks through proposal.
http://www.w3.org/mid/80A43FC052CE3949A327527DCD5D6B27012975A9@MAIL01.bedford.progress.com
Prasad: It's not clear to me that core properties that are already defined can be extended.
Glen: You can extend the existing properties as well as add new ones.
<prasad> Good for me
<mnot> An endpoint reference is a collection of abstract properties. This
<mnot> specification defines a core set of properties, but it is also possible
<mnot> for other specifications to extend these and/or add other properties. The
<mnot> semantics and XML Infoset representation (see next section) for any such
<mnot> extension properties will be described in their defining specifications.
Mark: What about the pseudoschema issue?
Glen: Unless there are objections, I'd be happy to let it drop.
A discussion about the pseudo schema ensues.
Jonathan: You end up blowing up your pseudo
schema, so I don't think it's the best place to define the extension
point.s
... pseudo schema should be very constrained
Nilo: Is it necessary to add a cautionary note that any extension should not change the semantics of the core defined here?
<GlenD> Glen: Can we add something that describes (in the definition of the pseudo-schema) that extensions are omitted for brevity and may exist.
<prasad> think we allow that no?
Mark: I think the answer is no because we already tell people to be careful about that.
Umit: This proposal is only for 2.1 and about EPR, right? Not about the other MAPs?
Glen: Correct.
Anish: I found a pseudo schema related issue:
For MAPs we don't express the cardinality, and I thought it would be useful
to put it in there.
... Specifically, e.g. Action is one and only, but relatesTo cardinality is
defined but not in the pseudoschema.
... My specific proposal was already posted to the list.
<mnot> LC 101/104
<mnot> Section 2.1, first sentence - replace with:
<mnot> An endpoint reference is a collection of abstract properties. This
<mnot> specification defines a core set of properties, but it is also possible
<mnot> for other specifications to extend these and/or add other properties. The
<mnot> semantics and XML Infoset representation (see next section) for any such
<mnot> extension properties will be described in their defining specifications.
<mnot> Before example, add:
<mnot> NOTE: Specifications which describe extension elements or attributes
<mnot> used to augment the above model will explain any effects those
<mnot> extensions may have on the abstract properties. They may affect either
<mnot> the core properties or extension properties as defined in section 2.1.
<mnot> In Notational Conventions:
<mnot> Clarify that extensibility is implicit in pseudo-schema
<mnot> <wsa:To>xs:anyURI</wsa:To>?
<mnot> <wsa:To>xs:anyURI</wsa:To>
<mnot> LC 101/104
<mnot> Section 2.1, first sentence - replace with:
<mnot> An endpoint reference is a collection of abstract properties. This
<mnot> specification defines a core set of properties, but it is also possible
<mnot> for other specifications to extend these and/or add other properties. The
<mnot> semantics and XML Infoset representation (see next section) for any such
<mnot> extension properties will be described in their defining specifications.
<mnot> Before example, add:
<mnot> NOTE: Specifications which describe extension elements or attributes
<mnot> used to augment the above model will explain any effects those
<mnot> extensions may have on the abstract properties. They may affect either
<mnot> the core properties or extension properties as defined in section 2.1.
<mnot> Section 3.2 example:
<mnot> add cardinality to pseudo-schema
<mnot> In Notational Conventions:
<mnot> Clarify that extensibility is implicit in pseudo-schema
Jonathan: I thought we had a link to the notational conventions in the WSDL spec.
Marc: It says to use BNF conventions
Umit: W3C should spit out a pseudoschema spec.
<mnot> ACTION: Jonathan to coordinate w/ WSDL to make sure notationalo conventions are synced [recorded in http://www.w3.org/2005/07/18-ws-addr-minutes.html#action03]
Anish: In my opinion if you write a spec that claims it is extensible, then you have to show how it should be extended.
Glen: I wouldn't be averse to adding some kind
of example.
... The issue for providing a framework is a separate one that is already
closed.
Anish: I have a problem with how you can do
extensibility with infoset.
... I don't know how to map that to abstract properties.
Glen: This just says that whoever extends the spec needs to tell you how to do it.
Anish: But you're making it someone else's problem.
Glen: But it has to be someone else's problem.
<Marsh> +1 to Glen. Extensions are by definition someone else's problem.
Mark: Does anyone object to the resolution?
Anish objects.
Roll call vote ensues.
<uyalcina> yep
18 yes
1 No
<hugo> the No vote is Oracle
RESOLUTION: LC 101 and 104 closed with the proposed resolution.
Mark: Several people mentioned that there were
use cases around this property and removing it could be considered a
substantive change.
... To remove it we still need to vote, but this kind of gives us an out.
... My opinion as chair is to mark it as a feature at risk so that we don't
knock ourselves back to working draft.
Marc: Colleagues at liberty alliance are planning on using it.
Mark: We could mark it so, and get comments
later that there will be formal objections if it's removed.
... The only argument against would be that we don't internally define any
use for it.
Marc: True, but we do that for others as well. I'm just saying that we know it's necessary, why take that step.
<Marsh> +1 to mark at risk. We prefer to drop it, but not at the expense of the schedule. Marking at risk should flush out the constituency, or show it doesn't have one...
<Marsh> Proxy to Paco again. Back in 45 min, but you might be done by then...
Bob: There is a potential security use there.
<prasad> Wonder what action we would take if there is in fact an objection to removing the source endpoint
Marc: In liberty, they want to use the metadata bucket to add information about who the message was from.
<dorchard> +1 to "do something"
<Nilo> did he say comfortable or UNcomfortable?
<Nilo> i'd like to leave it in
<hugo> Previous discussion at http://www.w3.org/2002/ws/addr/4/dec-f2f-minutes.html#item20
<pauld> chad, new poll
<chad> new poll
<pauld> chad, option 1: Flesh it out
<pauld> chad, option 2: Mark at risk
<pauld> chad, option 3: drop it
<pauld> chad, option 4: Status Quo
<pauld> chad, question: options for LC5
<pauld> chad, question?
<pauld> chad, options?
<RebeccaB> vote: 4,2,3,1
<mlpeel> vote: 2, 1
<marc> vote: 4
<dorchard> vote: 1, 2,3
<prasad> vote: 1,2,3
<TonyR> vote: 2, 4, 1, 3
<hugo> vote: 2, 4, 1, 3
<Nilo> vote: 4, 1, 2
vote: 2, 1, 4
<TRutt> vote: 2,3,4,1
<dhull> vote: 1, 3, 2
<GlenD> vote: 2,1
<PaulKnight> vote: 2,1,3,4
<pauld> vote: 4, 2
<jeffm> vote: 1, 2
<Paco> 2 4 3 1
<anish> vote: michael: 2, 4
<bob> vote: 1,2,4,3
<Paco> vote: 2, 4, 3, 1
<pauld> chad, count
<chad> Question: options for LC5
<chad> Option 1: Flesh it out (5)
<chad> Option 2: Mark at risk (9)
<chad> Option 3: drop it (0)
<chad> Option 4: Status Quo (4)
<chad> 18 voters: bob (1, 2, 4, 3) , dhull (1, 3, 2) , dorchard (1, 2, 3) , GlenD (2, 1) , hugo (2, 4, 1, 3) , jeffm (1, 2) , marc (4) , michael (2, 4) , mlpeel (2, 1) , Nilo (4, 1, 2) , Paco (2, 4, 3, 1) , pauld (4, 2) , PaulKnight (2, 1, 3, 4) , prasad (1, 2, 3) , RebeccaB (4, 2, 3, 1) , steve_winkler (2, 1, 4) , TonyR (2, 4, 1, 3) , TRutt (2, 3, 4, 1)
<chad> Round 1: Count of first place rankings.
<chad> Round 2: First elimination round.
vote: 2, 4, 1
<chad> Eliminating candidadates without any votes.
<chad> Eliminating candidate 3.
<chad> Round 3: Eliminating candidate 4.
<chad> Candidate 2 is elected.
<chad> Winner is option 2 - Mark at risk
<pauld> chad, details?
RESOLUTION: LC5 is closed by marking the source endpoint and all associated machinery at risk.
Mark: Please come tomorrow prepared to wrap up
any loose ends.
... We'll target final spec on Thursday, people can look at it and we can
vote to go to CR on Monday.
Hugo: When we decided to use XML Schema and
whether it would be normative or not, and limited ourselves to XML 1.0,
because XMLP did the same.
... There has been push back. This would mean changing a couple of sentences
in the core to say that we use XML 1.1.
... Our schema isn't as complex as say WSDL 2.0, we could just say that it's
1.1 and leave it.
Mark: This is the W3C looking at the overall stack.
Hugo: The pushback, we have linked certain
versions of tech to certain versions of other tech and there's a cascading
effect that is a problem.
... At an abstract level there is no reason to constrain to a particular
version, but at a binding level certain specifics may want to be included.
Paul: We've cited versions for WSDL and SOAP, but not XML.
meeting recessed