On Mar 21, 2010, at 3:24 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > If rate-control gives the impression that it disallows empty NOTIFYs to > be sent then rate-control needs to change. If location is not available > at the time when the SUBSCRIBE hits the location server then the server > just cannot send something. > > Do you agree with me? > We're not talking about NOTIFYs sent in response to a SUBSCRIBE. We're talking about NOTIFY's sent as a result of a max-interval expiration, when using the rate-control mechanism. The rate-control draft requires content in that situation, and the geopriv-loc-filters draft recommends empty notifies in the same situation. >> -----Original Message----- >> From: ext Ben Campbell [mailto:ben@xxxxxxxxxxxx] >> Sent: 21 March, 2010 18:23 >> To: Thomson, Martin >> Cc: Tschofenig, Hannes (NSN - FI/Espoo); aki.niemi@xxxxxxxxx; >> krisztian.kiss@xxxxxxxxx; salvatore.loreto@xxxxxxxxxxxx; >> Cullen Jennings; Rohan Mahy; IETF-Discussion list; General >> Area Review Team; Hannes Tschofenig >> Subject: Re: Gen-ART LC/Tekechat Review of >> draft-ietf-geopriv-loc-filters-10 >> >> >> 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 Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf