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? >-----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