Subject: [Geopriv] draft-garcia-geopriv-indirect-publish

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Oct 2009 01:40:07 -0500

Miguel

<I don't like sending message to 2 lists, but your ID crosses both 
the old SIP and your targeted Geopriv WGs>

I have concerns about your "Indirect Presence Publication with SIP" draft.
http://www.ietf.org/internet-drafts/draft-garcia-geopriv-indirect-publish-01.txt

Currently, and pretty much since whatever version of
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-01.txt 
has existed in whatever WG it happened to reside in at the time, 
Location Conveyance using SIP has included the use of PUBLISH to 
convey location as a message body, or as a location URI since about, 
or before 2005.  I fail to see or read what you want in your doc that 
cannot be covered in  SIP Location Conveyance.

I cannot figure out how you claim usage of the Geolocation is too limiting.

Additionally, I was forced to change the Location: header to the 
Geolocation: header due the SIP WG's conclusion it would be confused 
, therefore I do not believe you will be able to progress this 
forward for that additional reason as a Location header-value.

James

BTW -- you use a really old reference for the Location Conveyance 
ID.  It is on the -01 version in SIPCORE now, about to be -02.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 26 Oct 2009 09:43:43 -0400

I agree that we need a generalized way to indicate indirect presence
publish, and would not want to see a specialized mechanism for location.

I do think we could add a parameter to Geolocation which was instructions to
the presence server to fetch the location and include it in the presence
notifications, which would be much better than a new header just for that,
but a generalized indirect publish would be better IMO.

Brian

On 10/26/09 3:54 AM, "Miguel Garcia" <[email-masked]> wrote:

> James,
> 
> Actually, Martin Thomson has been pushing and submitting this draft. We
> (the authors) do not agree with all the content in there, for which we
> had little time to react. So, please, take this document as a mechanism
> to generate discussion more than as the reflected consensus among the
> authors.
> 
> Now, I will give you my personal thoughts below, which, as I said, might
> not match other authors'.
> 
> 
> On 26/10/2009 7:40, James M. Polk wrote:
>> Miguel
>> 
>> <I don't like sending message to 2 lists, but your ID crosses both the
>> old SIP and your targeted Geopriv WGs>
>> 
>> Location Conveyance using SIP has included the use of PUBLISH to convey
>> location as a message body, or as a location URI since about, or before
>> 2005. I fail to see or read what you want in your doc that cannot be
>> covered in SIP Location Conveyance.
> 
> I understand that the Geolocation header has quite a few similarities
> with what is proposed in the draft. I don't think the Geolocation header
> has means to indicate the presence server "you should de-reference the
> location and insert it in a presence document to be offered to watchers".
> 
>> 
> I have several criticism to the use of a SIP header to convey this
> information. Indirect location is just a particular case of a general
> solution, which is, a presentity wants to publish some information by
> reference not by value. Location is the more straight forward example,
> but we should try to find a general solution.
> 
> So, if we agree to pursue a general solution for publication of presence
> information by reference, then I find difficult to think of a solution
> based on a new or existing SIP header. Instead, we should be looking at
> the XML body, either to an extension to the existing one or a new XML
> body that.
> 
> If we don't agree with pursuing a general solution, then we should
> carefully look at the existing Geolocation header.
> 
>> 
>> Geolocation: header due the SIP WG's conclusion it would be confused ,
>> therefore I do not believe you will be able to progress this forward for
>> that additional reason as a Location header-value.
> 
> I agree with you, as I said, I don't even think the correct solution is
> to use a header at all. I think the chosen name "Location" is quite
> unfortunate due to historical reasons.
> 
> /Miguel
> 
>> 
>> James
>> 
>> BTW -- you use a really old reference for the Location Conveyance ID. It
>> is on the -01 version in SIPCORE now, about to be -02.
>> 
>>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Oct 2009 12:41:12 -0500

Miguel

