Hi Martin and all, A new revision (-15) has been submitted to address the Httpdir last call review. Highlights: - Persistent connection and related sections are removed. A short discussion is added to the appendix explaining the reason. - A new heartbeat request is introduced to check client liveness for a TIPS view. - <tips-view-uri> is now an absolute path to enable potential scoping with subdomain. - Specs for push-mode TIPS and related sections are removed, except a short discussion left in the appendix. Please let us know if the proposed changes resolve the issues. Thanks! Best, Kai > -----Original Messages----- > From: kaigao@xxxxxxxxxx > Send time:Thursday, 10/05/2023 16:25:23 > To: "Martin Thomson" <mt@xxxxxxxxxxxxxx> > Cc: ietf-http-wg@xxxxxx, alto@xxxxxxxx, draft-ietf-alto-new-transport.all@xxxxxxxx, last-call@xxxxxxxx > Subject: Re: [alto] Httpdir last call review of draft-ietf-alto-new-transport-14 > > > > > > -----Original Messages----- > > From: "Martin Thomson" <mt@xxxxxxxxxxxxxx> > > Send time:Thursday, 10/05/2023 11:26:32 > > To: kaigao <kaigao@xxxxxxxxxx> > > Cc: ietf-http-wg@xxxxxx, alto@xxxxxxxx, draft-ietf-alto-new-transport.all@xxxxxxxx, last-call@xxxxxxxx > > Subject: Re: Httpdir last call review of draft-ietf-alto-new-transport-14 > > > > On Thu, Oct 5, 2023, at 13:53, kaigao@xxxxxxxxxx wrote: > > > We will really appreciate it if you can point us to any work that has a better > > > design, as it looks like a generic problem. > > > > The namespacing issue is easy to address using the design I sketched out. That's a pretty common pattern. > > > > The heartbeating mechanism you describe could work, though it could end up being wasteful. > > > > There is an alternative here, which is to avoid server-side state and put > > the necessary state into the URL you return to clients when "creating" a view. > > Then you don't need to rely on liveness checking so much. You can have server > > side caches for any essential state that carries between requests, but you don't > > rely on that state being present. Any state can be cleared as necessary (on a > > timer, say), without needing constant pings, because it can be recovered if > > necessary from the URL. If you can get away with having no server-side state at > > all, this is even better, but I don't know how much these views represent > > substantial investment in computation or state such that it might be awkward to > > transfer that with every request. > > Unfortunately this is not feasible in our case. The fundamental states include > > 1. resource of interest > 2. parameters (e.g., filters) > 3. data & updates of the interested resource based on the parameters > 4. the current version of the client's data > > We already encode 4 in the URL but the first 3 (especially 3) are the most > resource-consuming states. Unfortunately 3 can only be maintained by the > server and depend on 1 & 2. > > In the ideal case, the client should release the resources when it terminates. > However, in case of failure or DoS attack, the heartbeat mechanism is needed > to identify resources that are no longer being used. > _______________________________________________ > alto mailing list > alto@xxxxxxxx > https://www.ietf.org/mailman/listinfo/alto -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
