Re: [Geopriv] Items of cross group interest

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

Absolutely not.

I am suggesting that the SIP location error headers should not be used
when the location information is not used as part of the routing
establish or is not critical to the establishment of a session. To do so
is a layering violation.

Cheers
James


> -----Original Message-----
> From: James M. Polk [mailto:jmpolk at cisco.com]
> Sent: Thursday, 24 July 2008 5:00 PM
> To: Winterbottom, James; Salvatore Loreto
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Items of cross group interest
> 
> At 07:21 PM 7/22/2008, Winterbottom, James wrote:
> >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!
> 
> James
> 
> Do I understand you now (from what you write here) that you have a
> competitive solution, in draft-winterbottom-sip-location-package, to
> the Location Conveyance ID -- necessitating a complete rewrite of
> Conveyance?
> 
> 
> >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
> 

------------------------------------------------------------------------------------------------
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