RE: Version upgrade etc. use cases

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

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

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


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


		Phill

Phillip Hallam-Baker (E-mail).vcf