Rohan Mahy wrote:
> As the original author of draft-ietf-geopriv-loc-filters I would like
> to provide some explanation of what I was thinking. I no longer have
> any plans to stay actively involved with this work, but I at least
> hope that others have the option of understanding where I was coming
> from and my current beliefs on the subject.
Thanks for weighing in. I appreciate understanding the historical basis
for the decisions made in the development of this docment.
> First, the last version of the draft for which I was the editor
> referenced the throttle mechanism in the Niemi draft, and I agree with
> Adam that the throttle mechanism is still the correct way to solve
> that problem. I think this is somewhat unrelated to the rest of the
> issues in Adam's email.
>
> Next, I think there are many good technical reasons to have a set or
> family of multiple filter mechanisms. I would like to point out that
> draft-ietf-geopriv-loc-filters predates RFC4660/4661 (and its source
> I-Ds).
That does go a long way towards explaining the divergent formats.
> RFC4660 describes itself as *the* filter mechanism instead of *a*
> filter mechanism, but RFC4660 was not the first nor will it be the
> last such filter mechanism proposed.
Well, at least *the* filter format for PIDF and its extensions.
Your implications about the immediate necessity for alternate formats
confuses me a bit. 4660/4661 was explicitly designed to be arbitrarily
extensible. In a degenerate case, you could take all the syntax defined
in geopriv-loc-filters and wedge it into the 4661 syntax (with
accompanying description of semantics). Now, I clearly think that's the
wrong thing to do, but it certainly would address a substantial portion
of my concerns.
> I see a number of problems with using only the RFC4660 event filtering
> mechanism for the uses described in draft-ietf-geopriv-loc-filters.
> One of these problems is difficulty in negotiating support for the
> necessary extensions. How does a subscriber find out if all the right
> bits for location filtering are supported?
Require/Supported?
> By using a separate filter body, that negotiation can be done
> explicitly based on MIME type and the built-in RFC 3261/3265
> negotiation mechanism, instead of implicitly based on some vague
> combination of factors.
MIME-type is a very blunt (and often ambiguous) instrument for
negotiating support of a protocol feature. If I advertise that I
understand "application/resource-lists+xml", am I saying that I support
ad-hoc list subscriptions, or subscriptions to XCAP documents?
We have an explicit feature negotiation mechanism for this kind of
thing. It seems a more appropriate choice.
> The other major technical problem I see relates to representing
> continuously variable quantities. I think the semantics and processing
> of the filter in RFC4660/4661 is cumbersome in the specific case of
> smooth gradients. RFC4660/4661 is a filter format and package designed
> to filter discrete changes in an XML document. To use the RFC4661
> filter body generically on continuous gradients requires the notifier
> to constantly regenerate a dynamic XML document and the filter format
> to figure out if the document has changed. For example, a subscriber
> interested in the location of the piece of medical equipment (say a
> dialysis machine) does not care about small motions of the machine
> from one side of the room to another, but it does care about the
> equally small movement between a room and the hallway and vice versa.
Generation of a literal, serialized XML document and then running a
conventional XPATH expression across it is certainly one very simplistic
way that this could be implemented, but it is certainly not the only one.
Fundamentally, XML is just a textual representation of a tree of data.
The underlying tree can be indexed, and the nodes indicated by XPATH
expressions can be cached for O(1) operation on live data. Done
correctly, this won't be any more inefficient than any other approach.
> Finally, much of my motivation for this work is my belief that it is
> useful to have a moderately narrow "classic" definition of presence,
> and to have other event packages as first class citizens who are peers
> with the presence event package. My moderately narrow definition of
> "classic presence" means "willingness and availability to
> communicate". In my view this "classic presence" always contains
> willingness and availability status, but can contain all manner of
> other supplementary information including (possibly obfuscated,
> fuzzed, and filtered) location data, offhook status, and calendar
> data. However, I believe there are many times when a subscriber who is
> not a watcher wants to get only (raw) location, calendar, or dialog
> status from a notifier (who is not a presentity) as a first class
> object. This is the case for the dialysis machine example. I designed
> the filter format so it would be hopefully useful whether it was
> contained in a presence subscription (supplementary location) or a
> separate location event package of some kind.
As I mentioned initially, I haven't followed the development of this
document, so I don't know whether the property of being useful in
conjunction with other 4461 criteria was in earlier drafts. But that
capability is certainly absent now. Or perhaps I'm missing something
that you can clear up.
Can you show an example of a filter that says, "I want to be notified
whenever sip:rjs@nostrum.com changes from closed to open or moves more
than 15 feet"?
/a
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Fri, 25 Jul 2008 10:39:03 -0500
This archive was generated by hypermail 2.1.8 : Fri Jul 25 2008 - 11:39:35 EDT