Subject: [Geopriv] Location Deference Event Pkg 02

From: Salvatore Loreto <[email-masked]>
Date: Fri, 26 Oct 2007 15:57:21 +0300

Hi there,

I haven't seen any discussion on this draft during the last months.
It seems that there is a lack of interest in the wg, however it is
becoming important for OMA.

I have read carefully the draft and I have some initial comments:

1) (Section 3.3) "For this package the subscriber SHOULD include an
'application/location-delta-filter+xml'"

My understand is that it is only a recommendation, but draft does not
restrict to use any other type of content (i.e for QoS parameters
preferences).

2) (Section 3.7): "If no location-filter is provided, the Notifier
SHOULD reject the subscription with a 403 Forbidden response"

I don't think that should be always true.
In fact it should be possible that if SUBSCRIBE with Expires 0 is sent
(one time request), then it should possible that no filter is provided. 
Notifier will send current location information as soon as possible. 

3) (Section 3.8) "Immediately after a subscription is accepted, the
Notifier MUST send a NOTIFY with the current location information as
appropriate based on the identity of the subscriber."

According to RFC 3265 it is possible to sent NOTIFY with pending status,
and then, when request is actually authorized and location information
obtained, then initial NOTIFY with location information is going to be
sent. This is not mentioned in the draft, but maybe it needs
clarification.

Best Regards
Sal

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 26 Oct 2007 09:16:52 -0400

What in the presence event package would not suit OMAs needs?  This is the
preferred approach of many WG members so far.  That is why you have not seen
much discussion.  

Brian

> -----Original Message-----
> From: Salvatore Loreto [mailto:[email-masked]]
> Sent: Friday, October 26, 2007 8:57 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Geopriv] Location Deference Event Pkg 02
> 
> Hi there,
>

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 26 Oct 2007 16:55:43 +0300

are you saying that the preferred approach among the wg members
is the usage of present event package with the filter criteria used to
differentiate the location event from the presence event?

without create a new specific event pkg for the location?

Sal

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 26 Oct 2007 10:13:39 -0400

Yes. I probably wouldn't describe the use the same way.  I expect that in
many cases the LIS that supplies location will provide a presence event
subscription service.  The only interesting parts of the PIDF will be the
location parts.  Filters that are specific to location will be needed in any
event (pardon the pun).

If you had a real presence service, and it had access to the location
information, then the presence server would also provide a subscription for
PIDF that included PIDF-LO.  You could have both situations, where the
presence server is aggregating the LIS information with other presence
information it had.

In the former case, the only events you would get would be location change
events.  In the latter case, you get a PIDF when location changed as well as
when other presence data changed.  Filters can help the client influence how
often events arrive in both cases.

Brian

> Sent: Friday, October 26, 2007 9:56 AM
> To: Brian Rosen
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Geopriv] Location Deference Event Pkg 02
> 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 26 Oct 2007 10:32:05 -0500

I don't think there is any formal "preferred" approach - there's a good
deal of noism evident in these comments.

A number of people do not consider it sensible to regard a LIS as a
presence server. Dereferencing a location URI is just the delayed
completion of the initial HELD request originated by the device. Thus
it's very sensible and reasonable to have defined way to complete the
location request in the same way that it started.

A device which hosts a presence service subscription can publish its
location information to a real presence server. Any valid watcher of
that presence service can, of course, subscribe using the standard range
of presence packages which include location and - by the way -
incorporate the presence controls that work against an actual subscriber
identity.

The question of defining an event/reporting package for LIS
functionality depends firstly on defining sensible event models for a
LIS - and dealing with the question of whether this is really the same
as a location event package for an actual presence subscriber identity
versus a transitory LIS reference. I don't consider these models to be
mature or complete at this stage. In the mean time, and regardless, the
ability to complete the HELD request cycle via the dereference is not
the same thing and is not to be dismissed on the basis of this other
model.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Saturday, 27 October 2007 12:14 AM
To: 'Salvatore Loreto'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Location Deference Event Pkg 02

Yes. I probably wouldn't describe the use the same way.  I expect that
in
many cases the LIS that supplies location will provide a presence event
subscription service.  The only interesting parts of the PIDF will be
the
location parts.  Filters that are specific to location will be needed in
any
event (pardon the pun).

If you had a real presence service, and it had access to the location
information, then the presence server would also provide a subscription
for
PIDF that included PIDF-LO.  You could have both situations, where the
presence server is aggregating the LIS information with other presence
information it had.

In the former case, the only events you would get would be location
change
events.  In the latter case, you get a PIDF when location changed as
well as
when other presence data changed.  Filters can help the client influence
how
often events arrive in both cases.

Brian

> > What in the presence event package would not suit OMAs needs?  This
is
> the
> > preferred approach of many WG members so far.  That is why you have
not
> seen

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 26 Oct 2007 11:50:36 -0400

Martin

Martin

This is a discussion of event notification, and specifically SIP event
notification.  Salvatore was asking about Rohan's location specific event
package.  There are some supporters of it, but I believe the consensus AT
THE MOMENT is to not have a location-specific event package.  The reason, I
believe that most of us don't think we need it is that it doesn't do
anything significantly different from the presence event package.  

A discussion of the relative merits of having a TCP based request-response
vs an event is entirely separate from which event package is used for
events.  Please don't take every comment on events for presence as an attack
on HELD.

Further, the general direction in Geopriv is that location is part of
presence.  So far, we've rebuffed attempts to separate them.  I think we all
recognize that a location server can supply a PIDF where the only thing of
interest in the PIDF is the location information.  I don't think that is a
problem, and I don't think we need to make any artificial barriers between
location and presence.  That means a LIS is a form of presence server,
always.  I don't think that causes any harm, and has some advantages.  

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Friday, October 26, 2007 11:32 AM
> To: Brian Rosen; Salvatore Loreto

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 26 Oct 2007 10:54:06 -0500

Yes - I mistook the thread for the HTTP using protocol submission also
just made. Carry on.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Saturday, 27 October 2007 1:51 AM
To: Dawson, Martin; 'Salvatore Loreto'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Location Deference Event Pkg 02

Martin

Martin

This is a discussion of event notification, and specifically SIP event
notification.  Salvatore was asking about Rohan's location specific
event
package.  There are some supporters of it, but I believe the consensus
AT
THE MOMENT is to not have a location-specific event package.  The
reason, I
believe that most of us don't think we need it is that it doesn't do
anything significantly different from the presence event package.  

A discussion of the relative merits of having a TCP based
request-response
vs an event is entirely separate from which event package is used for
events.  Please don't take every comment on events for presence as an
attack
on HELD.

Further, the general direction in Geopriv is that location is part of
presence.  So far, we've rebuffed attempts to separate them.  I think we
all
recognize that a location server can supply a PIDF where the only thing
of
interest in the PIDF is the location information.  I don't think that is
a
problem, and I don't think we need to make any artificial barriers
between
location and presence.  That means a LIS is a form of presence server,
always.  I don't think that causes any harm, and has some advantages.  

Brian

> > > > My understand is that it is only a recommendation, but draft
does
> > > > In fact it should be possible that if SUBSCRIBE with Expires 0
is
> sent
> > > > Notifier MUST send a NOTIFY with the current location
information
> as
------------------------------------------------------------------------
--
> ----------------------
------------------------------------------------------------------------
--
> ----------------------