W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2018

Re: Request for status re: NEW PREFERENCE - allow-entityreferences, callback, continue-on-error, include-annotations, maxpagesize, omit-values, and track-changes

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 20 Dec 2018 19:05:45 +1100
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "Mark Biamonte (Progress)" <Mark.Biamonte@progress.com>, "Ralf Handl (SAP)" <ralf.handl@sap.com>, "Julian F. Reschke" <julian.reschke@greenbytes.de>, James M Snell <jasnell@gmail.com>
Message-Id: <B05E6148-42B8-4656-9272-3B0643314B06@mnot.net>
To: Chet Ensign <chet.ensign@oasis-open.org>
Hi Chet and Mark,

I agree that some of these are potentially generic. See specific comments below.

Generally, we like to see extensions that are generic being documented in a way that isn't specific to one application. For example, WebDAV's previous definitions of HTTP methods and status codes is now considered bad practice; if they were done today, we'd make sure to define them in their own document.

Note that's not a formal policy for HTTP preferences (AFAIK; ultimately it's up to the experts); just a preference that's been expressed and accepted in the community for other extension points that seems pretty applicable here. Experience has shown that people who aren't intimately familiar with the context will assume that those extensions are limited to that application.

Would there be a willingness in your community to spin some of these extensions into a separate, non-ODATA-specific document? Something else from OASIS would be fine, it doesn't need to be an RFC. I imagine that ODATA might still have something to say about their specific use in that protocol (which might resolve the question below).

Cheers,


> On 19 Dec 2018, at 8:18 am, Chet Ensign <chet.ensign@oasis-open.org> wrote:
> 
> Hi Mark,
> 
> Our thinking is that a number of the preferences may be of general use and are not specific to OData.  Looking at each of the preferences the ones we feel are of general interest and independent of OData are
> 
> ·         callback as an add-on to respond-async can be used with any payload format – respond-async defined in - https://tools.ietf.org/html/rfc7240 - author is James Snell  
> 
> ·         maxpagesize as an add-on to the "next" link relation, see https://www.iana.org/assignments/link-relations/link-relations.xhtml.  
> 
> ·         Can be used in Atom with <link rel="next" ... /> as we do it in the OData Atom format  
> 
> ·         Can be used with a link header with this relation, see https://tools.ietf.org/html/rfc5988 - author is Mark Nottingham 
> 
> ·         omit-values – interesting for other JSON or “name-value pair” formats  
> 
> ·         track-changes – can be used with other payload formats that allow representing “diffs”, e.g. JSON PATCH - https://tools.ietf.org/html/rfc6902 - author is Mark Nottingham 

I think I agree that these are potentially generic. However, their descriptions mention ODATA-specific concepts; e.g., "delta links" and ODATA capabilities. Could you factor those out into more generic things, omit them, or move them to ODATA-specific text elsewhere?


> The remaining three are less obvious to us as to whether they would be useful in other cases
> 
> ·         allow-entityreferences – needs a concept and representation of “references” to be useful  
> 
> ·         continue-on-error – needs a “batch” or “bulk” format  
> 
> ·         include-annotations – needs annotations 
> 
> Do you or other experts know of existing specs that utilize the concept of references, batch or bulk operations or annotations?  If so could any of these remaining three be useful to those specs?

I think I agree that these are less likely to be useful generic. I'd encourage you to continue using the odata.* names.

Cheers,


--
Mark Nottingham   https://www.mnot.net/
Received on Thursday, 20 December 2018 08:06:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:27 UTC