RE: Multiple Addresses in an EPR

 

> -----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
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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...

> 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?

> 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?

> 
> "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
> 
> iD8DBQFDUxrEmNJiOOM57NMRAt05AKCWmgyJCNKFCHP65C7vHkfDLuU6/wCg+ETR
> Hjm17ZSrsAXb2Et+IvrDSY0=
> =0xcq
> -----END PGP SIGNATURE-----
>

Received on Monday, 17 October 2005 03:55:26 UTC