I saw Martin's note to the WG just after I sent this note to the 
WG... bad timing, eh?  ;-)

comments in-line below

At 02:54 AM 10/26/2009, Miguel A. Garcia wrote:
>James,
>
>Actually, Martin Thomson has been pushing and submitting this draft. 
>We (the authors) do not agree with all the content in there, for 
>which we had little time to react. So, please, take this document as 
>a mechanism to generate discussion more than as the reflected 
>consensus among the authors.
>
>Now, I will give you my personal thoughts below, which, as I said, 
>might not match other authors'.
>
>
>I understand that the Geolocation header has quite a few 
>similarities with what is proposed in the draft. I don't think the 
>Geolocation header has means to indicate the presence server "you 
>should de-reference the location and insert it in a presence 
>document to be offered to watchers".

hmmm... it's this a policy choice between the presentity and the 
presence server (i.e., what to have the PS pass on as a reference, 
and what the PS dereferences to pass on only as a value)?  How can't 
that be a policy between the PA and PS (including which references to 
leave as references, and which are dereferenced and sent by the PS as 
a value)?

In that sense, this mechanism (policy notification of which URIs it 
receives from the PA need to be dereferenced) ought to be general, 
and not limited to location. I can see one argument being "the PA 
should include with the URI reference whether or not to do this 
deference", but that can lead to mistakes - as then each URI the PS 
receives has to look for the indication -- which is always an 
extension to how the URI is sent to the PS in the first 
place.  That's clumbersome IMO.

Therefore, IMO, this shouldn't be

- a new SIP header
- with or without a new option-tag
- an indication to each way a PS receives a URI

but, rather, more general.

The issue that has to be watched out for is when 2 or more URIs get 
sent to the PS and only a subset needs this dereference treatment.

>information. Indirect location is just a particular case of a 
>general solution, which is, a presentity wants to publish some 
>information by reference not by value. Location is the more straight 
>forward example, but we should try to find a general solution.

I'm not really understanding this example. If a PA wants to have a 
watcher get a URI, then the PA sends a URI to the PS.  If the PA 
wants to have the watcher get a value, the PA sends a value to the PS 
*or* the PA sends a URI to the PS and the PS dereferences the URI to 
be able to send a value to a watcher.

To me this is a function the PS knows to do when it receives certain 
URIs (i.e., reference types).  Receiving a Location URI could be one 
such situation.

I wonder if there is another issue -- shouldn't the PS determine when 
to send the reference vs. a value mostly based on who is asking for 
the information?

>So, if we agree to pursue a general solution for publication of 
>presence information by reference, then I find difficult to think of 
>a solution based on a new or existing SIP header. Instead, we should 
>be looking at the XML body, either to an extension to the existing 
>one or a new XML body that.

You're proposing have this indication solely in a message body?

This appears to me to be overkill just to get a flag from a PA to a PS.

I could be wrong though...

>>Geolocation: header due the SIP WG's conclusion it would be confused ,

I left how who would be confused -- the issue is RFC 2616 (HTTP) has 
a "Location" header already, and that's why I had to change Location 
Conveyance to a Geolocation header.  I didn't like it, but have 
gotten used to it.

>I agree with you, as I said, I don't even think the correct solution 
>is to use a header at all. I think the chosen name "Location" is 
>quite unfortunate due to historical reasons.

yes to the last part.

>--
>Miguel A. Garcia
>+34-91-339-3608
>Ericsson Spain

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Oct 2009 12:49:20 -0500

>but a generalized indirect publish would be better IMO.

yeah -- I can add a Geolocation header parameter that is only valid 
in PUBLISH to have the PS dereference the location URI and only send 
values to watchers.

That said -- I'm wondering if this is such a general purpose 
mechanism in which the PA will always know the watcher needs to get a 
location value?  I can imagine a policy in the PS determining whether 
the watcher gets a location URI or a value, perhaps based on who the 
watcher is.

