> 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@estacado.net]
>> Sent: 21 March, 2010 18:23
>> To: Thomson, Martin
>> Cc: Tschofenig, Hannes (NSN - FI/Espoo); aki.niemi@nokia.com;
>> krisztian.kiss@nokia.com; salvatore.loreto@ericsson.com;
>> 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
>>
>>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
