W3C home > Mailing lists > Public > public-ws-addressing@w3.org > October 2005

Re: Multiple Addresses in an EPR

From: John Kemp <john.kemp@nokia.com>
Date: Sun, 16 Oct 2005 22:32:33 -0400
Message-ID: <43530D41.6010809@nokia.com>
To: ext Martin Gudgin <mgudgin@microsoft.com>
CC: "Conor P. Cahill" <concahill@aol.com>, "Rogers, Tony" <Tony.Rogers@ca.com>, David Orchard <dorchard@bea.com>, ext Mark Little <mark.little@arjuna.com>, Mark Nottingham <markn@bea.com>, WS-Addressing <public-ws-addressing@w3.org>

Hash: SHA1

ext Martin Gudgin wrote:
> I thought the CR phase was about figuring out whether the spec could be
> implemented 'as written'...

Isn't it also about figuring out whether the spec. is interoperable for
reasonable usage? I've heard a reasonable usage expressed that isn't
supported interoperably by WS-A.

- - JohnK

> Gudge 
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org 
>>[mailto:public-ws-addressing-request@w3.org] On Behalf Of 
>>Conor P. Cahill
>>Sent: 16 October 2005 18:39
>>To: Rogers, Tony
>>Cc: David Orchard; John Kemp; ext Mark Little; Mark 
>>Nottingham; WS-Addressing
>>Subject: RE: Multiple Addresses in an EPR
>>Rogers, Tony wrote on 10/16/2005, 9:02 PM:
>> > So I would prefer that those who have this newly 
>>discovered need can
>> > choose to solve it in one of the other ways that you have outlined,
>> > rather than hold back a standard that is in CR phase already - yes.
>> > Making the change that you propose would drag the spec 
>>back to LC again,
>> > and delay it for everyone.
>>That's what the CR process is about.  If one can't raise issues
>>and get them resolved, then there doesn't need to be a CR phase
>>at all.
>>On a technical basis, I haven't heard anyone say that this isn't
>>a resonable use case.
>> > Your fear that there will be a variety of implementations may be
>> > groundless - if you choose one and describe it now, then others can
>> > follow your lead, and all will be well.
>>So you're telling me that CA and other implementors will commit to
>>adopt one that I choose to describe now?   I'm guessing not.  I'm
>>guessing that there will be many toolkits that either a) don't
>>support this functionality at all because it isn't in the spec,
>>or b) choose to do it in a different non-interoperable way.
>> >
>> > "Not having this capability makes it very hard/inefficient 
>>to support a
>> > real world use of the spec."
>> >
>> > Not true - you have described multiple ways in which you might
>> > implement a solution, and they appear both simple and efficient
>> > (perhaps not as aesthetically pleasing). If there were truly no
>> > way in which the problem might be addressed, other than changing
>> > the spec, then I would be more sympathetic.
>>A) My comment was more related to trying to follow the spec as
>>written since that is all that out-of-the-box toolkits will
>>be able to do).  The spec currently requires that the physical
>>address be carried in a single wsa:Address element.  So if I
>>wanted to follow the spec and I had multiple addresses I would
>>have to have multiple EPRs (othewise I risk that clients
>>built off the spec will not recognize the alternative addresses).
>>B) Given that a spec has an xs:any in the EPR, I could put the
>>kitchen sink in there, so there's pretty much no problem that
>>would be impossible to resolve.  That doesn't mean that there
>>aren't good reasons to have defined elements (which is why,
>>even though there is an xs:any, the spec does define Address,
>>ReferenceParameters, and Metadata).

Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

Received on Monday, 17 October 2005 02:33:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:29 UTC