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] Commented: (ODATA-466) Please clarify whether Edm.Binary is really intended to be base16-encoded in accordance with ABNF, or if it should be base64-encoded as with OData V3


    [ http://tools.oasis-open.org/issues/browse/ODATA-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34725#action_34725 ] 

Michael Pizzo commented on ODATA-466:
-------------------------------------

*allow* or *require* the "binary" prefix in URLs?

> Please clarify whether Edm.Binary is really intended to be base16-encoded in accordance with ABNF, or if it should be base64-encoded as with OData V3
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ODATA-466
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-466
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Task
>          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]