Re: Version upgrade etc. use cases

[George Robert Blakley III <blakley@us.tivoli.com>]

Phill,

My $0.02:


>Versioning
>
>...
>
>Version 2.x client attempts to access version 1.y service
>    Desired behavior MAY be referal to 2.0 service,
>         MAY be advice to downgrade request,
>         MAY be 1.y response [Group MUST choose NOW]

I vote for 1.y response with minor status notification that the response is
back-level
(This is easy to build in to 1.y service -- just compare request level to
service current
level and if req-level > serv-level then issue minor status with normal
response).  Tradeoff
is that if 2.0 service schema is missing elements required in 1.y request,
you'll get an
error response rather than a referral or request to downgrade.  But I think
this choice provides
maximum decoupling of client behavior from server behavior while preserving
simplicity of
implementation.

>
>Version 1.y client attempts to access version 2.x service
>    Desired behavior MAY be referal to 2.0 service,
>         MAY be advice to downgrade request,
>         MAY be 1.y response [2.x group SHOULD choose IN FUTURE]

I think this statement is wrong.  I would have expected:

Version 1.y client attempts to access version 2.x service
     Desired behavior MAY be referal to ***1.y*** service,
          MAY be advice to **up**grade request,
          MAY be 1.y response [2.x group SHOULD choose IN FUTURE]

If I'm not right about this, could you provide more explanation of the
first
two options?  If I am right, I think the right behavior is a 1.y response,
on
the grounds that a reasonable service upgrade provides backward
compatibility.


>Client capability negotiation
>
>Client requests attributes from service
>    Client supports attribute schemas P,Q,R
>    Server supports attribute schemas Q,R,S
>
>    Desired behavior
>         Server responds with schema Q or R.

AND explicitly notifies client whether Q or R was used (unless this can be
determined
from elements of the schema itself --- I haven't paid enough attention to
know if this
is the case)


--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security, Tivoli Systems, Inc.


"Hallam-Baker, Phillip" <pbaker@verisign.com> on 08/14/2001 12:30:18 PM

Please respond to "Hallam-Baker, Phillip" <pbaker@verisign.com>

To:   "Security-Services (E-mail)" <security-services@lists.oasis-open.org>
cc:
Subject:  Version upgrade etc. use cases