See also: IRC log
<dhull> scribe:dhull
Glen: Adding embedded WSDL is good, metadata is maybe dodgy
Chair: Metadata discussion is secondary
Marsh: different idea of how WSDL
material should be split amongst docs. Extensibility for WSDL
is core, actual extensions incorporating WSDL is WSDL.
... Or (MarcH) everything WSDL goes into WSDL.
Marsh: Would be nice to have
extensions to the core already in.
... It would also be nice to have just one conformance
statement per doc. E.g., WSDL conformance covered solely in
WSDL conformance doc.
... Should supporting service name etc. be part of core WSA and
its schema? Yes.
GlenD: But if it's extensibility, it doesn't matter.
MarcH: If this is in metadata, we
don't need anything special for validation as it's open
content
... Extensibiliy is everywhere anyway.
Marsh: This is an example of
extensibility, so should be mentioned with extensions ...
... Or you could say it's WSDL, so it goes with WSDL. Depends
on which word you emphasize.
MarcH, GlennD: Belongs more in the WSDL (Glen: It's more than just an example of extensibility. It's a full-on WSDL extension)
Anish: Also see it as outside core. It's not absolutely essential.
dhull: WSDL has special status in
WS arch.
... Otherwise lean toward "outside core"
marsh: Inconsistency in namespace of properties (?)
marcH: Noted
GlenD: You can validate without knowing what the data means.
Marsh: Strange to have a schema span specification docs
GlenD: Basic question of how to
modularize.
... Art, not science
Marsh: Still haven't heard compelling reason for split.
Umit: Is your problem basically that this is done in the wsa: namespace.
Marsh: Yes. They're defined in a totally separate document from the wsa: core
GlenD: No harm in having them sitting in the namespace
Marsh: No harm in having them in the core.
Paco: So, do we really want a schema just for this?
Marsh: Timing issues to because WSDL 2.0 isn't done.
TonyR: You're anticipating split between WSDL1.1 and WSDL2.0 binding specs.
Marsh: Even more of an issue then. What goes in which spec?
MarcH: Does it matter?
... Happy to have everything in the same schema, specified in
WSDL docs.
Anish: Core spec can refer to
WSDL1.1 binding spec, then later WSDL 2.0 (?)
... I could use non-SOAP or non-WSDL and still use core. So
this is good (?)
Umit: Don't like the idea of same concept in two different namespaces.
(Anish: This == splitting among separate namespaces (?))
GlenD: WSDL 1.1 carries more extra stuff than WSDL2.0
Anish: Abstract properties are
independent of WSDL version.
... Don't need to invent three different namespaces. One ns for
abstract proprties. Concrete properties stay in their present
ns.
Umit: Are you suggesting two different ns tags for WSDL1.1 and WSDL2.0
Anish: No. Not for abstract
properties. We already have different sections for the
bindings.
... No need to invent new ns.
Chair: Does anyone feel really strongly about this? Seems like editorial tasks.
Marsh: Not just editorial. May need new namespace, which is more than editorial. Implications for conformance.
Anish: Agree not purely editiorial.
Marsh: Right now we're stuck in the middle. NEed to choose.
<umit> +1 it is not editorial
Anish: Core and binding are
redundant now.
... By putting this in core, WSDL is not jus another DL.
... Conformance cuts both ways. Easier for WSDL people, harder
for non WSDL if it's together.
Marsh: If core is WSDL independent, would new NS be OK for shortcut properties (service name, selected interface)?
Anish: That's fine.
Marsh: OK with me, but then we need to be consistent: No WSDL in core at all.
+1 to consistent, no WSDL in core
Chair: Different ns from other WSDL stuff
Marsh: (reluctant) yes.
Umit: Observes that this is all a bit ironic (scribe didn't quite catch the drift)
Chair: Straw poll?
<umit> Today we have these two properties in the core regardless of Issue 24 and issue 26 anyway.
Chair: Acceptable to move WSDL machinery to WSDL doc, and to put version-independent WSDL stuff to new namespace?
TonyR: Relevant to WSDL1.1/2.0 split?
?: Looks orthogonal.
Marsh: Cancel straw poll.
Chair: Is there another proposal?
Marsh: Yes. Friendly amendment to vinoski.
GlenD: If we move things back into core, then we need to move more stuff back in.
Chair: Poll: WSDL in WSDL doc or WSDL in core.
Core: 1, WSDL 10: Abstain: 11
Omnes: Abstentions win!
RESOLUTION: Make sure that WSDL moves to WSDL, new ns for abstract properties.
Chair: Comments on embedded WSDL.
Anish: Really like it. Will this now be normative (in WSDL doc)? Prefer normative part of EPR-related 1.1 extensions, instead of (present) non-normative status.
Marsh: This is getting into
conformance.
... Is it important to keep names consistent with embedded
WSDL.
Anish: It's all extensible. We don't prevent people from doing funky things.
Marsh: There's no MUST here.
Anish: If you inline WSDL you MUST do it this way.
Marsh: MUST what?
Anish: MUST put it in metadata.
GlenD: We say what it means IF it's in the metadata
Anish: Currently it's given as an example.
Marsh: Having example is helpful for interop but no MUST
GlenD: We do tie ourselves to
WSDL for this use case.
... Could also have gone with pure WSA.
Marsh: Not precluded.
Anish: Right now port is optional
service is required. You may have multipe ways of getting at
the same definition (?)
... Can always provide non-normative examples with specific
qnames.
Marsh: Right now no MUSTs.
... Would be good in an appendix.
Ansih: Can do that. Here's an example, this specific problem solved this specific way. But inlining WSDL is broader.
GlenD: In..ter.esting. What do
you do when you see inline WSDL with multiple endpoints. As
alternates?
... There are various ways to interpret (alternatives,
fallback, etc.) Is this a WSDL issue or WSA issue?
Anish: Same issues arise outside WSA. Could solve it in WSDL. Could also solve it as special WSA marker.
Vinoski: Could spend a lifetime trying to specify this.
GlenD: So leave it up to context?
Vinoski: Yes. Leave it up to WSDL.
<dorchard> doesn't seem like a WSDL issue as embedded WSDL is different than standalone WSDL. embeddeding wsdl will constrain the embedded wsdl.
GlenD: +1
<dorchard> it's a ws-a issue..
(GlenD: +1 to vinoski)
Chair: Options: 1) Appendix, non norm. 2) Appendix, but normative?
Anish: Appendices are fine. We can have as many as we like.
Several: It's editorial.
MarcH: OK. I'll take a shot.
Marsh: MUST service/selected interface elements match embedded WSDL. Less pressing if it's all in a separated doc.
MarcH: Could say service/selected is pointing to alternative to embedded. Not recommending this.
Anish: May contain multiple service endpoints. Is that bad?
Vinoski: No reason to preclude.
GlenD: Do we still have selector for service qname? If so would not matter so much.
Anish: Right. Embedded is
additional information.
... E.g. for later
Glen: or naive WSDL processor.
Marsh: Pick whatever you want from embedded and other WSDL (?)
GlenD: Important to be able to indicate that a bit of extensibility is important (wsa:mustUnderstand).
Chair: Roy has an interesting take on this.
Anish: So do we say this means whatever you want it to mean?
Marsh: If you put in hints, they apply to the EPR (?)
GlenD: What if embedded conflcts with something I already no about?
Marsh: How do you reconcile.
Chair: We don't deal with that.
Umit: We can only say that embedded info is self-consistent. Can't go farther.
GlenD: But processors can decide to ignore embedded WSDL.
Paco: Incumbent on minter of EPR (umit: yes)
umit: Client is guaranteed to get consistent info.
GlenD: Guarantee how?
Umit: We require it.
GlenD: Too much to ask (?)
Chair: What if I later add an extension that updates metadata.
Umit: Extension can violate anything.
JeffM: Can't violate spec and still conform.
TonyR: Are you suggesting mustUnderstand
GlenD: yes.
Chair: Not bringing that up now.
Umit: Need guarantee of consistency (?)
Marsh: What is harm if we don't have MUST (be consistent)?
Vinoski: Can't use EPR then. So what? Will there be policing action?
Marsh: And if so, will that be restrictive?
Anish: If I mint an EPR with a WSDL and the service doesn't implement it, is that an error?
Marsh: EPR is unusable.
Paco: WSDL places restrictions.
Embedded WSDL should be consistent (?)
... Don't want to preclude that. Better not to require
consistency.
... May be additional contracts.
Chair: Related to issue 14.
Paco: Enforcing consistency may preclude scenarios we haven't thought of yet.
Anish: Independent of inlining of WSDL?
Paco: Yes?
s/yes?/yes./
Anish: Not specific to embedded WSDL.
Umit: Not comfortable with inconsistent WSDL (?)
marsh, Chair: Change MUST match in (non-normative!) text to SHOULD or should?
<pauld> discussion of relationship with i014: http://www.w3.org/2002/ws/addr/wd-issues/#i014 and i020
Anish: issue of what does it mean to have WSDL-related data in EPR.
Chair: Suggest changing MUST to should.
Anish: Thought this was normative.
Marsh: MUST be downgraded to SHOULD.
Paco: Is this requirement on EPR
minter?
... Clients shouldn't have to check consistency.
Marsh: Consumer's behavior if
didn't match is undefined. Burden is on minter.
... Non-normative appendix to core -> normative appendix to
WSDL, s/MUST/SHOULD/
Chair: Proposal is <above> + move WSDL material from core to WSDL.
Anish: Current text has selected endpoint etc. outside metadata. Doesn't matter if we're moving.
Chair: Core right now is unstructured set of properties.
MarcH: WSDL document will
describe instances of Metadata.
... Metadata is a bag.
GlenD: What is functional difference between inside/outside metadata bag?
Chair: (-hat) If it's just for convenience, what do we say normatively about it (?)
Paco: Question is how do people feel about it.
GlenD: Feel it's silly, want to know what value it adds.
MarcH: Against metdata property or metadata syntax
GlenD: Both. Would be weird to
have mismatch between the two.
... What semantic do we gain here?
Paco: Hopefully people know why it's there.
GlenD: Quetsion is why separate bucket. Why not just put things in the EPR.
GlenD, Marsh: Metadata may have effects on what's on the wire (so not so distinct from properties?)
Paco: May not show on wire at all.
GlenD: Obviously a trick subject, but what is value of distinction.
Marsh: Algorithm: If there is metadata bout endpoint, put in metadata. IF about EPR put outside.
Umit: Exactly.
Anish: IT's the identifier.
Omnes: Anish, leave the room!
Chair: data/metadata is well-known tarpit. Can we focus on data model.
Marsh: Plan of record has redundant information (selected/service)
GlenD: Actually not. Metadata would be /descriptions/
Marsh: As it stands, selected/service would be in metadata.
GlenD, Paco: not good.
Paco: Ref props is also a container. One way is to say the interface/service are refprops (?)
Marsh: Two ways to resolve reduncancy. (remove either part)
Glen: Either top level as properties, or in metadata.
Chair: Charter doesn't require either way (had thought it might)
GlenD: want one or the other but not both (for selected etc.)
Anish: This would appear in metadata only (per split of WSDL from core (?))
Chair: Data model has them as root properties.
marsh: 4 possibilities ...
Anish: If we're using only XML then why do we need abstract properties (why not just infoset).
<pauld> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0198.html
<pauld> PDF: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/att-0198/ws-addr-tag-overview.pdf
Chair: Straw poll: 1) accept duplication 2)special-case WSDL properties so they can't be in metadata 3) WSDL metadata isn't expressed as properties, just in metadata. 4) ....
Anish: what's difference between abstract property and infoset.
Marsh: sort of mixed.
Chair: 4) No metdatata property;
metadata children define their own top-level props
... 5) put WSDL props at top level, not in metadata bucket.
marsh: 5 is closer to status quo, that's about all there is to recommend it.
Chair: 6) WSDL metadat is a subproperty of the metadata property.
umit: What are we enabling by these different choices.
glenD: we had this discusion in WSDL, decided not to go there
Anish: Here we've decided this is XML 1.0. WSDL didn't. Why do we need extra layer?
GlenD: It made sense structurally in WSDL, may here. Infoset does not always map to same abstract structure.
Anish: Here abstract model contains some infoset. WSDL model is completely abstract
Marsh: is it?
Anish: maybe not
Marsh: property vlaues may be XML in WSDL
Glen: Abstract model makes coding easier. Don't need to worry about serialization as XML.
Anish: Infoset isn't abstract enough for you?
Umit: right
GlenD: You havea point
Marsh: Abstraction is good for EPR -> message rules
Anish: Can do same with infoset.
Hugo: SOAP features involved, too.
Several: Can we get every possible issue in here while we're at it?
Chair: Staw poll to narrow discussion?
Omnes: OK
<enter the TAG>
1: 0
2: 0
3: 13
4: 5
6: 5
5: clarify
GlenD: 4 is good because it leads to getting rid of metadata
dhull: point
TAG: Summary of raison d'etre
<DanC_> TAG issue endPointRefs-47: WS-Addressing SOAP binding & app protocols
noah: There is a separate issue
(to TAG) of how are URI being used
... Beyond strict issue 47
<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/att-0198/ws-addr-tag-overview.pdf
(presentation by PaulD -- see link)
<DanC_> (the analogy to email from/to/reply-to is completely new to me, and explains quite a lot. is it in the WG charter? did I miss it?)
<DanC_> (aha... it was there... I missed it... "# Abstract properties to identify subsequent destinations in the message exchange, including: * the reply destination" -- http://www.w3.org/2004/09/wsa-charter.html )
<DanC_> +1 "I dunno what metadata is. it's just stuff"
<dorchard> I did a comparison of ws-md to ws-a at http://www.pacificspirit.com/blog/2004/07/29/ws-addressing%20ws-messagedelivery%20comparison
<dorchard> Dan, specs that I can think of: WS-Reliability, WS-reliablemessaging, ws-eventing, ws-notification, ws-transfer, ws-resourceframework, ws-coordination, ws-enumeration, and more...
<DanC_> er... so how does ws-notification use ws-addressing? I only learned which end of ws-addressing is up 5 minutes ago. I don't know which end of ws-notification is up.
<DanC_> timeline slide... wonderful!
<dorchard> in the eventing systems, like ws-n and ws-e, there is a "subscribe" message that returns a subscription structure that contains an EPR. It may use "ReplyTo" + "FaultTo".
<dims> suppose someone subscribes to a certain topic, they tell the server where (using ws-addressing) to send notifications
<DanC_> ok, that's a good example. is that in a ws-addressing use cases doc? (please? ;-)
<dorchard> nah, no use cases or reqs doc.
<anish> There is also a comparison of WS-MessageDelivery and WS-Addressing at http://lists.w3.org/Archives/Public/public-ws-addressing/2004Oct/0007.html
<DanC_> ("Addressing Infoset" slide... hmm... looks a lot like RDF. I wonder if it can be converted with XSLT)
Stuart: Seems odd to have To: as a URI and reply-to: as an EPR
<DanC_> SW: on "Addressing Infoset" slide, it seems odd to have To as a URI but From as an endpointref.
<dorchard> Dan, it is in xml so....
GlenD: Interesting queston which has been discussed at length.
Noah: Is this recursive?
Glend: No this is infoset of SOAP message
PaulD: Can use EPRS outside addressing.
<DanC_> (er... eek... as W3C/IETF liaison, I need to go tell the IETF we're reinventing email and get appropriate review. sigh.)
Plh: Also have refparams
<dorchard> dan, I'm not *quite* sure it is <email>
<DanC_> yeah, IETF doesn't have a monopoly on deliverying messages
<dorchard> The RefPs (aka Properties/Parameters) is the key extension from URIs, ala cookies.
<anish> on the slide: s/Reference Properties/Reference Parameters
PauD: Intentionally left in policies even if it's not "correct"
Noah: Examples?
GlenD: Object ID. To: URI is fronting a bunch of "thingies"
Several: Snickers and grins
Noah (?): Not sure that ID issue is nailed.
GlenD: Session ID, security info.
Noah: The expectation is I will get back to you with this, with the stuff you told me to echo
<DanC_> (aha! so end-point reference are kinda like closures.)
Omnes: Yes.
GlenD: and they're marked as ref props.
<dorchard> Dan, the ws-addressing authors didn't do a discrete interop event, but it has been used in multiple interop sessions, like ws-rm, ws-eventing, ws-notification, etc.
<anish> paul said identity, i think he meant identifier
Glend: Identically spelled EPRs in different contexts can have different effects.
Chair: As with URI. Sometimes lexical comparison is OK, sometimes not.
TimBL: The two are not the same. Closer to URI refs.
<DanC_> er... was that Noah? in any case, no one person speaks for the TAG here
Paco: ?
Stuart: Endpoint comparison is removed.
Omnes: yes
Dorchard: Common scenario is EPR
exsits in context and protocol around it.
... E.g. subscription contains expiry etc along with EPR.
Comparison is external to EPR.
... Another scenario: bags of EPRS, need to distinguish.
Roy: Security model is arch
issue
... Spoofing of addresses and return addresses.
<end presentation>
<DanC_> RF's security question... issue 4 seems relevant
<anish> security issue is at: http://www.w3.org/2002/ws/addr/wd-issues/#i004
<DanC_> RM: see SOAP binding security considerations section
marsh, Chair: Security is still open
<DanC_> HH has a relevant action
<DanC_> 4. Security Considerations
Chair: There's concern that there are not examples of how to use WSA in a sentence.
Paul Cotton: WSI BSP would speak directly to this.
Unknown TAG member: Should be able to pick out threats and countermeasures from this.
<DanC_> "threats and countermeasures"
MarcH: We do have such a list.
MarcH: Should we provide minimum requirements for WSA.
marsh: Consumer /can/ treat EPRs as opaque, but doesn' have to. E.g., can discard headers that raise security issues.
Noah: Tricky bit is that I can send you an EPR, causing you to represent what I want to someone who trusts you.
GlenD: There should be trust
relationship between EPR provider and EPR destination.
... Marking ref prop soap headers makes them identifiable.
noah: If the destination doesn't know WSA, then it's defenseless.
Paco: Security section calls out possibility of signed EPRs
MarcH: Haven't tackled establishment of trust.
Stuart: Trust is red herring.
Chair: cuts security discussion short
DanC: What /have/ people done with EPR, how do you test it?
GlenD: There have been interops for eventing, WSRF, reliable messaging, which use WS-A (as of a year ago).
DanC: This is testing higher-level protocols
GlenD: Also testing WSA
GlenD, Chair: We do have open issue for test cases. Going slowly.
Jeffm: Hasn't been testing onging.
DanC: We encourage that you do.
TimBL: E.g. formulating issue as test case.
DanC: EPRs look like closures, maybe why they're not just URIs.
GlenD: Not written that way, but
it's not inaccurate.
... There are also policies as well as state/context.
<anish> wrt the security discussion, I think it is worth mentioning that one of the options that the WG considered was to put the reference parameters (cookies) in the wsa:To SOAP header
DanC: There appears to be a body of shared stories here. Eg. email analogy was new. (And as IETF liason I have to tell them to review this)
<noah> Tag issue endPointRefs-47: http://www.w3.org/2001/tag/issues.html?type=1#endPointRefs-47
<DaveO> I posted a comment about mapping most of ws-a (action/replyto/messageid) to HTTP
<DaveO> it's at http://www.pacificspirit.com/blog/2004/12/20/ruminations_on_wsaddressing_and_transfer_protocols
Noah: Appears to call for exclusivity
DanC: It's a pain to put it both places
GlenD: Long-standing issue with SOAP (e.g. action)
Chair: Also issue of
physical/logical address.
... (so To: != physical address).
Plh: SMTP to send to list
<noah> Some quotes from Mark Baker emails:
<noah> And that, in a nutshell, is why I raised the issue... and also why I've
<noah> been so opposed to anything else premised on the concept of "protocol
<noah> independence".
<noah> ...and...
<noah> my proposal was just to remove redundant information, not
<noah> to change the meaning.
Dorchard: Some cases (reply-to:, fault-to:) are tricky w.r.t. qname -> URI mapping
<noah> So, I think Mark has fairly clearly stated that he wants the URI >only< at the HTTP level, not duplicated.
Dorchard: Issue is to make as full use of HTTP protocol as possible, to: is part of it.
Noah: Issue (MBaker) is
"protocol-independence is bad, just use HTTP, don't try to say
things at multiple levels"
... Or, is WSA making good use of the architecture of the web
(?)
DanC: When is wsa:to used when it shouldn't be.
MarcH: It's mandatory.
DanC: Is it typical to use EPR for queries that should be GET.
MarcH: No one knows.
?: When is wsa:to being used to dispatch (?)
Dorchard: WSRF -- a good chunk of what they do is dispatch off of refprop.
DanC: Getting property values is obviously GET.
Dorchard: ALmost no one is using GET for those sorts of thing
DanC: Lots of damage, then.
Chair: Other issues 51, 52
<noah> Noah asks for clarification: Dan, are you asking whether WSA usage is discouraging people from using, for example, the SOAP WEBMETHOD=GET (which was added specifically at the TAG's request?)
<noah> I think Dan said: yes, effective paraphrase of my concern.
<DanC_> yes, that's my question, noah
<noah> Various: but that feature is rarely used anyway.
<noah> Dan: right, so LOTS of damage is being done.
TimBL: As HTTP matured,
flexibility and complicatoin came from header structure
... One delight of building on XML is that it provides nesting
and information hiding (?). Ironic that SOAP is using headers
again.
... When you flag where headers came from, you need it as a
top-level header. Doesn't seem to be clean, hard
structure.
... Boundary between IP/TCP is clean. This boundary isn't.
<DaveO> To a certain extent, SOAP is about mushing the layers together...
TimBL: IT would be nice to have clean layering. So you could say this EPR is used by this layer. Then parties know whether to pay attention or ignore (based on layer).
GlenD: EPRs specifically don't
require knowledge of what's going.
... WSDL policy/assertions say what to do and what you have to
undrestand.
TimBL: Two completely different
architectures being put together.
... Don't guet guarantees of opaque architecture.
<DanC_> (glen and timbl seem to have agreed on something that I missed. darn.)
GlenD: There are already systems that use SOAP headers.
<DaveO> Dan, they agreed that there is less layering, roughly a flattening into soap headers.
GlenD: So data becomes first-class SOAP headers to avoid having to rearchitect.
<DanC_> hmm
Noah: There is no standard for mustUnderstand, but can grandfather to mean, you must use these policies.
Jeffm: Mantra is you can only look at wire, not what generated what's on it. Makes it harder.
Paco: SOAP allows for this building on headre (?)
<noah> I'd paraphase what I said differently: soap has a very clear standard for mustUnderstand. One of the things you can do in your spec for understanding YOUR header is to say that it involves a set of hierarchcal rules.
Jeffm: What if there's an interaction between (?)
<missed comments>
DaveO: Tim's point is valid: SOAP is flattening layers. Unlike TCP/IP. Bug or feature?
TBL: SOAP is clearly underneath everything else.
<noah> Thus, to get what TimBL wants, I claim the SOAP rec doesn't have to change. As Glen Danials said, it's the current SOAP >implementations< and other Recommendations using SOAP to date which have chosen a single layer model.
TBL: No one seems to know further layering.
GlenD: Architecture is that things may be carried by protocol, maybe by SOAP (?)
PaulCotton: What has WSA done in document to address this TAG issue?
<DaveO> noah, I've tried unsuccessfully to get the semantics of 'mU' into other specs, like Atom. The pushback is generally that it's too hard to parse through the entire infoset...
PC: Can someone summarize why you don't consider this an issue.
Marsh: Do we have to bind all the way down to HTTP, or just bind to SOAP (SOAP bound to HTTP)
PC: Are you going to reference this binding
HenryThompson: Should stop at SOAP.
GlenD: SOAP has binding framework. These expose at top layer as abstract things. WSA does not so much say what SOAP should do. Says, we serialize to SOAP.
MarcH: Don't tie WSA abstract properties to SOAP binding abstract properties.
<TBL> (I am not happy with the transcriptions of my points. btw, and the log seems to be 404)
HenryT: A good thing?
Pls review logging. I'm barely keeping up.
Pls. accept apologies.
<DanC_> (timbl, I suggest you contact the chair about the record when we're done)
<DanC_> (I think dhull's doing as good a job as can be expected)
<comments missed>
GlenD: There are cases where people expect to see requestURI at one place, wsa:to elsewhere, to: is abstract.
<DanC_> ah.
PC: What have you said back to
Mark on this? IF WSA reaches down through SOAP, would you take
away a feature of SOAP (e.g. intermediaries).
... ISn't this the simplest answer? Issue 47 -> taking away
a feature of SOAP. What did you say to this?
Mrash: Didn't accept issue. Mark wanted to take it to TAG anyway.
PC: Yes.
... Not wise for WSA to reach down under SOAP.
<timbl> (My last point was that the WS architecture does not have a clear layering. For example, a given functionality doesn't necessarily know whether it is under or over reliable messaging. That makes thinking about all these questions much more difficult. The idea of marking headers which came from EPRs with a special attribute seems to point to a confudion as to what layer they are to do with , who should or should not know what they mean, be responsible for them,
<timbl> (I don't expect any scribe to keep up with this discussion)
PaulC: TAG has neither agreed or disagreed with Mbaker.
PC: MB /is/ here!
DanC: 2/3 of this discussion
sounds like WSA, not TAG (unless oyu do it wrong ;-)
... No implementaiton experience with this?
Omnes: no.
<DaveO> time's just about out...
GlenD: Need to understand SOAP
binding, and WSA, and all layers. We're trying to write this in
a layered fashion allowing different bindings to plug in.
... E.g. SOAP/{HTTP,SMTP,JMS}
Chair: Issues are still open, actively discussed.
Danc: Please put hopes down as test cases.
Roy: If you use HTTP layer addressing, information is still there, can reconstitute. (So no harm in reaching undre SOAP in this sense (?))
Paco: It's an optimization (?)
Roy: What's more optimal depends on software. SOAP/HTTP is not anything optimal.
Naoh: You're still losing information. Eg. canonicalization/DSIG info.
?: Particularly end-end encryption.
<DanC_> (hopes to wit... the hopes around "specese" in hugo's proposal for issue... 51PaulKnight turning into code. Though since there isn't any such code yet, I'd be inclined to postpone that issue till the next version of ws-addressing, as I understand this WG to be chartered to standardize based on the deployed experience)
Roy: Duplicating doesn't have
this problem.
... Doesn't have position about SOAP (for polite company)
... Creted GET binding for a reason, to ensure that Web remains
web, so that people can still get infomrmation with URIS.
... Deviation will be dealt with severely as it damages web as
information space.
... IF you can do what you want w/o damaging web as info space,
we're happy (I say)
<DanC_> (I think I took my turn(s))
<Zakim> DanC_, you wanted to ask for a couple of examples of who wants to layer on top of ws-addressing and to ask how much interoperability is expected... what's the test
DaveO: Impedence mismatch between HTTP and SOAP views. Eg. SOAP is arbitrary typed operations. Trying to bind WS flexibility into verb set is hard. Haven't got to middle ground, to be able to pull service-y things into web (vice/versa (?)) (?)
Roy: HTTP has no constraints on verbs.
PC: But this is least standardized area. Little effect in extending verbs.
GlenD: HTTP systems are not designed for extensibility.
Roy: Disagree. They're designed to be extensible in that way.
GlenD: SOAP service deployned in envionment built for it. Big difference between plugging in CGI script and plugging in new verb.
<DanC_> (I disagree; I think there's a pretty square box around GET/PUT/POST/DELETE. there's a reason no others have been standardized)
Roy: Not necessarily.
s/not necessarily/no/?
<plh> http://www.w3.org/2005/Talks/0227-rectrack/?n=1
<plh> slides: http://www.w3.org/2005/Talks/0227-rectrack/?n=1
<mnot> Scribe: bob
proposals: 1) WSDL metadata isn't expessed as properties; only in the metadata property's infoset
2) No metadata property; metadata children have to define their own top-level properties
3) WSDL metadata is a subproperty of the metadata property
straw poll
preferred/can live with: 1-10/23; 2-5/14; 3-4/18
DavidO: appeals for logic in voting and constancy of positions
Chair: observes that proposal 1 seems the way to go
RESOLUTION: issue 26 closed with Jonathan's proposal
<Chair> summary:
<Chair> - Jonathan's proposal
<Chair> - all WSDL-related metadata, examples described in WSDL doc, in separate ns
<Chair> - embedded WSDL appendix is normative
<Chair> - MUSTs in appendix to SHOULDs
<Chair> - WSDL metadata isn't expressed as properties; only in the metadata property's infoset
RESOLUTION: issue 24 also closed due to the resolution of issue 26
Person who opened issue 24 agrees that the resolution to issue 26 satifies the concern raised in issue 24
Hugo presents his proposal of mapping addressing propertiies to SOAP
straw poll indicates that more understanding around the tabe is required before informed decisions may be made
break
return from break
detailed discussion of Hugo's proposal
items 1 seems non controversial (anish suspending disbelief)
<dims> +1
<dims> +1
<dims> +1
straw poll indicates most can live with defining SOAP properties
straw poll indicates that addressing soap feature ought to be included in the SOAP binding document
straw poll of defining the SOAP properties can be lived with generally
only three prefered not to define the SOAP properties, doinjg it carries in straw
topic Hugo's proposal chapter 3
item 3 will be re-drafted
<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0202.html
Three options on action mapping: a) always the same; b) SOAP action is the same as ADDR action, when SOAP action present;c) completely disconnected
option 2 is preferred 16/22; and will be probed in more detail
<scribe> ACTION: Hugo to write up an action proposal (ref 3. action mapping) fro SOAP 1.1 and 1.2 [recorded in http://www.w3.org/2005/02/28-ws-addr-minutes#action02]
<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0207.html
editors need to back port some redacted 3.2 information disclaiming EPR carried metadata and other information not describing comparison of EPRs