[OASIS Issue Tracker] (ODATA-846) Add version 4.01

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/ODATA-846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Pizzo updated ODATA-846:
--------------------------------

    Proposal: 
1) Define an OData-Versions annotation that specifies the OData version(s) supported by the service
  <Term Name="ODataVersions" Type="Edm.String" AppliesTo="EntityContainer">
    <Annotation Term="Core.Description" String="A space-separated list of supported versions of the OData Protocol." />
  </Term>
2) For new 4.01 features, we should define vocabularies to test the presence and expected behavior for 4.0 clients.
3) Allow services to incrementally opt into 4.01

Conformance Rules:

Compliant 4.01 Services:
-MUST return 4.0-compliant JSON payloads with OData-Version=4.0 header for clients specifying OData-MaxVersion=4.0 request header
-MUST support 4.0-compliant JSON request payloads with OData-Version=4.0 request header
-MAY support 4.01 syntax regardless of version; does not necessitate a change in OData-Version of response
-MUST not return new CSDL elements/attributes/values for existing elements/attributes if the client specifies OData-MaxVersion=4.0
-MAY return new CSDL annotations regardless of the version; does not necessitate a change in OData-Version of response
-MAY support 4.01 behavior, including returning 4.01 content and payloads, if the client does not specify the OData-MaxVersion=4.0 request header
-MUST follow OData semantics for any 4.01 syntax
-MUST return 4.0 for the Edmx:Version attribute (we are not defining a new version of Edmx)
-SHOULD return the new ODataVersions annotation. MUST include 4.0 if 4.01 is included.

Compliant 4.01 Clients:
-MUST only send payloads containing 4.01 structure to a service that advertises support for 4.01 or greater
-SHOULD use capabilities to determine if a 4.01 feature is supported but MAY attempt syntax (and receive either 501 not implemented or 400 bad request)


Areas of the spec that talk about versioning:
Part 1: Protocol
- Section 5.1 Protocol Versioning
- Chapter 12 Security Considerations

Part 3: CSDL
- Section 3.1.1 Attribute Version
- Sections 2.1 and 2.2 XML Namespaces

JSON Format
- Chapter 21 Security Considerations



  was:
Part 1: Protocol
- Section 5.1 Protocol Versioning
- Chapter 12 Security Considerations

Part 3: CSDL
- Section 3.1.1 Attribute Version
- Sections 2.1 and 2.2 XML Namespaces

JSON Format
- Chapter 21 Security Considerations

Negotiation:
-A client that specifies odata.maxversion=4.0 must receive 4.0 compliant responses.
-A client that specifies odata.maxversion=4.01, or no odata.maxversion, may get back 4.01-specific responses
-A client must only send payloads containing 4.01 structure to a service that advertises support for 4.01 or greater
-A client should use capabilities to determine if a 4.01 feature is supported but may attempt syntax (and receive either 501 not implemented or 400 bad request)

For new 4.01 features, we should define vocabularies to test the presence and expected behavior for 4.0 clients.

Make every new feature optional so that a compliant V4 service is also a compliant V4.01 service.


> Add version 4.01
> ----------------
>
>                 Key: ODATA-846
>                 URL: https://issues.oasis-open.org/browse/ODATA-846
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol
>    Affects Versions: V4.0_ERRATA02
>            Reporter: Ralf Handl
>            Assignee: Michael Pizzo
>             Fix For: V4.01_WD01
>
>
> This issue tracks all places that need to reflect the new version number in the  prose text.
> We will also use this issue to track how we do version negotiation between a 4.0 and a 4.01 client and service.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)