Re: [Geopriv] Long review of draft-ietf-geopriv-loc-filters-07

[Brian Rosen <br at brianrosen.net>]

Thank you for your review.  The co-authors will probably have some more
comments as we actually edit the document, but I wanted to respond to some
of your more important comments now.

Your comment that '"Alternative" makes it seem like Conveyance doesn't need
to be used at all -- which is absolutely false. The only want a NOTIFY can
contain a PIDF-LO is through understanding of SIP Location Conveyance. This
forces Conveyance to be moved from an Informative reference to a Normative
reference.  If anything, this doc is a formal update to Location Conveyance
because it specifies how to augment Conveyance by doing additional
functions/capabilities not found in Conveyance.'

is incorrect.  Sending location via a presence service was the initial way,
and until -conveyance, the only way to send location using the SIP protocol.
The appearance of -conveyence in no way diminishes, or alters, use of
presence to send location.  Presence IS an alternative way to use SIP to
send location.  It uses NOTIFY without a Geolocation header.  This document
discusses presence, and is not related to -conveyence, and this document in
no way updates -conveyence.

Your comment 'Does this accurately describe an extension (to 4661)?'
confuses me.  I did check, 4661 describes 'extensions'.  We do extend the
schema in a way that I think conforms to section 4 of 4661.  What were you
concerned about?

When you say 'What about leaving a room into a hallway? Neither are a circle
or a polygon (that's been allowed into the Geopriv WG to date - though a
couple of IDs have tried to have the WG include these).
This might be covered by #4, but want to be sure.'  were you asking about
leaving a room described using the civic form of location?  If so, then yes,
#4 is how you describe that.  One could describe the room as a polygon of
course.

Your concern about #5 (type of information) is answered in section 3.5.  The
filter allows you to ask for geo, civic or any.

Yes, you would need four <changed> filters to express an 'OR'.  The current
syntax has implied 'AND'.  I think that is okay.  I would like to hear from
others who may have an opinion on that.  It would be a large syntax change
to come up with a reasonable way to have AND/OR syntax included within this
element, and I don't think it's worth it.  The alternative of having a flag
that was set to either "AND" or "OR" doesn't strike me as reasonable.

I think it probably is a mistake to use "LIS".  Rather, I think PS is
appropriate, or maybe just Notifier.

You said "It should be possible for the subscriber to be told - if the
'exact' attribute is set - that is has location, but not in the format the
subscriber wants it in."

Could you suggest a reasonable syntax?  I thought about this for a while,
and while I'm somewhat sympathetic to the problem you raise, there is no
similar syntax in any other filter: if you filter away the data, you aren't
told that there was data, but your filter made it appear as if there is no
data (you don't get a NOTIFY). I would think that if we did something on
this, it would have to be generalized.

In 3.6, I don't think the text that refers to "immediately available" is
talking about something relating to the initial NOTIFY.  Rather,  it's
talking about location update in the context of partial state availability.
If the filter says to, you get a partial state update in a time determined
by rate-control.

While I think we can reword the text you are objecting to below Figure 8,
which discusses changing the rate after the first update, your final comment
'Where does this doc say that getting location for the emergency case MUST
NOT have a one-time only subscription (because of just what is in the
paragraph above?' is confusing.  The text is talking about a circumstance
where the emergency service wants TWO locations: one which is available
quickly, and is good enough to route the call, and then another, subsequent
location, which is more accurate, and good enough to dispatch to.  However,
getting both of them is optional.  Some elements (such as the routing
elements) will need only the first.  Some elements (the dispatcher) only
needs the second.  Some need both.

Brian


On 11/2/09 9:17 PM, "James Polk" <jmpolk at cisco.com> wrote:

> I have attached my review of draft-ietf-geopriv-loc-filters-07.
> 
> It is a PDF of my marked up version.  It has enough comments and
> suggestions that putting this in email would be very difficult - but
> I will if the chairs believe that's best.
> 
> Some of the comments are nits, some of the comments were where a
> topic or sentence didn't make sense (perhaps with its placement were
> it was in the paragraph), and some of the comments were technical.  I
> hope they are obvious when anyone reads them.
> 
> I can send the MS WORD version with the active track changes to the
> authors if they want that version.
> 
> If there are any questions or comments about my review comments,
> please don't hesitate to send me a note.
> 
> James
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv