Hi Wendy and Richard, all, this is to acknowledge that the new -03 of the sse draft addresses the issues in my review of the -02 version from Tue, 9 Aug 2016.
I also buy Wendy's arguments why JSON merge-patch without sse does not really make sense. However, the new -03 version also introduces some new minor issues: Sec 4: Each message has one or more lines, where a line is terminated by a carriage-return immediately followed by a new-line, a carriage-return not immediately followed by a new- line, or a new-line not immediately preceded by a carriage-return. This reads a bit clumsy. Maybe: Each message has one or more lines, where a line is terminated by a carriage-return (CR) character, a line-feed (LF) character, or a CR/LF character pair [SSE]. **** Sec 8.1: To prevent an attacker from forging a Stream Controller URI and sending bogus requests to disrupt other Update Streams, Stream Controller URIs SHOULD contain sufficient random redundency to make it difficult to guess valid URIs. redundency is misspelled and probably also not a good term here. Also forging - I think the correct description of the security threat is guessing a valid URI, not forging a new one. Maybe better: To prevent an attacker from guessing a Stream Controller URI and sending bogus requests to disrupt other Update Streams, Stream Controller URIs SHOULD include a sufficiently random component (e.g., a nonce value). **** Sec 9: In the examples: 204 No Content is not followed by a Content-Length: 0 header (see Sec. 3.3.2 of RFC 7230: A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content).) Thanks Sebastian On Tue, Sep 13, 2016 at 09:16:45AM -0700, [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-03.txt > Pages : 41 > Date : 2016-09-13 > > Abstract: > The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol > provides network related information to client applications so that > clients may make informed decisions. To that end, an ALTO Server > provides Network and Cost Maps. Using those maps, an ALTO Client can > determine the costs between endpoints. > > However, the ALTO protocol does not define a mechanism to allow an > ALTO client to obtain updates to those maps, other than by > periodically re-fetching them. Because the maps may be large > (potentially tens of megabytes), and because only parts of the maps > may change frequently (especially Cost Maps), that can be extremely > inefficient. > > Therefore this document presents a mechanism to allow an ALTO Server > to provide updates to ALTO Clients. Updates can be both immediate, > in that the server can send updates as soon as they are available, > and incremental, in that if only a small section of a map 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's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-incr-update-sse-03 > > > 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
