Re: [Geopriv] Items of cross group interest

["Winterbottom, James" <James.Winterbottom at andrew.com>]

James,

There are two distinct use cases in location conveyance.
The first is that I need to route a message from A to B and I need
location information to do that. In this case location is, essentially,
routing information, and a SIP error is appropriate.

The second use-case is that I am sending a end-point some information in
a SIP body. The SIP body in this case is simply transporting
application-level data that will be consumed by a higher-level
application, and SIP is simply serving as a transport to achieve that.
In this case I don't believe that a SIP header is appropriate, indeed it
is a protocol layering violation to use one!

The location subscription draft that Martin, Hannes and I have written
follows the layering principles described above. Where the location
application has been unable to provide the data requested it indicates
this with an application-level error.  You will note that we had a lot
of discussion in ECRIT and Geopriv about exactly these topics with
regards to using HTTP as a transport for HELD and LoST. These are
exactly the same principles and results are that we have clean protocol
design.

Cheers
James


> -----Original Message-----
> From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On
Behalf
> Of James M. Polk
> Sent: Wednesday, 23 July 2008 3:02 AM
> To: Salvatore Loreto
> Cc: 'GEOPRIV'
> Subject: Re: [Geopriv] Items of cross group interest
> 
> At 04:26 AM 7/20/2008, Salvatore Loreto wrote:
> >Location Event Package:
> >I support the introduction of a new event package, different from
> >presence, to return
> >presence information.
> >
> >There are several reasons to have a different event package, among
them:
> >- LIS and Presence servers could be separate and then there would be
> >a need to specify communication
> >between them whenever a location request is received by a presence
> >server; or we should specify how
> >to route the location request to LIS instead of Presence
> >- LIS server can be present in a network that does not have any
> >Presence server; in this scenario LIS
> >server could be overloaded with Presence requests, it doesn't support
at
> all
> >- LIS bring Lawful requirements to meet, where a Presence server does
not.
> 
> so, having read the thread through Brian's message early on 7/22, I
> have a simple observation Salvatore, you want the separate event
> package to route the SIP SUBSCRIBE correctly, the rest is just
> attempting to justify this core requirement.
> 
> I don't agree with your requirement - and Brian has already said why,
> but let me add  -- that if you have a SIP request routing problem, an
> event package name differentiation shouldn't be relied upon to make
> the routing decision.
> 
> >Moreover the location-package draft:
> >- reuses the location response and error message from HELD, and I
> >think is a clever idea.
> >- define the What (the form of location) capability that is not
> >present in the loc-filter draft,
> >and also the When capability seems to be slightly different from
> >what is defined in loc-filter.
> >- the extension point is also another important capability that give
> >the possibility to reuse what we already
> >have in loc-filter.
> >
> >So I do believe we have to progress this draft, and I am ready to
> >give my help on it.
> >
> >
> >- Loc-filters:
> >I have already send out a couple of days ago a mail where I have
> >provided some comments
> >and expressed my support both to the draft in general and to the
> >idea of include in the draft filters
> >related to the quality (confidence/uncertainty).
> >I have also other comments/suggestion to provide to this document,
> >but I'll do in a different mail.
> >
> >In my view the definition of new event package for location doesn't
> >diminish the need of Loc-Filter,
> >even because the location-package make possible use Loc-Filter.
> >what we should avoid is an overlap between the two drafts.
> >
> >
> >-Location-get draft:
> >I have also read this draft, and I should say that (if I understood
> >it correctly) it only listen the set of filter that a *geopriv
> >seeker* could specify in order to get specific pieces of location
> information.
> 
> gee, but here are two points from why you like the location-package
> draft that this draft also does
> 
> >         - define the What (the form of location) capability that is
> > not present in the loc-filter draft,
> >         and also the When capability seems to be slightly different
> > from what is defined in loc-filter.
> 
> the "clever" errorring that the location-package draft shouldn't
> exist, because everything should be based on what the SIP subscriber
> understands, which is a SIP response - which is stated in RFC 3265
> and 4661 already (which are nearly complete as is). The Location-get
> draft will expand this list (probably only slightly) to exactly what
> should be done by the subscriber UAC for each type of location based
> error.  Taking the "actionable" view that is done in Location
> Conveyance, which the Geopriv WG already blessed.
> 
> so, that's half of your stated 4 ideas that are covered by the
> Location-get draft, yet you didn't mention them. Plus 1 of the 4
> ideas that shouldn't be done in the first place.
> 
> Admittedly, I have to think about what you say about your last
> capability,  "the extension point", before considering incorporating
> it into the Location-get draft.
> 
> >In a certain way it is a guideline (a requirement draft) for
> >Location filter draft and having a clear view of what a *geopriv
> >seeker" could specify will help the progress of Loc-Filter
> >
> >
> >/Sal
> >
> >
> >James M. Polk wrote:
> >>At 03:32 PM 7/18/2008, Brian Rosen wrote:
> >>>I oppose the notion of another event package beyond presence to
return
> a
> >>>PIDF (containing, in this context, a PIDF-LO).
> >>
> >>I agree with this, given that this is what we agree to in IETF69
> (Chicago).
> >>
> >>draft-ietf-geopriv-loc-filters was Rohan's ID that was supposed to
> >>have died abruptly based on this same Chicago decision, because he
> >>proposed an alternate event package to Presence, called "Location".
> >>
> >>What draft-polk-sip-location-get does is specify how SIP is used to
both
> >>
> >>- solicit (the opposite of Conveyance) a location from another
entity,
> and
> >>- to dereference a Conveyed locationURI (which is part of
Conveyance)
> >>
> >>Both functions are done exactly the same way in
draft-polk-sip-location-
> get.
> >>
> >>This ID also proposes a set of filters be created to specify which
> >>pieces of location information an entity (presence watcher, or
> >>geopriv seeker) wants to learn about another entity's location.
> >>
> >>This to me, which is summarized by Brian below, is a combination of
> >>the functionality of what both Brian's ID (was Rohan's and was
> >>supposed to have died) and James's IDs, therefore I believe
> >>draft-polk-sip-location-get should be the one to move forward -
> >>since it answers the part of Rohan's ID that agrees with the
> >>Chicago decision (while omitting what the Chicago decision didn't
> >>want going forward), and the part of James's direction (the set of
> >>filters specifying some of the different pieces of location
information).
> >>
> >>At the same time, draft-polk-sip-location-get satisfies both how to
> >>subscribe to solicit and how to dereference a location URI. Neither
> >>of the others do both of these, that I have read.
> >>
> >>BTW -- draft-ietf-geopriv-loc-filters was never written to be a
> >>general purpose SIP dereference specification -- which is needed to
> >>complete the work started in Conveyance (that was there, until the
> >>Paris meeting actually, when it was split off).
> >>
> >>draft-ietf-geopriv-loc-filters is about triggered movement in and
> >>out of buildings.
> >>
> >>
> >>>I the only capability draft-winterbottom-sip-location-package-00
offers
> over
> >>>presence+loc-filters that I can see is the ability to specify the
> "what",
> >>>i.e. the form of location. If this is desirable, we can add it to
> >>>loc-filter.
> >>>
> >>>I must confess that I have had a very hard time understanding what
> >>>polk-sip-location-get does. It appears to define filters for the
> presence
> >>>package, somewhat like loc-filters, but there are some additions
that
> are
> >>>unclear to me (filter 1 filters on presentities, but unless the
> subscription
> >>>URI is a list, there is only one presentity, but it doesn't say
it's
> for
> >>>lists, and if it is for lists, why do we need a filter on the
list?).
> Many
> >>>of the other filters seem to duplicate what is in loc-filters.
There is
> no
> >>>justification offered for why an alternative to loc-filters is
needed.
> >>>
> >>>I think we should continue working on loc-filters, adding a filter
for
> >>>"what" and not consider the other proposals.
> >>>
> >>>Brian
> >>>
> >>> > -----Original Message-----
> >>> > From: geopriv-bounces at ietf.org
> >>> [mailto:geopriv-bounces at ietf.org] On Behalf
> >>> > Of Robert Sparks
> >>> > Sent: Friday, July 18, 2008 4:07 PM
> >>> > To: GEOPRIV
> >>> > Cc: SIP IETF; sipping LIST
> >>> > Subject: [Geopriv] Items of cross group interest
> >>> >
> >>> > This message is heavily crossposted. It is set to reply-to
geopriv.
> >>> > If you manually reply-to, please reply there.
> >>> >
> >>> > There are some questions about how to best provide location for
some
> >>> > applications. To date, the answer from GEOPRIV has been to use
> >>> > Presence as defined by SIMPLE and extended by GEOPRIV. (We've
spent
> >>> > time arguing that in GEOPRIV more than once).
> >>> >
> >>> > There are some new proposals, perhaps with new information, that
> push
> >>> > at that answer again, and in some cases, if they move forward,
its
> not
> >>> > clear what the best venue to vet them in is. But we have to
start
> >>> > somewhere, and the plan at the moment is to have a framing
> discussion
> >>> > in GEOPRIV.
> >>> >
> >>> > Please review the following drafts, comment on the GEOPRIV list
if
> you
> >>> > have an opinion, and plan to attend this section of the GEOPRIV
> >>> > meeting if you have an interest in how the conversation turns
out.
> >>> >
> >>> > ------
> >>> > Location events/filters
> >>> > draft-ietf-geopriv-loc-filters-02.txt
> >>> > draft-winterbottom-sip-location-package-00.txt
> >>> > draft-polk-sip-location-get-00.txt
> >>> > _______________________________________________
> >>> > Geopriv mailing list
> >>> > Geopriv at ietf.org
> >>> > https://www.ietf.org/mailman/listinfo/geopriv
> >>>
> >>>_______________________________________________
> >>>Geopriv mailing list
> >>>Geopriv at ietf.org
> >>>https://www.ietf.org/mailman/listinfo/geopriv
> >>
> >>_______________________________________________
> >>Geopriv mailing list
> >>Geopriv at ietf.org
> >>https://www.ietf.org/mailman/listinfo/geopriv
> >
> >_______________________________________________
> >Geopriv mailing list
> >Geopriv at ietf.org
> >https://www.ietf.org/mailman/listinfo/geopriv
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv