Hi Mirja, Thank you so much!
I had text on 5, 6, 7, but they were not moved to the new version. I will handle shortening abstract, and clarify http/1.1 right after the last call. Thanks again! Richard On Fri, Feb 21, 2020 at 6:02 AM Mirja Kuehlewind <[email protected]> wrote: > Hi Richard, > > Thanks for the update! I just request IETF last call which should start > today. You can still update the document but you might want to wait until > the end of the IETF last call in order to also address potential last call > comments (mainly be SECDIR, GENART, and OPSDIR reviews.) > > I believe there are also some small open points from my review (probably > points 5, 6, and 7) which you might want to consider. And please also > consider shortening the abstract. You can also look at Vijay’s summary in > the shepherd-write as an example. > > One more editorial comment on the latest changes: Based on the intro text > in section 3 and the title heading of section 3.3, I actual got confused if > you proposed now to use HTTP/2. Maybe clarify early on in that section that > HTTP/1.1. is used. > > Thanks! > Mirja > > > > > On 21. Feb 2020, at 07:53, Y. Richard Yang <[email protected]> wrote: > > > > Hi Mirja, > > > > We have submitted a new version. If you need to move on forward this > week, > > please use the submitted version. If you can do so by Monday morning, > then > > we plan to take a couple reads during this weekend. > > > > Your reviews helped greatly and we greatly appreciate them! > > > > Richard > > > > On Tue, Feb 18, 2020 at 6:46 PM Y. Richard Yang <[email protected]> wrote: > > > >> Hi Mirja, > >> > >> I believe that we have a grasp of all of your feedback. We will submit > in > >> the next couple days, a new version directly to the data tracker, as you > >> suggested. > >> > >> Thank you so much! Really appreciate it! > >> > >> Richard > >> > >> On Tue, Feb 18, 2020 at 4:32 AM Mirja Kuehlewind <[email protected]> > >> wrote: > >> > >>> Hi Richard, > >>> > >>> Please see inline. > >>> > >>>> On 17. Feb 2020, at 21:03, Y. Richard Yang <[email protected]> wrote: > >>>> > >>>> Hi Mirja, > >>>> > >>>> Thanks a lot for the ultra-fast response. Please see below. > >>>> > >>>> On Mon, Feb 17, 2020 at 4:21 AM Mirja Kuehlewind <[email protected] > > > >>> wrote: > >>>> Hi Richard, > >>>> > >>>> Please see below. > >>>> > >>>>> On 17. Feb 2020, at 05:44, Y. Richard Yang <[email protected]> wrote: > >>>>> > >>>>> Hi Mirja, > >>>>> > >>>>> Please see below. > >>>>> > >>>>> On Fri, Feb 14, 2020 at 4:32 PM Mirja Kuehlewind < > [email protected]> > >>> wrote: > >>>>> Hi authors, > >>>>> > >>>>> I reviewed draft-ietf-alto-incr-update-sse in order to potentially > >>> get this document through the process before I step down as AD in > March. I > >>> have a couple of technical questions below that I would some feedback > about > >>> before we move on to IETF last call and some fully editorial point > that can > >>> be updated anytime before final publication (e.g. also after IETF last > call > >>> has ended). > >>>>> > >>>>> However, I have one high level question that I would like to at least > >>> understand to justify it in the IESG before we moved on. Sorry that I > have > >>> not raised this earlier in the working group but I realised it just > now: > >>>>> > >>>>> HTTP/2 (and HTTP/3) support multiplexing, why is a separate service > >>> needed for stream control, instead of just using a different stream on > the > >>> same HTTP connection? > >>>>> Also note that I don’t find the justification, why HTTP/2 Server Push > >>> is not used, not very convincing and I’m afraid to get push-back from > the > >>> ART ADs. Especially given the problems describes in section 9.5. > However, > >>> we can give it a try. I think I would recommend to have the > justification > >>> in section 13.1 earlier in the document, e.g. in section 3. > >>>>> > >>>>> > >>>>> We are indeed designing an ALTO incremental based on HTTP/2 (/3). For > >>> now, we plan to clarify that the design is for earlier HTTP and move > 13.1 > >>> to Sec. 3. How does this sound? > >>>> > >>>> It’s okay. > >>>> > >>>> > >>>> However as you are already working on a design for HTTP/2 or HTTP/3, > >>> would it be better to finish this work up now and specify it from the > >>> beginning over this more modern protocols? Or is there a goos reason > why > >>> HTTP/1 support is needed? > >>>> > >>>> Thanks. We will finish this work now, for HTTP/1/1.1, as it is mostly > >>> done and HTTP/1/1.1 is widely adopted. . HTTP/2 is definitely gaining > >>> momentum (https://w3techs.com/technologies/details/ce-http2 states > 43.3% > >>> in Feb. 2020) and we will do the work during the next phase as soon as > we > >>> are done with this one. > >>> > >>> I don’t think that is a relevant number for alto because that's about > >>> Webservers already offering http/2. And I would assume an alto server > is > >>> usually not co-located with another Webserver. For alto the most > important > >>> question would be if the http sever implementation you are using is > >>> supporting http/2 and I think in terms of implementation most > platforms do. > >>> So if you run an alto server and want to use SSE with http/2 you need > to be > >>> willing to update you server; that’s it. > >>> > >>> Anyway, I think you need a bit more justification in the draft why this > >>> is http/1.1 based. > >>> > >>>> > >>>> > >>>>> > >>>>> And one more request before we move on, please add the actual > >>> Content-Length values to the examples and confirm that you did run the > >>> examples though a syntax checker! > >>>>> > >>>>> > >>>>> Yes. All fixed. > >>>> > >>>> Thanks! > >>>> > >>>>> > >>>>> > >>>>> Here are my other technical questions/comments: > >>>>> > >>>>> 1) In section 3.2.1 > >>>>> "This document adopts > >>>>> the JSON merge patch message format to encode incremental changes, > >>>>> but uses a different HTTP method, i.e., it uses POST instead of > >>>>> PATCH.” > >>>>> I don’t quite understand this sentence. As you use SSE, I guess you > >>> are using neither POST nor PATCH. The point here is that SSE has a > quite > >>> different communication model than otherwise in HTTP, so I’m not sure > what > >>> this statement actually tells me. > >>>>> > >>>>> > >>>>> Excellent review. We have revised the paragraph to be the following: > >>>>> > >>>>> "JSON merge patch is intended to allow applications to update server > >>> resources by sending only incremental changes. <xref target="RFC7396"/> > >>> defines the encoding of incremental changes (called JSON merge patch > >>> objects) to be used by the HTTP PATCH method <xref target="RFC5789"/> > > -- Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
