On Mar 21, 2010, at 3:12 PM, Thomson, Martin wrote: > Ben wrote: >> There's a few ways to handle that: >> >> 1) Treat rate-control as an informative reference, and say you're doing >> something mostly like rate control, but not quite identical. That would >> require quite a bit more normative language to describe what you're actually >> doing. >> >> 2) Make this draft update rate-control to allow for empty bodies when you >> don't have location info yet. Put some tightly constrained language around >> it. so that this doesn't become a _general_ udpate. >> >> 3) Since rate-control has, to my knowledge, not been pubreq'd yet, try to >> get the authors to modify the language to allow for empty bodies for this >> use case. >> >> I personally think 3 is the best path forward, as I think the empty notify >> is generally useful for rate-control, and implementor are likely to do it >> anyway. > > I was not under the impression from reading rate-control that that document > was modifying 3265 to prevent notifiers from sending an empty notify. But, > your suggestion is a reasonable one. Reading the rate-control text you > quoted earlier in the thread could lead to the impression that this is the > case. I've added the rate control authors to the thread. >
I don't think it modifies 3265 in general, but it does seem to normatively prevent empty NOTIFY requests as a result of a max-interval expiration. > --Martin _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