Therefore, unless corrected, I'm more inclined to make this 
indication (from PA to PS) up to the local policy within the PS as to 
whether it wants to do this function, or pass on the location URI.

Is this agreeable?

That said - my other note on this questions whether this ought to go 
in every different way a reference is sent from a PA to PS (i.e., 
extending each way a reference is done).  Location Conveyance is 
really easy because this is still an ID, but other specs are more concrete.

James

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 26 Oct 2009 21:50:47 +0100

Please only make further enhancements to location conveyance after seeking endorsement of the sipcore list.

Primarily we need to concentrate on getting out what we have.

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: Monday, October 26, 2009 5:49 PM
> To: Brian Rosen; Miguel Garcia; Thomson, Martin
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Geopriv] [sipcore] draft-garcia-geopriv-indirect-publish
> 
> >I do think we could add a parameter to Geolocation which was 
> >instructions to the presence server to fetch the location 
> and include 
> >it in the presence notifications, which would be much better 
> than a new 
> >header just for that, but a generalized indirect publish 
> would be better IMO.
> 
> yeah -- I can add a Geolocation header parameter that is only 
> valid in PUBLISH to have the PS dereference the location URI 
> and only send values to watchers.
> 
> mechanism in which the PA will always know the watcher needs 
> to get a location value?  I can imagine a policy in the PS 
> determining whether the watcher gets a location URI or a 
> value, perhaps based on who the watcher is.
> 
> indication (from PA to PS) up to the local policy within the 
> PS as to whether it wants to do this function, or pass on the 
> location URI.
> 
> Is this agreeable?
> 
> That said - my other note on this questions whether this 
> ought to go in every different way a reference is sent from a 
> PA to PS (i.e., extending each way a reference is done).  
> Location Conveyance is really easy because this is still an 
> ID, but other specs are more concrete.
> 
> James
> 
> 
> >Brian
> >
> >
> http://www.ietf.org/internet-drafts/draft-garcia-geopriv-indir
> ect-publish-01.
> > >> txt
> > >>
> > >>
> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-convey
> > ance-01
> > >> .txt
> > >> convey location as a message body, or as a location URI since 
> > >> about, or before 2005. I fail to see or read what you 
> want in your 
> > >> doc that cannot be covered in SIP Location Conveyance.
> > >
> > > should de-reference the location and insert it in a 
> presence document to be offered to watchers".
> > >
> > >>
> > >> Geolocation: header due the SIP WG's conclusion it would be 
> > >> confused , therefore I do not believe you will be able 
> to progress 
> > >> this forward for that additional reason as a Location 
> header-value.
> > >
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 26 Oct 2009 20:35:32 -0500

>seeking endorsement of the sipcore list.

fair -- I was just imagining how it could be done, not that I was 
going to do this.

I'm more concerned about a newly proposed SIP header that recreates 
at least part of what the SIP Geolocation header can do.

>Primarily we need to concentrate on getting out what we have.

I agree.

James

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 27 Oct 2009 10:06:06 +0100

Hi James,

some inline comments.

On 26/10/2009 18:41, James M. Polk wrote:

>> with what is proposed in the draft. I don't think the Geolocation
>> header has means to indicate the presence server "you should
>> de-reference the location and insert it in a presence document to be
>> offered to watchers".
>
> presence server (i.e., what to have the PS pass on as a reference, and
> what the PS dereferences to pass on only as a value)? How can't that be
> a policy between the PA and PS (including which references to leave as
> references, and which are dereferenced and sent by the PS as a value)?

At the moment the draft is not ambitious to have the PS passing the 
reference to the watcher. This might be something to look at it a bit 
later, but so far, the only ambition is that the PS de-references the 
location and adds it to the PIDF that is offered to watchers.

