Hi Wendy and Richard, all,
during the Berlin meeting our valued chairman have invited me
to do one more review of draft-ietf-alto-incr-update-sse-02,
so here it is:
1. One general question
this document tries to make distribution of updates to ALTO information
more efficient, in particular when network/cost maps are large and
change frequently. It leverages two separate mechanisms to do so:
a) an efficient encoding for smaller updates to JSON structures
(e.g. ALTO network/cost maps) and b) server-initiated notifications as
opposed to the client frequently asking for updates.
For a), the document argues that JSON Merge Patch [RFC7386] is clearly
better suited than other similar mechanisms such as JSON Patch
[RFC6902]. I am not an expert in this field and just belive that this
assessment is correct. Furthermore, a client can de-facto disable this
mechanism by setting "incremental-updates" to false.
So far, so good.
For b), the document compares "SSE over HTTP 1.1" [W3C SSE Rec.] and
"HTTP 2 Server-Push" [RFC7540]. It argues that the second method is
technically superior, yet still specifies usage of the first one, in
order to allow faster deployment, as HTTP/2 libraries are not widely
available as of today. This seems to be a bit questionable to me, given
that getting this document published as an RFC will need at least
another half a year, but then it will live forever. What is the
timeframe we expect HTTP/2 implementations?
But my main question is: could this mechanism be made optional, similar
to JSON merge patch? I'm thinking of a client-initiated request
(GET/POST), something along the lines "give me the diff for the .. map
since tag ... (if the diff is larger than the current map or the server
has not enough history information or CPU power to create the diff, send
the full map instead)".
I am not really convinced that in every scenario sending a keepalive
message every 15 seconds is more efficient than the client asking for
updates in similar time intervals. Maybe this client-initiated request
with JSON merge patch can be done, maybe I overlooked something? Adding
some lines of discussion may be worth it.
2. Smaller issues and nits
Section 2 (and similar wording in 7.5):
The server selects the resource set for each stream,
although it is recommended that the set be closed under the ALTO
resource dependency relationship (i.e., the "uses" relationship).
This sentence is rather difficult to understand when reading the first
time. It made sense to me only after reading the following sentence.
Maybe reword:
The server selects the resource set for each stream. It is
RECOMMENDED that if a resource depends on one or more other
resource(s) (indicated with the "uses" attribute defined in RFC7285),
these other resource(s) should also be part of that stream.
****
General: replace references to RFC 2616 (which is now obsolete) with
references to its successors, 723[0-5]
****
Sec 4:
Messages are delimited by two new-lines (this is a slight
simplification; see [SSE] for details).
The "slight" sounds dangerous to me - an invitation not to read the
referenced document?
Maybe better:
In the following illustration, messages are delimited by two
new-lines. Please refer to [SSE] for the full specification
of message delimitation.
****
Sec 7 (Paragraphs before 7.1):
The abundance of "[Update] Stream [Control] (Service|resource)" is
difficult to read. I have the feeling that sometimes words were omitted,
which makes it even more difficult to read.
Maybe. did I get this right?
An Update Stream Service returns an Update Stream, i.e., a stream
of SSE messages, as defined
in Section 6. An Update Stream resource is used to request a new
Update Stream.
A server creates an Update Stream Control resource for each active
Update Stream. A client uses the Update Stream Control resource to
request that the corresponding Update Stream should no-longer
convey updates for a specifc resource,
or to request updates for
additional resources. Update Stream resources are listed in the
server's IRD, but Stream Control resources are not. Instead, the
first event that the server sends to the client has the URI for the
Update Stream Control resource for that stream (see Section 6.3.
****
Sec 7.3:
If ... the client MAY set the "tag" field to "tag" part of the
resource's version tag.
This sentence is difficult to read. Do the "" around the second "tag"
make sense? Is a "the" missing?
If that version is still current, the ALTO
Server SHOULD omit sending a full replacement update at the start of
the stream (see Section 7.6.2).
Could you explicitly state what it should do (send?) instead? Just nothing?
If that version is not current, the server MUST ignore the "tag" field.
Could you explicitly state what it should do (send?) after ignoring?
Just nothing? The full map?
****
Sec 7.3:
... SHOULD send the full-replacement message soon after the change ...
If I remember correctly we had a discussion on this list some years
ago whether RFC2119 language is adequate only for behavior that
can be blackbox-tested, or also for behavior that needs a whitebox test
to validate. I think we agreed that both is ok.
But "SHOULD" in conjunction with "soon" seems to me like going
a step too far.
****
Sections 8.2 and 8.6
If a request is successful, the server returns an HTTP "200
OK" response with Content-Type "text/plain" and no data.
is this good practice? Maybe better "204 No Content" ?
****
sec 12.3
Hence when sending a full network map or cost map, an ALTO
server SHOULD insert a new-line character periodically.
Approximately every 2,000 characters should be sufficient for most
SSE clients.
an uppercase SHOULD in conjunction with a very vague lowercase should?
Can this be expressed more specific?
Hence an ALTO server SHOULD NOT send lines longer than 2000 characters.
This can be achieved by adding new-line characters periodically.
Or is this someone else's problem and has been discussed and specified
elsewhere, so we can just add a pointer to that document?
****
sec 13.2
An outside party which can read the update stream response can obtain
the control URI and use that to send a fraudulent "remove" requests,
thus disabling updates for the valid client. This can be avoided by
encrypting the stream (see Section 15 of [RFC7285]).
This remedy implies that the server must use control URIs with enough
randomness, so an attacker cannot guess them. Should that be added in 8.1?
Or can we find a better mechanism to actually authenticate and autorize
requests to the control URI?
****
-- Sebastian
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
