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

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

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


Subject: [OASIS Issue Tracker] Updated: (ODATA-466) Edm.Binary should be base64-encoded (as with OData V3), not base16-encoded (as per current ABNF)


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

Ralf Handl updated ODATA-466:
-----------------------------

    Proposal: 
Consistently use base64url encoding for binary data throughout OData, see http://tools.ietf.org/html/rfc4648#section-5. This variant of base64 is URL-safe.

The pad character = is not necessary as the encoded value is prefixed and enclosed in single quotes in URLs, enclosed in double quotes in JSON, and represented as an attribute or element value in XML (CSDL, Atom format). 

Spaces and line breaks are allowed within the encoded value  and MUST be silently ignored.

Only allow "binary" as prefix in URLs as the prefix 'X' would misleadingly suggest HEX encoding.

  was:
Consistently use base64url encoding for binary data throughout OData, see http://tools.ietf.org/html/rfc4648#section-5.

This variant of base64 is URL-safe. The pad character = is not necessary as the encoded value is prefixed and enclosed in single quotes in URLs, enclosed in double quotes in JSON, and represented as an attribute or element value in XML (CSDL, Atom format).

Only allow "binary" as prefix in URLs as the prefix 'X' would misleadingly suggest HEX encoding.


Not sure whether we want to allow spaces and line breaks within the encoded value. XML Schema 1.1 allows them in http://www.w3.org/TR/xmlschema11-2/#base64Binary, RFC4648 does not, see http://tools.ietf.org/html/rfc4648#section-12.

> Edm.Binary should be base64-encoded (as with OData V3), not base16-encoded (as per current ABNF)
> ------------------------------------------------------------------------------------------------
>
>                 Key: ODATA-466
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-466
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData ABNF Construction Rules, OData ATOM Format , OData CSDL, OData JSON Format
>    Affects Versions: V4.0_CSD02
>         Environment: [Proposed]
>            Reporter: Evan Ireland
>            Assignee: Ralf Handl
>             Fix For: V4.0_CSD03
>
>
> OData V3 encodes Edm.Binary using base64 encoding, as defined by RFC4648.
> OData V4 JSON and ATOM specs for encoding of primitive values refer to "binaryValue" in the ABNF.
> It this an intentional change for the encoding of binary values in payload (switching from base16 to base64)?
> Or have we accidentally (by having URL conventions and ATOM/JSON documents referring to the same binaryValue ABNF rule) changed to base16?
> Also, I note that odata4j does base64 encoding including CR/LF, whereas RFC 4648 (referred to by OData V3 spec) states:
>    Implementations MUST NOT add line feeds to base-encoded data unless
>    the specification referring to this document explicitly directs base
>    encoders to add line feeds after a specific number of characters.
> My reason for pointing this out is that if we decide to revert OData V4 to using base64-encoding for binary values in payload, then we might consider explicitly mentioning that CR/LF is disallowed in the encoding. Even although that should be apparent if we have a suitable ABNF rule for base64 that doesn't permit CR/LF, we should be clear so that implementors are reminded not to make the same mistake that was made in odata4j.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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