> receives from the PA need to be dereferenced) ought to be general, and
> not limited to location. I can see one argument being "the PA should
> include with the URI reference whether or not to do this deference", but
> that can lead to mistakes - as then each URI the PS receives has to look
> for the indication -- which is always an extension to how the URI is
> sent to the PS in the first place. That's clumbersome IMO.
>
> The issue that has to be watched out for is when 2 or more URIs get sent
> to the PS and only a subset needs this dereference treatment.

I think I concur with you, except the level of ambition, as I said before.

> watcher get a URI, then the PA sends a URI to the PS. If the PA wants to
> have the watcher get a value, the PA sends a value to the PS *or* the PA
> sends a URI to the PS and the PS dereferences the URI to be able to send
> a value to a watcher.
>
> URIs (i.e., reference types). Receiving a Location URI could be one such
> situation.

I agree with your analysis.

>
> I wonder if there is another issue -- shouldn't the PS determine when to
> send the reference vs. a value mostly based on who is asking for the
> information?

This is discussed before, we are building from the ground, and the first 
step is to make the PS to dereference the location URI. Passing the URI 
is something for which don't have requirements at the moment, so will 
analyze whether is worth doing it once we have solved our main problem.

>> presence information by reference, then I find difficult to think of a
>> solution based on a new or existing SIP header. Instead, we should be
>> looking at the XML body, either to an extension to the existing one or
>> a new XML body that.
>

Well, at the moment all solution spaces are open. If we want to make 
something general enough, it cannot be done at the SIP level, so we 
should be looking at ways to do it at the XML level. Using and XML diff 
document (XML Patch operations) might be a way to move forward. We are 
currently investigating this track.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 27 Oct 2009 13:19:23 -0500

Miguel

comments in-line

At 04:06 AM 10/27/2009, Miguel A. Garcia wrote:
>reference to the watcher. This might be something to look at it a 
>bit later, but so far, the only ambition is that the PS 
>de-references the location and adds it to the PIDF that is offered to watchers.

watchers SUBSCRIBE to a PS to get presentity state information, right?

If true, then the NOTIFY can carry the Geolocation header-value with 
a location URI as the answer to the watcher for (geographically) 
where the presentity is - provided it has been authorized to receive 
such information.  This isn't hard.

This to, can be added to SIP Location Conveyance (if the SIPCORE WG 
agrees with this addition).

>This is discussed before, we are building from the ground, and the 
>first step is to make the PS to dereference the location URI. 
>Passing the URI is something for which don't have requirements at 
>the moment, so will analyze whether is worth doing it once we have 
>solved our main problem.

it seems - since you do not have requirements to send the watcher a 
location URI for a presentity's location that the PS dereferencing 
will always happen. If true, then this appears to me to be a fixed 
policy - for the time being (i.e., until something else tells the PS 
to do something different) - to *always* dereference any location URI 
it receives from a presentity in a PUBLISH.  To me, the PS doesn't 
need to be told to do anything, since only one action can occur 
(i.e., to dereference).

If you agree with the above, why do you need a flag telling the PS to 
do anything other than a default action (i.e., to dereference the 
location URI) and send the location value to authorized watchers?

It feels like you are forcing this to be an explicit instruction 
instead of a default implicit action to always be done until told to 
do something else (like send a location URI - which could require a 
flag at some future date).

Why not have the following rule cover what you want

         the recommended policy be to dereference any location URI
         received in a Geolocation header-value (in a PUBLISH) from
         a presentity, to give to authorized watchers.

This seems to cover what you want.

And when you reach consensus on the requirement to send a watcher the 
location URI instead of a location value, that will need to be 
indicated with further work.

>should be looking at ways to do it at the XML level. Using and XML 
>diff document (XML Patch operations) might be a way to move forward. 
>We are currently investigating this track.

As stated above, I believe you are wanting a default action for the 
PS to dereference location URIs to provide location values to 
watchers, without a choice in the matter (of giving out a location 
URI to a watcher instead).  This seems like a policy choice that can 
be stated as a recommendation or a should (both 2119 strength) in an 
existing document, until you determine the time has come for the 
requirement to send a watcher the location URI instead of a value.

