See also: IRC log
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0009.html
no changes or other business
RESOLUTION: Minutes approved as sent
2005-07-25: Paul Downey to generate list of features, their
requirement level and applicability for discussion
<scribe> : DROPPED
Arun's material appears sufficient.
DHull review: DONE
MarcG review: DONE
Katy: PENDING
Marsh AI: DONE
scribe:
All done but Katy's...
Mark: Hugo suggested it would be good to write down a policy
Hugo: I wrote a doc.
<hugo> Draft I did: http://www.w3.org/2002/ws/addr/5/08/29-ns-policy.html
Hugo: For each draft we have set
a new namespace, with the form
w3.org/year/month/identifier
... we have been updating the namespace each publication.
... We haven't agreed on how to change this from now on.
... Before we reach CR, we replace the namespace each time.
When we reach CR, we only update if there is a significant
change is made.
... WHat is a significant change?
... Up to the WG in each case.
Chorus: Seems sensible.
Mark: Philippe said it might be good to document this at the end of the NS URI.
Hugo: Only problem is that the
policy is only visible when dereferencing the namespace
URI.
... We should also put it in the status section of the
doc.
... I'm very flexible.
... Good to see when people read the draft.
Mark: Can we get a paragraph to paste into the spec and the RDDL?
Hugo: Do you want to include the appropriate section from my doc?
Mark: Yes, not too heavyweight.
Nilo: CR says the URI only
changes with significant changes. Hugo's proposal says the
opposite.
... Seems we need to remove the "NOT"s
<mnot> From Section 2.2: After a document has been published as a Candidate Recommendation, the namespace IRIs will be updated only if changes are made to the document are not significant and do not impact the implementation of the specification.
<uyalcina> +1 to Nilo
Hugo: Ah, I see! To many
negatives...
... needs to be fixed. "are significant and impact ..."
Mark: After we get to CR, we will
attempt to keep the URI the same.
... OK?
<scribe> ACTION: Editors to incorporate this into the document and the RDDL. [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action01]
<Nilo> After a document has been published as a Candidate Recommendation, the namespace IRIs will be updated only if changes made to the document are significant and impact the implementation of the specification.
Mark: Only 2.2 applies to the CR docs, section 2.1 applies to the WSDL doc.
[general agreement]
Mark: We have 3 of 4 AIs done. Let's walk through them.
<gpilz> anyone know what the address of this server is?
<mnot> http://www.w3.org/mid/[email protected]
Mark: Tony's review on the Primer
<gpilz> I meant the direct IRC address
Tony: saw a number of typos.
<marc> ACTION 1=Editors to incorporate ns update policy into drafts
Tony: We aren't included in the
references.
... Section 5.3 discusses endpoint references to describe the
URL where the service lives.
... Could be "endpoint URL" or an "endpointer"
... A different term than "endpoint reference" would reduce
confusion.
Umit: THere is a definition of endpoint reference in 5.3.
DaveH: Confusing.
<anish> WSDL has an endpoint and ws-addr has an endpoint and they are quite different
Umit: If there is a different term, would that solve the problem?
Glen: Just the term, I believe.
DaveH: Partly the term, partly
two parallel universes.
... One where you refer with a URI, one with an EPR. Took a
couple of readings to figure out what was going on.
Glen: the third universe is the
syntactical constructs, they may contain policy etc.
... the "endpoint" construct in WSDL.
Tony: 5.3 comes right after 5.2
which makes reference to WS-A, already given people a defn of
endpoint reference there (implicitly).
... Different term would avoid confusion.
Umit: Definitions in Core and 5.3, and 5.2 introducing concepts in wrong order (possibly).
Mark: Happy to send Tony's comments to WSDL?
[apparently so]
Mark: Dave's comments
<mnot> David Hull's comments on the Core: http://www.w3.org/mid/[email protected]
<scribe> [postponed temporarily]
Mark: Marc Goodner's
comments:
... typos
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0011.html
scribe: points out some relevant sections of the spec, but don't appear to be issues.
<mnot> WSDL Adjuncts Section 2.2:
<mnot> WSDL patterns specify propagation of faults, not their generation. Nodes which generate a fault MUST attempt to propagate the faults in accordance with the governing ruleset, but it is understood that any delivery of a network message is best effort, not guaranteed. The rulesets establish the direction of the fault message and the fault recipient, they do not provide reliability or other delivery guarantees. When a fault is generated, the generating node MUST atte
<mnot> the fault, and MUST do so in the direction and to the recipient specified by the ruleset. However, extensions or binding extensions MAY modify these rulesets. For example, WS-Addressing [WSA 1.0 Core] defines a "FaultTo" address for messages, which is used in lieu of the recipient nominated by the ruleset.
Mark: That seems fine.
<mnot> http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#soap-operation-decl
Mark: SOAP Action Feature doesn't
mention WSA Action - oversight?
... thoughts?
Marsh: What would WSDL say?
Mark: Might say "there are other
specs out there..."
... Let's defer these till next week.
... when Katy's got her review done.
... And forward the typos.
DaveH: Except for 3.3, most of
the COre is too generic to be of concern to us.
... In 3.3, wsdlx:interface and wsdlx:binding are
defined.
... Need to clarify endpoint references as applied to
URIs.
... By tagging it the semantics of "this is a reference to an
endpoint" are applied.
... It's nice, e.g. WSN, to say that an EPR is a particular
type.
Marsh: Interesting it wasn't clear to you that you can use these for wsa:EPRs.
DaveH: Wasn't clear - should make
it more explicit.
... Nice to hang it off an element declaration instead of just
a type.
... Seems lighter weight than deriving a new type.
... Don't think anything would preclude that design. The
examples in the primer tend towards extending a type nor an
element.
... A use case was what is in the data vs. a schema.
... Could include wsdlx:interface in an EPR.
... Is that what WSDL wanted?
Umit: Is there a problem in the
Core (3.3), it says that that are AIIs in wsdlx, and a comment
about how these can be used together, and how they are applied
to xs:anyURI.
... No restriction against using them with wsa:EPRs. Are you
saying there should be used on wsa:EPRs? and an example?
DaveH: Says these annotate anyURIs or restrictions thereof, which sounds exclusive.
Umit: That wasn't the intent. Add more text making it clear it can be used on EPRs too?
Dave: "xs:anyURI" ->
"xs:anyURI and wsa:EPR" or just drop xs:anyURI and talk about
elements.
... even adding "such as" would have helped.
Marsh: Intention was to provide description level constructs to complement wsa:Metadata/wsaw:ServiceName, etc.
Dave: Was the intention to allow on element decls as well as types?
Marsh/Umit: Don't remember.
Dave: Other than this, core looks good.
Summary:
1) Clarify wsdlx: can apply to EPRs, not just xs:anyURI.
2) Can wsdlx: be applied to element decls, not just types?
<scribe> ACTION: DaveH to revise his comments on WSDL 2.0 3.3, by 9/19 [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action02]
<mnot> http://www.w3.org/mid/7DA77BF2392448449D094BCEF67569A508D098E9@RED-MSG-30.redmond.corp.microsoft.com
<GlenD> +1
Marsh: Goes through his posting.
<Zakim> marc, you wanted to ask a question on wsdl:required=false case
Arun: We should add some of this to the spec.
Marc: wsdl:required="false"
allows a service to send headers without receiving them from
the client.
... That seems bad.
... You could send me a message with a messageID, expecting a
relatesTo, but you won't get it, which is bad.
Marsh: We could define that behavior - separate issue.
Umit: Bottom line: wsas:Action can't force behavior without wsa:UsingAddressing.
Anish: you say a client MAY
engage wsaw:Action when wsdl:required="false", but not pick and
choose the rest of the WS-A features.
... WHen the client uses WS-A it must engage it fully as we
spec.
Marsh: Useful to clarify that.
<Gil> get the video!
Summary:
1) in case 2, if wsa headers are sent, they must be responded to by the service.
2) in case 2, client either chooses to honor Addressing, or not to include any wsa headers (whole enchilada)
3) in case 3, wsaw:Action is informational.
Clarify these three items.
<mnot> [numbered bullets are additions to 3' proposal in Jonathan's e-mail]
Paco:
"informational/advisory" should say "no normative intent".
Marsh: you can't ignore it in all cases (out of band may make use of it).
Mark: Everyone comfortable with this?
[seem so]
scribe: Can we send this off to the editors?
Marc: Would like some text.
<scribe> ACTION: Paco to come up with wording to implement i061 based on the above discussion. [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action03]
<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Apr/0062
Mark: Marc's link is the proposal
on the table.
... everyone comfortable at this point?
Umit: looks reasonable, except
for one thing.
... "if there is no wsa:EndpointReference..." what does it mean
that there is an anonymous URI for the destination?
Marc: IIRC, the anonymous means
"do what the transport says".
... we define HTTP response.
Umit: For destination what does
that mean?
... for SOAP/HTTP.
<vikas> Every binding has its own "understanding" of what is anonymous URI
Marc: Conclude it's bad WSDL at that point.
Umit: Maybe the fourth rule shouldn't apply then.
Mark: Are there other bindings where that would have utility?
Umit: Unless there were a catalog
or config file to map anonymous.
... Not very interoperable.
Marsh: What's the alternative?
Anish: If you wanted to support a
way to have this defined elsewhere, we should call it
"undefined".
... IF a binding could define what anonymous means it would be
useful, but I can't think of such a binding.
... Maybe a separate issue: we require a destination to be
anonymous, which is delegated to the binding. In the SOAP
binding we define what it means for replyTO and faultTo, but
not destination.
Mark: We could change the fourth bullet to say "it's undefined", or define what anonymous means for destination.
Umit: We need to define anonymous for [destination] in any case.
Anish: If wsa:To is missing destination is anonymous already. Is #4 adding anything?
Marc: Mixing up the value of wsa:To and the value of the property.
Anish: Proposal is if no values are specified you use anonymous. Similar with wsa:To.
Marc: Doesn't interfere with it, just conveys it.
Umit: In the end, what is the address on the wire?
Marc: If you're sending a message to anonymous, you can omit the wsa:To header or put in the anonymous value.
Umit: The relation of the HTTP address and the anonymous URI needs to be clarified somewhere.
Marc: We only define one case where anonymous has a meaning - HTTP back-channel.
Mark: What are you
recommending?
... that people avoid anonymous for destination?
Umit: Not sure what the solution
is.
... Maybe clarify where anonymous doesn't make sense.
Mark: So should we change or remove the 4th bullet?
Marc: Don't think we fix anything by removing the default.
Paco: This is a hole in WSDL
we're trying to fix.
... If you have a WSDL with no address, we're providing an
interpretation for that case.
... Can we derive the value of [destination] from WSDL? When
the WSDL author doesn't provide one, we'll provide one.
... Is that the wisest thing to do?
Anish: In the proposal, the EPR
is included as a child of wsdl:endpoint or wsdl11:port. DOes
that mean the EPR applies only to the in messages for that
endpoint/port?
... What happens when it's specified for a port with only an
out message?
... Need to be more specific on which messages the embedded EPR
applies to.
... requires more thought.
... Specifically a problem with the first "in" message, but
might be others.
Umit: The reason you don't have
an address in teh port (WSDL perspective) is that the address
is added at deployment.
... Might not be safe to assume there is an anonymous
destination.
... Addresses might be provided at a later time.
Marc: Why would you have an EPR
at a later time.
... OK, maybe so.
<scribe> ACTION: Anish to explore the issue of application to messages other than the first "in". [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action04]
<scribe> ACTION: Umit explore the issues surrounding bullet 4 for next week. [recorded in http://www.w3.org/2005/09/12-ws-addr-minutes.html#action05]
Mark: i056 to email.
Mark: Delegated to the Async
TF.
... At this point it seems the TF is running out of steam a
bit. Good time to bring it back into the WG.
... Need to wrap this up to get the doc into CR.
... Glen will write up a summary, esp. of the decisions to be
made, different proposals for solving them.
... Please look for it.
... Will reserve a chunk of the FTF to talk about this issue.
If you have a proposal get it in by then.
... Number of ways to address the issue, but we need to see
which fit within our deliverables and our charter
requirements.
Mark: Revised proposal from Anish.
<stevewinkler> glen, I'll send my regrets for wed now, I'm on the road...
<mnot> http://www.w3.org/mid/[email protected]
Anish: Logical/physical
address
... There was the potential for a physical and logical
address.
... The proposal had three parts, part 2 and 3 defined the
relation of physical and logical.
... those have gone away. Part 1 uses updated
terminology.
... Proposal:
When the EPR minter includes a [selected port type], and/or [service-port] then the EPR is considered to be specific to the [selected port type] and/or [service-port]
Marsh: The spec doesn't say this yet?
Anish: No, not that I could see.
Umit: No we don't say that anywhere. Although it seems obvious, it's not explicitly stated anywhere.
Paco: Makes sense.
<uyalcina> +1 for the proposal
Mark: Any objections to the proposal?
Vikas: Doesn't resolve the logical and physical.
Mark: We resolved a while ago we wouldn't talk about that.
<mnot> Subissue c: An EPR allows one to include (optionally) a service endpoint/port. If such an endpoint/port is included in an EPR, what is the relationship between the value of the [address] property and the URI value in the [service-port] property? We have said that the [address] property is a logical address and not necessarily the physical endpoint where messages can be sent and how the mapping between logical to physical takes place is an extensibility point. Is t
<mnot> vice QName is present in the EPR. I.e., should our spec say that if the service QName is present then the physical address is what is specified by the wsdl port.
Anish: WSDL never says the port address is any more physical than the WS-A address. THey are all IRIs and that's that.
Vikas: Maybe we should rewrite the issue to get rid of the logical/physical confusion.
Umit: Does Anish's proposal make sense on it's own right or not.
Vikas: If the issue is cloudiness about physical/logical, the proposal doesn't address it.
Mark: Should we delete everything but the second sentence of the issue?
Anish: We can point to i052, say the questions about logical/physical are addressed there.
Mark: Proposed resolution:
Anish's proposal, plus a ref to the resolution of 052.
... Everyone comfortable?
Vikas: i052 resolution: remove "logical" when talking about addresses.
[silent assent]
RESOLUTION: i020 closed with Anish's proposal.
Bob: Customers have co-opted our
meeting room, we've moved to a nearby building.
... Logistics coming.
... Negotiated rates available through email reservation.
... Unless you are fluent in Japanese, have an international
drivers license, etc., it's maddness in the metro area to try
to drive.
... Will be escorting people from the hotel to the meeting room
starting on the 7th
... Trying to gauge interest in some sightseeing or
entertainment.
... Just after the peak of the autumn color season, we might be
able to get some rooms there Nov 5,6.
... Other details like how to buy tickets, get from the
airport, etc. coming.
DaveH: How long is the Narita express?
Bob: About an hour. 12 min from
hotel to meeting room; fare: 210. Narita Express fare
information forthcoming.
... $125 hotel + $10.70 internet access.
... I'm translating maps from Japanese, takes a while.
Mark: Talk next week, might be
absent, in which case Hugo will chair.
... Do your AIs.
... Get your potential issues in.
[adjourned]