RE: Agenda for OData TC meeting on 2019-10-31

[‎31.‎10.‎2019 16:02] Mark Biamonte:

My meeting just before this going long so I will be late to join again this week

[‎31.‎10.‎2019 16:03]

No problem, we'll wait with the IANA registration

[‎31.‎10.‎2019 16:03]

[1] Agenda

1. Roll call [8:00 am]

a. Self-registration link: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=48010

[‎31.‎10.‎2019 16:03]

Voting Members: 5 of 9 (55%) (used for quorum calculation)

[‎31.‎10.‎2019 16:03]

Quorum achieved: yes

[‎31.‎10.‎2019 16:05]

Voting Members: 6 of 9 (66%) (used for quorum calculation)

[‎31.‎10.‎2019 16:06]

2. Approve agenda [8:05 am]

[‎31.‎10.‎2019 16:06]

Shift 4.a.iii until Mark can join the call

[‎31.‎10.‎2019 16:07]

5.b.i: new issue for V4.01: ODATA-1339 - Make examples 8 (entity type) and 86 (record _expression_) consistent

[‎31.‎10.‎2019 16:09]

Mike: customer question

[‎31.‎10.‎2019 16:09]

3. Approve minutes from previous meeting(s)

a. Minutes from October 24, 2019 TC meeting: https://www.oasis-open.org/committees/download.php/66107/Minutes%20of%202019-10-24%20Meeting%20%23272.docx

[‎31.‎10.‎2019 16:09]

Minutes are approved

[‎31.‎10.‎2019 16:09] Mike Pizzo:

Customer’s team has developed a Restful Service with OData protocol on which in the URL there are certain character like “(“, “)”, ” [“, “]” and “&” are implemented (example: https://service-endpoint/api/V2/ControllerName/ActionName(Id=[508,509])). OData supports direct usage of the mentioned characters in the URL however there is other explanation in the https://tools.ietf.org/html/rfc3986#section-2.2 which says that the characters are regarded as gen-delims and must be encoded.

Section 2.2 IETF RFC-3986:

2.2. Reserved Characters
URIs include components and subcomponents that are delimited by
characters in the "reserved" set. These characters are called
"reserved" because they may (or may not) be defined as delimiters by
the generic syntax, by each scheme-specific syntax, or by the
implementation-specific syntax of a URI's dereferencing algorithm.
If data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.

Berners-Lee, et al. Standards Track [Page 12]
________________________________________

RFC 3986 URI Generic Syntax January 2005

reserved = gen-delims / sub-delims

gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"

sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="

[‎31.‎10.‎2019 16:13] Mike Pizzo:

Do we have a conflict between OData's direction not to encode the parens (and equals) in the parens-key syntax, and the section on Reserved Characters in IETF RFC-3986?

[‎31.‎10.‎2019 16:15]

https://docs.oasis-open.org/odata/odata/v4.01/csprd06/part2-url-conventions/odata-v4.01-csprd06-part2-url-conventions.html#sec_URLParsing

[‎31.‎10.‎2019 16:17] Mike Pizzo:

No conflict. Parens, equals, commas are a not delimiters in the generic syntax, nor the scheme-specific syntax, but they are a delimiter in the OData implementation-specific syntax. Therefore, they do not need to be encoded, as defined as delimiters by OData, but would need to be encoded if used in a data (i.e., key) value.

Note that, as per above reference, it would be okay to encode the parens, but not required.

[‎31.‎10.‎2019 16:18] Mark Biamonte:

Just joined now

[‎31.‎10.‎2019 16:18]

No Title

4. Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php?sort_field=due_closed_date] [8:15 am]

a. Upcoming

i. #0039 Concept for Compact JSON data format – Hubert Heijkers – 2020-01-31

ii. #0037 Concept for binary data format – Hubert Heijkers – 2020-03-26

iii. #0036 Register the OData- headers and preferences with IANA – Mark Biamonte – 2018-07-26

[‎31.‎10.‎2019 16:21] Mike Pizzo:

Mark's summary of the thread:

[‎31.‎10.‎2019 16:21] Mike Pizzo:

Response from IANA on our clarification of the Isolation Header:

Hi Chet,
We have a response from the reviewer:
===

I think that either:
(1) the specification referenced by the header registration should not indicate a syntax that allows the "OData-" to be dropped in the header name - I judge that could be source of confusion in the future.

or
(2) two separate registrations are submitted for "OData-Isolation" and for "Isolation", referencing the same specification. Given the push-back against the latter, I anticipate that the latter might become a provisional registration with an "IESG warning" attached, while the unabbreviated form may be a permanent registration. I'd also suggest adding a note to the permanent registration.
===

thanks,
Amanda Baber
Lead IANA Services Specialist

Chet followed that up with this question:

Amanda, one question: in option 2, would we draft the IESG warning or would that be attached by an IESG expert? I am discussing the alternatives with the TC. Option 1 will require that they take the specification through the review and approval process again and that will take time. So I want to be sure I fully understand alternative 2.

Thank you very much for your help,
/chet

Finally IANA’s response to Chet’s question:

Hi Chet,
We have a response from the reviewer:
===

