[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (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:comment-tabpanel&focusedCommentId=34865#action_34865 ]
Ralf Handl commented on ODATA-466:
----------------------------------
Disallowed spaces and line breaks.
One goal was to be able to just copy and paste from message body to URL, and allowing spaces defeats this purpose.
> 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, OData URL Conventions
> Affects Versions: V4.0_CSD02
> Environment: [Applying]
> 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]