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