James

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 26 Oct 2009 08:54:43 +0100

James,

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 29 Oct 2009 13:20:32 +0800

Hi James,

> agrees with this addition).

Aside from a very strong desire to see the end of SIP location conveyance, all the authors on this document are in strong agreement that a location-specific solution is not desirable.

> indicated with further work.

This is sensible.  I tend to agree that we want to have the presence agent able to do the dereference.  In many cases, the watcher wont be interested in doing this themselves.  This is just one aspect we need to consider in the solution.

For instance, if we extend PIDF, a presence agent that doesn't support the extension would pass the reference onward unaware of its special status.  That might be a desirable attribute of a solution.  Alternatively, we could provide a different body.

Miguel and I are currently debating options.  We're still trying to come to a common understanding on this point.  About all we agree on right now is that this reference will sit in the body of the SIP PUBLISH and that it will not be location-specific.  These are both reasons against using Geolocation, which is unfortunate in a way because it has a lot of the semantics we're looking for.

Once we've sorted out the basics, maybe we can see how the Geolocation header fits.
 
> PS to dereference 

Actually, as Miguel says, the options are still largely open.  But I certainly think that having the presence agent able to dereference is a desirable feature.  This might be: always dereference, dereference based on presence agent policy, dereference at the request of the presentity, or a combination of these.

--Martin

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 29 Oct 2009 09:36:35 +0100

>          a presentity, to give to authorized watchers.

I think this the text around the policy is quite reasonable and according 
to our expectations.

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Oct 2009 09:32:54 -0400

I agree that this is something where a general solution would be preferable.

There are a number of parties involved in this:
- the publisher
- the presence server
- the watcher
- the true source of the information

(Some of the above may be collocated.)

If there is a deref to be done, it can potentially be done in any of 
those places, except the source. The *policy* about where it should be 
done might also be set in any of those places. And there are competing 
interests about that. For instance:

- the source wants to minimize derefs. Depending on the particular
   data and the typical access patterns for that data, choosing a
   particular one of the other parties to do the deref may minimize
   the number of derefs. (But probably the source has too little info
   about the usage to make the choice even if it could.)

- the publisher, if it isn't collocated with the source, may want
   to delegate the deref to save itself work.

- the presence server may also want to delegate the deref to either
   the publisher or the watcher to save itself work. But in other
   cases its role in life is to offload the publisher and the watcher,
   so it might be willing to take on the work.

- the watcher also may want to delegate this work to one of the
   other parties to offload itself. But in other cases it may *want*
   the opportunity to do the deref itself so that it can get more
   timely values than it would otherwise.

So, I think  general solution is going to require some sort of 
negotiation between all the parties about who assumes this 
responsibility. Seems like an interesting and non-trivial problem.

	Thanks,
	Paul

Thomson, Martin wrote:
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 29 Oct 2009 13:23:29 -0500

Martin

comments in-line

At 12:20 AM 10/29/2009, Thomson, Martin wrote:
>Aside from a very strong desire to see the end of SIP location 
>conveyance, all the authors on this document are in strong agreement 
>that a location-specific solution is not desirable.

ok... I think I mention that this ought to be a more generic solution 
-- but then have to ask, if the authors believe this is to be a more 
generic solution, why would you create a "Location"" header in SIP 
(especially when Henning knows full well that we (SIP folks) can't 
name anything "Location:" because of the conflict with the HTTP 
header Location)?  This seems pretty Location specific to me, unless 
I'm misreading the text in the ID for another purpose of Location: 
(I'm thinking I didn't because this is all about dereferencing a 
location URI when sent to a PS by a presentity).

>This is sensible.  I tend to agree that we want to have the presence 
>agent able to do the dereference.

"presence agent" here means presentity or PS?

If presentity, then the dereference occurs before the SIP PUBLISH is 
sent to the PS (meaning there is no indirect location publish).

