Re: Multiple Addresses in an EPR

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ext Martin Gudgin wrote:
>  
> 
> 
>>-----Original Message-----
>>From: John Kemp [mailto:john.kemp@nokia.com] 
>>Sent: 16 October 2005 20:30
>>To: Martin Gudgin
>>Cc: Conor P. Cahill; Rogers, Tony; David Orchard; ext Mark 
>>Little; Mark Nottingham; WS-Addressing
>>Subject: Re: Multiple Addresses in an EPR
>>
> I certainly appreciate the process-oriented viewpoint. Processes, of
> course, are supposed to work for those who create and adhere to them.
> 
> 
>> FWIW - The WG didn't create the process...

The point still applies I think.

> 
> 
> And they're there to make sure the specification that gets produced is
> not just implementable, but sound from an engineering perspective.
> 
> 
>> Are you implying that the lack of this feature makes WS-Addressing
>> unsound from an engineering perspective?

I believe that it is important to support the possibility of multiple
identical servers being identified with multiple addresses in one EPR.

> 
> 
> Furthermore, the most compelling reason to make a standard at all (IMO
> at least) is for interoperability.
> 
> 
>> Are you implying that WS-Addressing is not (usefully) interoperable
>> without this feature?

I think it is less interoperable than it should be.

- - JohnK

> 
> 
> "standards sausage" - v. good ;)
> 
> 
>> Not mine I'm afraid, 
> 
>> (C) Don Box (circa 2002)
> 
>> ;-)
> 
>> Gudge
> 
> 
> - JohnK
> 
> ext Martin Gudgin wrote:
> 
>>To me, it's about figuring out whether people can implement 
> 
> the spec 'as
> 
>>written'. Part of getting the spec to CR in the first place 
> 
> is ensuring
> 
>>it meets the requirements specified in usage scenarios etc. 
> 
> Few specs do
> 
>>everything everyone wants them to do. Sometimes features 
> 
> are left out
> 
>>for a variety of reasons ( same with shipping any 'product' 
> 
> really ). I
> 
>>believe this particular 'reasonable usage' was discussed by 
> 
> the WG and,
> 
>>essentially, didn't make the 80/20 cut. And I think the discussion
>>occurred before Last Call, let alone CR.
> 
>>It's easy to cut features when moving forward from CR. It's 
> 
> very hard (
> 
>>impossible? ) to add features without incurring signficant 
> 
> extra process
> 
>>( i.e. going back to Last Call ).
> 
>>To me, before ( or during ) Last Call was the right time to 
> 
> ask for this
> 
>>feature to be added. Not during CR. And in some cases, 
> 
> people ask for
> 
>>features to be added, and the WG still declines to add 
> 
> them... That's
> 
>>just part of the way standards sausage gets made...
> 
>>Gudge
> 
> 
> 
>>>-----Original Message-----
>>>From: John Kemp [mailto:john.kemp@nokia.com] 
>>>Sent: 16 October 2005 19:33
>>>To: Martin Gudgin
>>>Cc: Conor P. Cahill; Rogers, Tony; David Orchard; ext Mark 
>>>Little; Mark Nottingham; WS-Addressing
>>>Subject: Re: Multiple Addresses in an EPR
> 
> 
>>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).
> 
>>>>Conor
> 
> 
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDU6VZmNJiOOM57NMRAuV/AJ0XYOl+Zg3TpUyZtAyWwuiSM4oargCdHKiK
31wXGKMdkGjnAaIvb8Ju1lM=
=tgWI
-----END PGP SIGNATURE-----

Received on Monday, 17 October 2005 13:22:00 UTC