We (I?) would draft the warning (but the details could be open to discussion).

The intent of the note on the permanent registration would be make make it clear that the registration applies only to the non-abbreviated syntax. The note applied to the other registration would be to the effect that the header field name is controversial, and its use is not recommended.

I think it would be better to avoid using the abbreviated form altogether. I don't know in what context the extra 6 characters are regarded as being too verbose, but can't imagine that being a significant concern for use with Internet protocols covered by the header field registry.

===

Best regards,
Amanda Baber
Lead IANA Services Specialist

[‎31.‎10.‎2019 16:27]

Go with option 2 - one permanent, one provisional registration

[‎31.‎10.‎2019 16:27]

Mark and Mike will follow up on this

[‎31.‎10.‎2019 16:27]

5. Issues [8:50 am]

a. APPLIED

i. ODATA-1337 Clarify use of @Core.ContentId in delta update

[‎31.‎10.‎2019 16:38] Mike Pizzo:

I move to accept the application of ODATA-1337 as applied.

[‎31.‎10.‎2019 16:38] Borges, Matt:

I second

[‎31.‎10.‎2019 16:39]

ODATA-1337 can be CLOSED as applied

[‎31.‎10.‎2019 16:39]

https://issues.oasis-open.org/browse/ODATA-1339

[‎31.‎10.‎2019 16:44]

ODATA-1339 is OPENB

[‎31.‎10.‎2019 16:45]

Example 86 also shows how to "morph" one entity type into another

[‎31.‎10.‎2019 16:46]

Make this consistent by swapping DirectSupervisor and Manager, making the type in example 8 the "source" that is morphed, and describe the target type in the description of example 86

[‎31.‎10.‎2019 16:46]

c. Vocabularies: NEW or OPEN with concrete proposal

i. ODATA-1275 Describe structure of "JSON properties"

1. https://github.com/oasis-tcs/odata-vocabularies/pull/52/files

2. https://github.com/oasis-tcs/odata-csdl-schemas/pull/9/files

[‎31.‎10.‎2019 17:01]

Problem: how to express the media type of the "stream annotation" in CSDL XML and JSON

[‎31.‎10.‎2019 17:01]

Proposal: use term Core.MediaType and extend its meaning to cover streams

[‎31.‎10.‎2019 17:10]

Ralf to update proposal and pull requests to reflect today's discussion

[‎31.‎10.‎2019 17:12]

6. OData Dictionary [9:20 am]

a. Document Walkthrough

i. https://1drv.ms/w/s!AlFcFKQNWuoXiRmtz6Yd6yIBZ9tZ?e=G9Dgub

[‎31.‎10.‎2019 17:26]

Mike: everyone check/edit the document until November 21st, then use December 5th for cleanup and then move it to GitHub

[‎31.‎10.‎2019 17:29]

7. Next meetings [9:50 am]

a. Thursday November 07, 2019 during 8-10 am PST (17:00-19:00 CET)

b. Thursday November 14, 2019 during 8-10 am PST (17:00-19:00 CET)

c. Thursday November 21, 2019 during 8-10 am PST (17:00-19:00 CET)

d. Thursday November 28, 2019 No meeting, Thanksgiving in the USA

e. Thursday December 05, 2019 during 8-10 am PST (17:00-19:00 CET)

[‎31.‎10.‎2019 17:31]

Mike can't attend on November 14

[‎31.‎10.‎2019 17:31]

George can't attend on November 14

[‎31.‎10.‎2019 17:32]

9. AOB and wrap up [9:55 am]

[‎31.‎10.‎2019 17:33]

Meeting is adjourned

From: odata@lists.oasis-open.org <odata@lists.oasis-open.org> On Behalf Of Handl, Ralf
Sent: Mittwoch, 30. Oktober 2019 16:44
To: odata@lists.oasis-open.org
Subject: [CAUTION] [odata] Agenda for OData TC meeting on 2019-10-31

Here [1] is a draft agenda for the OData TC (Technical Committee) meeting scheduled on Thursday October 31, 2019 during 8-10 am PST (16:00-18:00 CET). For additional information, such as dial-in details and chat room, refer to [2]. For TC timeline, see [3]. Feel free to suggest additions or modifications.

Thanks.

[1] Agenda

1. Roll call [8:00 am]

a. Self-registration link: https://www.oasis-open.org/apps/org/workgroup/odata/event.php?event_id=48010

2. Approve agenda [8:05 am]

3. Approve minutes from previous meeting(s)

a. Minutes from October 24, 2019 TC meeting: https://www.oasis-open.org/committees/download.php/66107/Minutes%20of%202019-10-24%20Meeting%20%23272.docx

4. Review action items [Action item list: https://www.oasis-open.org/apps/org/workgroup/odata/members/action_items.php?sort_field=due_closed_date] [8:15 am]

a. Upcoming

i. #0039 Concept for Compact JSON data format – Hubert Heijkers – 2020-01-31

ii. #0037 Concept for binary data format – Hubert Heijkers – 2020-03-26

iii. #0036 Register the OData- headers and preferences with IANA – Mark Biamonte – 2018-07-26