So, the rate control does recognize that the first notify message can be empty or might not contain all state: $3.2: Thus, the first notification might be empty, or certain values might be absent. The text that was originally quoted, that we're discussing is this: A compliant notifier MUST generate notifications whenever the time since the most recent notification exceeds the value in the "max- interval" parameter. Depending on the event package and subscriber preferences indicated in the SUBSCRIBE request, the NOTIFY request MUST contain either the current full state or the partial state showing the difference between the current state and the last successfully communicated state. The second sentence, taken out of context might be interpreted as Ben did - a blanket prohibition on empty notify messages. Reading through again, with complete context, I'm not sure that I agree with this assessment. If the rate-control editors are amenable to a clarification in this section, it would be nice, but I don't see it as necessary. --Martin ________________________________________ From: Ben Campbell [ben@xxxxxxxxxxxx] Sent: Sunday, 21 March 2010 3:31 PM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: Thomson, Martin; aki.niemi@xxxxxxxxx; krisztian.kiss@xxxxxxxxx; salvatore.loreto@xxxxxxxxxxxx Loreto; Cullen Jennings; Rohan Mahy; IETF-Discussion list; General Area Review Team; Hannes Tschofenig; geopriv@xxxxxxxx; Adam Roach Subject: Re: Gen-ART LC/Tekechat Review of draft-ietf-geopriv-loc-filters-10 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