If PS, then I don't see or know about anything preventing this from 
happening in the first place.

Miguel stated to me that there is no requirement to date for a PS to 
send a location URI presentity to a watcher. This means that there 
need only be a policy in all presence servers to dereference all 
location URIs when received in a PUBLISH, to give to watchers that 
are authorized to receive a presentity's location.

>  In many cases, the watcher wont be interested in doing this 
> themselves.  This is just one aspect we need to consider in the solution.

I'm wondering why this is considered at all, since there is no 
requirement to be able to send a watcher a location URI.  The 
solution is above.

>For instance, if we extend PIDF, a presence agent that doesn't 
>support the extension would pass the reference onward unaware of its 
>special status.

I'm not sure I understand how extending a PIDF is an answer, but I 
don't fully understand Miguel's desire for a new message body for 
this - in the first place. I see problems where this can be 
misunderstood and perhaps incorrectly used in other SIP methods to 
send a location URI, which could easily require support for multipart 
message bodies that not every UAS will support (because most don't today).

>That might be a desirable attribute of a solution.  Alternatively, 
>we could provide a different body.
>
>Miguel and I are currently debating options.  We're still trying to 
>come to a common understanding on this point.  About all we agree on 
>right now is that this reference will sit in the body of the SIP 
>PUBLISH and that it will not be location-specific.

ok, so there is not going to be a new SIP Location: header. That's very good.

I'm wondering why this has to be in a separate message body though.

One option I haven't heard (admitting I'm not part of the author team 
have these discussions) is why a general policy can't exist 
specifically to presence servers to dereference any location URI 
found in the Geolocation header of a SIP PUBLISH request to give to 
authorized watchers.  This is clearly the most straightforward 
solution - knowing there is no requirement for a presence server to 
send a location URI to the watcher. Once that new requirement is 
reached, I agree something new needs to be in the PUBLISH.

But this is for location only, and if you want a more generic 
solution for situations where URIs are sent to presence servers that 
are location URIs, then perhaps something else needs to be done.

>These are both reasons against using Geolocation, which is 
>unfortunate in a way because it has a lot of the semantics we're looking for.

For location (specific) URIs, I'm not seeing how a policy at the 
presence server doesn't satisfy the current use of the Geolocation header.

>Once we've sorted out the basics, maybe we can see how the 

ok

>Actually, as Miguel says, the options are still largely open.  But I 
>certainly think that having the presence agent able to dereference 
>is a desirable feature.  This might be: always dereference, 
>dereference based on presence agent policy, dereference at the 
>request of the presentity, or a combination of these.

sounds about right

James

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 29 Oct 2009 13:24:26 -0500

At 03:36 AM 10/29/2009, Miguel A. Garcia wrote:
>I think this the text around the policy is quite reasonable and 
>according to our expectations.

cool

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 30 Oct 2009 05:59:03 +0800

> why would you create a "Location"" header in SIP [...] ? 

So that we would have this debate.  It seems to have worked ;)

There were reasons for choosing "Location" that seemed valid.  I had no idea that it would cause so much confusion though.  It was never intended to be location specific (in a geopriv sense); the draft goes to great lengths to make this distinction.  But then, everyone just skims drafts, so I can see how easily we get confusion like this.

Since I updated the doc, I've been convinced that a message body is more appropriate than a header.

> "presence agent" here means presentity or PS?

Presence agent is the term used by RFC 3903 and other presence documents.  It's the presence server (PS) in your terms.

> sent to the PS (meaning there is no indirect location publish).

Meaning we don't need a mechanism.  I'm not really interested so much in that use case.

> happening in the first place.

Nothing preventing it, but as Paul notes, we need to be clear on what model we want.

> are authorized to receive a presentity's location.

We're not talking about location URIs, remember.

c.f. my upcoming response to Paul.

> requirement to be able to send a watcher a location URI.  The

We haven't determined if there is a requirement or not.  I tend to think that there is no reason to prevent this, and there are cases where it might make sense to allow for it.
 
