See also: IRC log
<RebeccaB> :-)
<scribe> Scribe: Bijan Parsia
Marsh: minutes out late, will
enteratin postponing approval?
... Minutes approved
Marsh: Glen and Umit's primer AI...we can publish without them, but can we drop them?
Glen: We can drop mine, but I'll still do it later
Marsh: Umit? any objection to dropping it? No. Good.
Tomj: Hey! Maybe I care about that. Where's the agenda?
Marsh: It's trivial; let's not sweat it
Scribe notes that he is taking licence in the dialogue :)
Marsh: DaveO's LC121 is done
Discussing Paul's AI about Common Schema structures
Marsh: Profiling schema for data binding would be objectionable to MS
pauld: it's not really profiling for databinding, just conventions that might help
Marsh: Well....it's different.
pauld: Will wrap up this week
<GlenD> +1
Marsh: Getting a thought through
draft done is probably work it, e.g., for getting picked up by
other wg
... Hope to have enough to do a F2F
... Amy's AI?
alewis: in progress
Marsh: Register for F2F!
RebeccaB: What about telecons in Aug?
<pauld> cites proposed working group for XML Schema patterns for data binding: http://lists.w3.org/Archives/Public/www-ws/2005Jul/0000.html
Marsh: we'll take traditional break. Some work may continue.
Glen: We really need to know who's coming so we can decide the room!!!
Marsh: I'm hoping to hit last
call (or have hit lc) here
... Bijan (for rdf mapping) at F2f?
Bijan: Perhaps second day only.
Marsh: Still work on primer.
DaveO objects to LC publishing "part of" the primer
... So, delay the vote
... so let's make progress on the rest of the documents
today
... Delaying 121 until the end of the call so we can get
through other stuff.
<sanjiva> hi Guys .. apologies for being late .. just joined :(
<JMarsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0096.html
Marsh: Bijan sent email but it wasn't clear if it was just discussion or proposal for text
Bijan: It was proposal for text for discussion
<dorchard> I will attend the f2f by telephone, and live with the difficulties
Arthur: What are we talking about?
<Arthur> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/altschemalangs.html
Bijan: We factored out Appendix E. This is to augment it slightly with a bit of dicussion
Arthur: Is the propsoal to add this text?
bijan: yes
sanjiva: is multiple languages a common use case?
Marsh: Bijan had some use cases
Bijan: it was just to document for possible extension authors
sanjiva: I'm in favor of writing this stuff done.
<pauld> Dare Obsanjo wrote an MSDN article on extending XML Schema with Schematron: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxml/html/schematron.asp
ACTION bijan to add text to alt schema examples
Tomj: I would like to strengthen the "don't do the multiple definitions in different type system" warning
bijan: sure
Marsh: with that, we'll be done with Alt Schema language
Marsh: LC5a
jjm's email: http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0021.html
Marsh: so, we've addressed subissue a and b, and the wg doesn't want to define anything regarding WSDL processor. Does the group concur?
group: cricket sounds
Marsh: Ok, I'll so respond
... LC5f
... Still on processors. We're not going there. basically the
same as 5a.
... LC9
... Glen responded a while back. I sent a note on the 28th of
June...waiting on a reply.
... So, propose that objection is mooted.
... LC51
... It's an empty issue, since the details hasn't been received
despite numerous pings. Leave it open but dead.
... LC73
... Single interface per service is the settled opinion of the
group. So just defend this decision to the director.
jjm: concur, plus we have text in the primer
Marsh: 75f
... Oops, that's mine and I still have work to do :)
jjm: I think the offending sentence is gone.
Marsh: No, I think it's in
there
... Desire to allow attr extensibility in many places (e.g.,
signing)
... the concern: if we don't allow attr extensibilty as
infrastructure, we'll limit future stuff. Can we allow them
*only* for infrastructure and not application?
Arthur: Isn't signing in headers?
Marsh: no, it requires IDs on elements in the message for the parts you want to sign
Arthur: Eeek!
Marsh: also, things like xml:base and xml:lang
Arthur: None of those are convincing for SOAP messages
Marsh: yes, but we should allow for extensibilty. We don't want such attributes to show up in the function signature, but isn't enough to say that such attr don't so show up?
sanjiva: How do we distinguish infrastructure from data?
Marsh: We can put the exception into the mapping, rather than forcing the schema this way
sanjiva: another workaround, style can be a list so we can overlay
Marsh: that doesn't work because list are unions, so can't retract a constraint
sanjiva: so, qualified attributes will be ignored (for style purposes)
Marsh: something like that.
sanjiva: don't want to do it, but it probably wouldn't hurt to do it
Arthur: I'll entertain a concrete proposal
<JMarsh> ACTION: Jonathan to come up with concrete proposal for 75f [recorded in http://www.w3.org/2005/07/07-ws-desc-minutes.html#action01]
Marsh: LC75v done. LC76a.
<scribe> ACTION: bijan to add text to alt schema examples [recorded in http://www.w3.org/2005/07/07-ws-desc-minutes.html#action02]
<jjm> <current section="2.2.1">
<jjm> Any message after the first in the pattern MAY be replaced with a fault message, which MUST have identical direction. The fault message MUST be delivered to the same target node as the message it replaces, unless otherwise specified by an extension or binding extension. If there is no path to this node, the fault MUST be discarded.
<jjm> </current>
<jjm> <current section="2.2.1">
<jjm> Any message, including the first, MAY trigger a fault message in response. Each recipient MAY propagate a fault message, and MUST propagate no more than one fault for each triggering message. Each fault message has direction the reverse of its triggering message. The fault message MUST be delivered to the originator of the message which triggered it, unless otherwise specified by an extension or binding extension. If there is no path to this node, the fault MUST
<jjm> </current>
<jjm> <proposed section="2.2.2">
<jjm> Any message, including the first in the pattern, MAY trigger a fault message, which MUST have opposite direction. The fault message MUST be delivered to the originator of the triggering message, unless otherwise specified by an extension of binding extension. Any node MAY propagate a fault message, and MUST not do so at most once for each triggering message. If there is no path to the originator, the fault MUST be discarded.
<jjm> </proposed>
<sanjiva> +1 to making things easier to read
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jul/0021.html
(search for section="2.2.2">)
alewis: confused about second to last sentence in the proposed section
Marsh: Making 2.2.1 and 2.2.2 more consistent with each other, but I though the commnent was to make it more consisten with the definitions in 2
alewis: I like jjm's 2.2.2 more
than the current text.
... I would accept this (with clarification of that confusing
sentence) as editorial
Tomj: moi aussi
... you are ubercosmopolitan. You are cosmopolitionesque
Oops
scribe's last Tomj was meant to be /me d :)
Marsh: LC76c
<JMarsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0093.html
alewis: doesn't this effectively say "nofault for security purposes"?
Marsh: What if I have a blacklist of known bad address to which I don't send faults but I'm willing to send it elsewhere
sanjiva: isn't this true of all messages? Why do we need to call this out? It's not fault specific
Marsh: But we want people to be able to use blacklists conformantly
sanjiva: but it is generic. why the fault harping/
Marsh: Proposal, let's not add anything, but say that the spec doesn't forbid you taking security considerations seriously
alewis: doesn't this belong in
the security considerations section? There's a slew of things
for which, if you've detected an attack, you might want to
depart from advertized behavior
... do we even have an security consideration section? No?
perhaps we should add one?
sanjiva: let's not go there
<sanjiva> sanjiva: if someone wants/wanted to do it they could make the request for security considerations
Marsh: I'm not feeling that the wg wants to add text like my proposal, so let's just express our intention not to block security stuff
Tomj: I support the not adding text route
alewis: if we're going to do this, I'd perfer to have a security considerations section
Marsh: should we go to the list to try to develop that proposal?
<charlton> charlton: +1 to not adding text
sanjiva: Separate it. Someone should raise a lc comment for this if they want a security considerations section
Marsh: I'll take up the ai with the issue raiser.
sanjiva: just raise it with the text as a LC issue. Then we can pop it in.
Marsh: but we need to address the
current LC comment
... would anyone object to the very notion?
<charlton> charlton: I don't object to the prinicple
<scribe> ACTION: JMarsh and alewis to come up with a proposal for a security consideration section that would also address this issue [recorded in http://www.w3.org/2005/07/07-ws-desc-minutes.html#action03]
<sanjiva> +1 to Arthur's comment!
arthur: I object to the very
heart of this issue. The security issues should be handle at an
entirely different layer, not as part of the application and
tthe description thereof
... You're descripting a web service...they have to generate
the described fault behavior!
alewis: Also, what happens when you expect the described fault and you don't get it...what do you think? When you have conformant non-conformant behavior because, well, you have *reason* to be non-conformant. Better to handle security at a different level, where those consideration *trump* conformance (e.g., the attackers aren't mainline clients)
<charlton> charlton: I think it is valid to speak of security issues while not providing for "complete coverage" in some text, but I think that it w/b impractical
Marsh: arthur, what should we do? Not do security consideration?
arthur: I think that silently generated and logging a fault and not sending it when you are supposed to is wrong
alewis: a security considerations section is still good practice
<charlton> IMHO a security consideration section would be valid coverage in the spec.
arthur: I'm not objecting to a sc section per se. I'm objecting to the particular way of handling it under discussion.
alewis: can we leave the argument until we have some concrete text
Marsh: arthur, you are discussing the original proposal/comment. We've not accepted the whole "you can log a fault" bit. We're trying to figure out how to deal with the security situation.
<charlton> let's see the text that Jonathan and Amelia develop and reconsider....
arthur: Yes, but sanjiva pointed out that this holds for messages. i want meps to be clean with security factored out
Marsh: that's the text we are
tasked to develop
... LC76d
Glen: let's remove it!
Marsh: that's where I was going
scribe lost the discussion
scribe still lost the discussion, or lost in the discussion
Marsh: Take it to the list. I'll get the discussion going
sanjiva: I'm fine moving forward. I don't want to prolong it
Marsh: Any objection to removing this header?
Tomj: But wait! It was in WSDL 1.1!
Glen: It's a server side issue, mostly.
Tomj: So you expect no ripples from removing this?
Marsh: this is new to this last call, so it'll receive attension
<anish> tom, r u saying that u can specify mU in wsdl 1.1?
Tomj: Yeah! So we added soap headers back, now we are going to rip some part of it out?
Marsh: The mustunderstand is
redundant
... the issue is mustUnderstand on soap:header. Explain it, or
remove it
... by describing the header in the wsdl it already is
required
dorchard: How about when the service doesn't change but the service hasn't? So the client revs too.
sanjiva: shouldn't the wsdl change?
dorchard: well that's one view. But the contract can be used to force upgrades on both sides (scribe isn't clear)
dorchard would object to removing
<scribe> ACTION: dorchard to provide an explanation of mustUnderstand on wsoap:header for the primer [recorded in http://www.w3.org/2005/07/07-ws-desc-minutes.html#action04]
<pauld> wonder if describing soap:mustUnderstand is useful in the use-case where the WSDL is published by a consortia to be implemented by a number of different services?
Marsh: is adding stuff to the primer a resolution of this issue?
Glen: no
Marsh: ok, we'll wait on text to
close this issue
... out of time!
... Let's get email progress on LC 124
... Aim for resolution next week
JMarsh, I'm rusty on extracting the minutes