<anish> Scribe: mpeel
Chair: WG will meet on President's Day (2/21).
Last meeting (2/7/) minutes approved
Hugo: working draft publication set for tomorrow, all 3 drafts
Chair: everyone please review these drafts
<scribe> ACTION: Gudge will check schema to align with working drafts
<Gudge> ACTION 1 = Gudge will check schema to align with working drafts. Due 2005-02-18.
<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0086.html
Anish: proposed adding text to resolve confusion over "endpoint"
<uyalcina> +1 to change
Gudge: change "optimized" to "designed"; Anish: Okay
Tony: "intended" rather than "designed": Gudge and Anish agree
<mnot> RESOLUTION: subissue iv, issue 020: add "Note that WSDL 2.0 has an Endpoint component [ref] which along with other WSDL 2.0 components can be used to describe a Web service endpoint. A Web service endpoint may in fact have multiple such descriptions. Similarly multiple EPRs can be used to convey information needed to address a particular Web service endpoint. An EPR is optimized to convey information required to address a Web service endpoint whereas a WSDL 2.0 is intended to describe a Web service." after "A Web service endpoint is a (referenceable) ... needed to address a Web service endpoint." in the core.
Issue 20 subissue iv closed with Tony's amendment
<anish> subissue iii -- http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0109.html
Anish: describes his proposed wording to resolve subissue iii, Issue 020
<Marsh> Something like this? "When the EPR minter includes a [selected interface] and/or [service endpoint], then the [selected interface] and/or [service endpoint] are considered to apply to the endpoint to which the EPR refers."
<Marsh> or s/to apply/to be applicable/
<uyalcina> Jonathan, I think this is true for all metadata, not only selected interface, etc.
<Marsh> Umit: Yes. But Anish's issue seemed to be more clearly defining those two properties as "relevant metadata".
<Marsh> or s/to apply/to be relevant/
<uyalcina> I observe that this proposal predates the metadata proposal.
<TomRutt> +1 on Anish proposal from Tom rutt
Chair: should this be in 1.0 or can it wait? Anish: big hole if omitted
Paco agrees point 1 is necessary, but thinks physical/logical relationship needs more fleshing out
TomRutt: #2 is important; don't have to use this mechanism, but must be able to specify WSDL-centric physical endpoint
Umit: +1 to Paco, too murky to make distinction right now
<Marsh> +1 to at least clarify that WSDL address is clearly (and intentionally) physical, if we assert that in our spec.
Chair: needs more discussion on the list
Anish will drive discussion on list
Marc: proposal on absolute vs. relative URIs
Defined 3 sets of properties where a base URI + relative URIs could be useful
Marc: only allow relative URIs in addressing elements, use SOAP-defined mechanisms for specifying base URIs
Gudge: Security issues using relative URIs? Need signing to prevent tampering?
Phillippe isn't sure about security issue, will doublecheck
<hugo> http://www.w3.org/TR/2001/REC-xml-c14n-20010315 certainly talks about XML Base a lot
Chair: any benefits other than saving bytes?
<Zakim> Gudge, you wanted to clarify xml:base in EXCC14N
<plh> "The XML being canonicalized may depend on the effect of XML namespace attributes, such as xml:lang, xml:space, and xml:base appearing in ancestor nodes."
<plh> "To avoid problems due to the non-importation of such attributes into an enveloped document subset, either they must be explicitly given in the apex nodes of the XML document subset being canonicalized or they must always be declared with an equivalent value in every context in which the XML document subset will be interpreted."
Marc: won't oppose making all URIs absolute
Chair: I hear some misgivings about relative URIs, no strong support
Resolution: when serialized into SOAP message, all URIs must be absolute; editors agree
<mnot> Proposed resolution: Message Properties whose values are URIs must be serialised as absolute URIs in the SOAP binding.
<marc> [destination], [action], [message id],
<marc> > [relationship/relatesto], [relationship/type]. In addition the message
<marc> > addressing properties [source endpoint], [reply endpoint] and [fault
<marc> > endpoint] each contain [address] properties
Anish: is this a SOAP 1.2 issue?
No objections to resolution, Issue 047 closed
Anish: more info available about April and June F2Fs? Chair: not at this time. Firm dates in week, week-and-a-half?
Jonathan: put a predefined Action URI for faults in core spec
Marc: I don't see much value in this.
Paco: Jonathan's proposal useful, low-cost
Chair: Marc, are you ambivalent or against this? Marc: Against. Don't see the need, doesn't give any info.
Jonathan: are you suggesting appending "_fault" to created Action URI? I'd be okay with that, but it seems like more work.
Marc: create one Action URI for anonymous messages, one for anonymous fault
<scribe> ACTION: Marc will write proposal for dual default default URIs
Issue 042 skipped for now; Dave Orchard needs to look at this
<hugo> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0091.html
Chair: is this just an editorial change? Marc: no
<marc> and that it would be good to align the behaviour of FaultTo and ReplyTo
Chair: close Issue 044 with latest proposal from Hugo? No opposition
just lost Glen, so wait for next meeting
<pauld> Paco's summary: http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0039.html
Umit: if deploying minor improvements to services, you wouldn't advertise new endpoints for them
Umit: This is especially relevant to deploying different versions of the same webservice. One would not publish a new endpoint for a minor, monotonic and backwards compatible new version of a web service. Such an example is adding a new message exchange and a service provider will use the existing endpoint. This specific use case appears be prohibited by the definition of the comparison we have. We just made a decision about clarifying the distinction between EPR, endpoint and endpoint components for issue 20, subissue iv. This means that there may be multiple EPRs that refer to the same endpoint. Section 2.3 effectively contradicts the definition which we just agreed upon. The comparison rules we have do not mean that EPRs are the same. They just refer to the same endpoint.
Marc: do you plan to use Reference Parameters to distinguish the endpoints?
Umit: Potentially
Marc: that gets back into identity
<anish> wsrf tc uses that if i'm not mistaken
<hugo> +1 to what Marc said
Marc: it seems we're trying to get around our resolution to Issue 001.
Chair: we need more discussion on list and at F2F
Umit: Correction, I meant to say EPRs, not endpoints. Apologies for the confusion.
<Marsh> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Feb/0016.html
<TomRutt> +1 tom rutt likes this proposal a lot
Umit: this creates a metadata bucket in an EPR in a clean way in one place
TomR: can this be used to add
policy as well? SteveV: yes
... how about proprietary policy metadata in here?
SteveV: I don't see how we can stop them from using extensibility to do so.
Chair: everyone should be familiar with this by F2F; this should be one of your last big issues.
Meeting adjourned
[End of minutes]