> I'm wondering why this has to be in a separate message body though.

It's currently a choice.  One that I'm tending away from right now, but it's still a valid choice.

> reached, I agree something new needs to be in the PUBLISH.

Actually, if you read the draft, I discuss this briefly.  We can request that a server dereferences, but we can't force them.  After all, servers that don't support this feature will exist.

> are location URIs, then perhaps something else needs to be done.

Precisely.

--Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 30 Oct 2009 06:31:59 +0800

Hi Paul,

That's an excellent summary of the stakeholders.

                 Source
                    |  \
                   ?|    \ ?
                    |      \
  Publisher/ --- Server --- Watcher
  Presentity      (PA)

Assuming that the publisher wants to do the dereference (and they are able to [1]), we have nothing further to do.  We don't need to build a mechanism.  The publisher can implement this policy as they see fit.

So, the presentity publishes a reference to the presence server.

The pertinent questions are:

 (A) does the presentity have any say in where the reference is resolved?

 (B) does the watcher have any say in where the reference is resolved?

Any preference for (A) is expressed in a PUBLISH and that any preference for (B) is expressed in a SUBSCRIBE (most probably).  Obviously, the server has the final say: it can choose to pass the reference on - forcing the watcher to dereference - or it can do the dereference itself.

So, why would the publisher ask the server to dereference?  Maybe it knows something of the watchers, or maybe it wants to protect the reference (c.f. location URIs and the possession model).  That second reason is a good reason to have a means to fail the publish if the server is unwilling or unable.  The Require header I proposed does this, but there might be other ways to achieve the same effect.

So why would the watcher ask the server to dereference?  The simplest reason is: it doesn't want to do the work itself.

Why would the server not want to dereference?  The idea that it doesn't want the extra work doesn't really fit with it being a presence server.  After all, a large part of its reason for being is to offload work from watcher and publisher.

So, all this more or less leads me to think that having the server dereference is the most sensible option.  Obviously, server policy can override this or the server might be unable to dereference.

I do think that it might make sense to have an option where the server failing to dereference doesn't prevent the watcher from attempting to do so.  If the server doesn't support the feature, the server decides not dereference, or the server encounters an error while trying, ... then the reference is passed on the watcher.  

That leads me to conclude that there is no benefit in having the watcher request that a reference is resolved.  If the watcher receives a reference, it knows that there's nothing it could have done to have this dereferenced for it.

Cheers,
--Martin

[1] This isn't always the case: <http://tools.ietf.org/html/draft-ietf-ecrit-rough-loc>, though for many presence use cases I doubt it will be a factor.

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, 30 October 2009 12:33 AM
> To: Thomson, Martin
> Cc: James M. Polk; Miguel A. Garcia; [email-masked]; [email-masked]
> Subject: Re: [sipcore] draft-garcia-geopriv-indirect-publish
> 
> agent able to do the dereference.  In many cases, the watcher wont be
> interested in doing this themselves.  This is just one aspect we need
> to consider in the solution.
> >
> special status.  That might be a desirable attribute of a solution.
> Alternatively, we could provide a different body.
> >
> PUBLISH and that it will not be location-specific.  These are both
> reasons against using Geolocation, which is unfortunate in a way
> because it has a lot of the semantics we're looking for.
> >
> certainly think that having the presence agent able to dereference is a
> desirable feature.  This might be: always dereference, dereference
> based on presence agent policy, dereference at the request of the
> presentity, or a combination of these.
> >
> > --Martin
> >
> >> James
> >>
> >>
> >>
> >>
> >>> /Miguel
> >>>
> >>> --
> >>> Miguel A. Garcia
> >>> +34-91-339-3608
> >>> Ericsson Spain
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Oct 2009 20:03:17 -0400

Martin,

