OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Version upgrade etc. use cases


Phill

>> >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
>
>I agree. Although it would probably be a good thing to include
>an advisory referal to the upgraded service.

I agree with the addition of an advisory referral.

>> 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]
>
>Yes, cut and paste error. Point is however we don't need to
>decide today how a 2.0 server behaves.

Agreed, but it wouldn't hurt if we have a strong opinion to
try to guide our successors in the right direction (which, to
reiterate, is in  my opinion a 1.y response)

>However a server should be able to notify the client that is
>prepared to support 2.0 requests in the future.

I think this would be nice but not essential.

>> >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)
>
>If the XML is well formed and validates then the xmlns attribute
>for the schema will have to be present.

Good -- nice to get something for free.

--bob

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC