Dear all, We have finally added JSON Patch (application/json-patch+json) as an allowed incremental encoding format. This is reflected in -07.
Now, ALTO incremental updates can use both JSON patch and JSON merge patch. Although both are complete, in that they can represent all changes, they have different encoding efficiencies: JSON patch can work well for arrays, and JSON Merge Patch (application/merge-patch+json), is cleaner in the general case, in particular for key-value based objects. As much as we want to keep simplicity, we see use cases where both are needed. There is a possibility to develop a unifying incremental encoding scheme, but we opt to use existing techniques whenever possible. We feel that this is a quite powerful, elegant mechanism. My hat off to Wendy, who came up w/ the design. Any comments will be greatly apprecIiated! Richard On Mon, Jul 3, 2017 at 9:13 PM, <[email protected]> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Application-Layer Traffic Optimization of > the IETF. > > Title : ALTO Incremental Updates Using Server-Sent > Events (SSE) > Authors : Wendy Roome > Y. Richard Yang > Filename : draft-ietf-alto-incr-update-sse-07.txt > Pages : 40 > Date : 2017-07-03 > > Abstract: > The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol > provides network related information, called network information > resources, to client applications so that clients can make informed > decisions in utilizing network resources. For example, an ALTO > server can provide network and cost maps so that an ALTO client can > use the maps to determine the costs between endpoints when choosing > communicating endpoints. > > However, the ALTO protocol does not define a mechanism to allow an > ALTO client to obtain updates to the information resources, other > than by periodically re-fetching them. Because some information > resources (e.g., the aforementioned maps) may be large (potentially > tens of megabytes), and because only parts of the information > resources may change frequently (e.g., only some entries in a cost > map), complete re-fetching can be extremely inefficient. > > This document presents a mechanism to allow an ALTO server to push > updates to ALTO clients, to achieve two benefits: (1) Updates can be > immediate, in that the server can send updates as soon as they are > available; and (2) Updates are incremental, in that if only a small > section of an information resource changes, the server can send just > the changes. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-07 > https://datatracker.ietf.org/doc/html/draft-ietf-alto-incr-update-sse-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-incr-update-sse-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