I pretty much agree.
There may be other considerations if the deref'ed answer varies with 
time. If the server always derefs, then for the watcher to get a new 
value it must query the server again. If the watcher gets a reference 
frmo the server, then it can query the source.

Is that a useful distinction? Probably not, and least not often.
The work of doing so will probably not be that different for the 
watcher, except it may get back more data than it wants.

In the interest of simplicity, I think the distinction can be ignored.

	Thanks,
	Paul

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 30 Oct 2009 08:25:32 +0800

This is something that will need to be dealt with somehow.  After all, if we're talking location, then it does change.

That's actually a motivation for doing this: the presentity/publisher doesn't want to deal with changing values and having to continually publish.  For one, it might be pointless because none of their watchers are even interested in the updates.

The "dereference" operation could be something quite sophisticated, like a presence subscription.  That's all up to the presence server.  It has a number of options:

 - Dereference on publish, which equivalent in many respects to having the presentity do the dereference, so this adds little value

 - Dereference on update, where the information is retrieved each time a watcher subscribes

 - Dereference based on information in the retrieved presence data, such as expiry times or timestamps

 - Dereference periodically, where the time is based on local policy or based on the intervals provided by watchers

 - Dereference more intelligently by considering event-rate controls from watchers, the filters that they provide and consolidate all these into the one subscription (assuming that this is possible, say the reference is a pres: URI) or either attempt to poll in an optimum way to meet these targets

Obviously, there are quite a number of ways this could be done.  Obviously, the options that are more efficient and provide a better view of the presence state to watchers are more difficult to implement.

I'm happy to let the presence server decide on what to do, but we should probably have some sort of discussion in the draft that describes the choices that are available and some of the implications of each.  That should be sufficient.  

Giving the presentity/publisher or watcher a means to control this doesn't seem helpful - for the watcher, they can use subscription event rate control and filters to influence the server, but it's up to the presence server implementation and policy how those are acted upon.

--Martin

> Sent: Friday, 30 October 2009 11:03 AM
> To: Thomson, Martin
> > Assuming that the publisher wants to do the dereference (and they are
> able to [1]), we have nothing further to do.  We don't need to build a
> mechanism.  The publisher can implement this policy as they see fit.
> >
> > Any preference for (A) is expressed in a PUBLISH and that any
> preference for (B) is expressed in a SUBSCRIBE (most probably).
> Obviously, the server has the final say: it can choose to pass the
> reference on - forcing the watcher to dereference - or it can do the
> dereference itself.
> >
> > So, why would the publisher ask the server to dereference?  Maybe it
> knows something of the watchers, or maybe it wants to protect the
> reference (c.f. location URIs and the possession model).  That second
> reason is a good reason to have a means to fail the publish if the
> server is unwilling or unable.  The Require header I proposed does
> this, but there might be other ways to achieve the same effect.
> >
> > So why would the watcher ask the server to dereference?  The simplest
> reason is: it doesn't want to do the work itself.
> >
> > Why would the server not want to dereference?  The idea that it
> doesn't want the extra work doesn't really fit with it being a presence
> server.  After all, a large part of its reason for being is to offload
> work from watcher and publisher.
> >
> > So, all this more or less leads me to think that having the server
> dereference is the most sensible option.  Obviously, server policy can
> override this or the server might be unable to dereference.
> >
> > I do think that it might make sense to have an option where the
> server failing to dereference doesn't prevent the watcher from
> attempting to do so.  If the server doesn't support the feature, the
> server decides not dereference, or the server encounters an error while
> trying, ... then the reference is passed on the watcher.
> >
> > That leads me to conclude that there is no benefit in having the
> watcher request that a reference is resolved.  If the watcher receives
> a reference, it knows that there's nothing it could have done to have
> this dereferenced for it.
> >
> > Cheers,
> > --Martin
> >
> > [1] This isn't always the case: <http://tools.ietf.org/html/draft-
> ietf-ecrit-rough-loc>, though for many presence use cases I doubt it
> will be a factor.
> >
> is a