Interoperability issue when using escaped slash/backslash in URLs

We already have an implicit cast rule: "Primitive types are cast to Edm.String or a type definition based on it by using the literal representation used in payloads". This means that binary literals are cast to strings containing the base64url-encoded value. Alternative proposal: both problematic components (Tomcat, .NET client) can deal with plain-text or percent-encoded forward- and backslashes if they appear in the query part of the URL. This means parameter aliases are sufficient to defer problematic key values to the query part of the URL. Services that support forward-slash in key values MUST support passing key values as parameters. Put this issue on "Implementing OData" to add a recommendation for clients and servers on "problematic" infrastructures. ---------------------------------------------------------------- Old, inapplicable proposal: Add an implicit cast rule that allows binary values in place of string values, where the base64url-encoded binary is the UTF-8 representation of the string value: GET Categories(binary'Q29tZWR5L011c2ljYWw=') Services are required to support an implicit cast from binary to string (anywhere). Clients are advised to use this form when passing a string value containing a forwardslash, backslash, and a null character (%5C, %2F, %00)