Subject: RE: [Simple] PIDF "entity" attribute usage

From: "Tim Rang" <[email-masked]>
Date: Thu, 13 Jan 2005 10:38:07 -0800

Paul,

You had me until here-

 So, at least in principle, when using SIMPLE, you can use either sip or

pres URIs. However this assumes the specific implementation you are 
using actually supports this. In practice you should determine what the 
implementation you are using supports.

 [Tim Rang] Can a SIMPLE implementation expect that all other SIMPLE
implementations support receiving the sip scheme in the entity
attribute?

Thanks,
Tim

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jan 2005 16:36:37 -0500

> implementations support receiving the sip scheme in the entity

Probably not. I *think* a SIMPLE implementation must at least support 
receiving an entity attribute containing the URI used to subscribe for 
that presence. (And I suspect many will require that - don't recall if 
the specs require it.)

So the bigger question is whether a SIMPLE implementation is able to 
*issue* a presence subscription to a { sip / pres } URI, and whether it 
is able to *accept* a presence subscription to a { sip / pres } URI.

The issue of accepting doesn't seem like a big deal. The presence 
implementation is responsible for defining what URIs its presentities 
have, so a user should know what uri is supported to access that presentity.

The ability to issue subscription requests to one kind or the other of 
uri is probably the big issue. If I tell you my presence URI is 
pres:[email-masked] but your presence client doesn't support pres 
URIs, then you are just out of luck.

I personally don't see any particular value in pres URIs. If I want a 
SIMPLE presence client, it is probably in support of a SIP UA that will 
be doing voice or IM. Both of those require the use of sip URIs. If I 
have all the support for sip, then why not use it for presence too? The 
pres URI is just a 5th wheel.

	Paul

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Jan 2005 14:40:10 -0800

At 4:36 PM -0500 1/13/05, Paul Kyzivat wrote:
>TThe ability to issue subscription requests to one kind or the other 
>of uri is probably the big issue. If I tell you my presence URI is 
>I personally don't see any particular value in pres URIs. If I want 
>a SIMPLE presence client, it is probably in support of a SIP UA that 
>will be doing voice or IM. Both of those require the use of sip 
>URIs. If I have all the support for sip, then why not use it for 
>presence too? The pres URI is just a 5th wheel.
>

RFC 3859 would argue that it is a useful mechanism for creating a presence
service abstracted from the specific presence/IM services (still
largely proprietary) in the wider world.  In a world where gateways
are still a common feature, I don't personally see it as a 5th wheel.
				regards,
					Ted Hardie

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Jan 2005 18:18:26 -0500

Ted Hardie wrote:
>> SIMPLE presence client, it is probably in support of a SIP UA that 
>> will be doing voice or IM. Both of those require the use of sip URIs. 
>> If I have all the support for sip, then why not use it for presence 
>> too? The pres URI is just a 5th wheel.
>>
> 

I agree if and when the necessary gateways are built.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Jan 2005 21:57:12 -0500

inline.

Paul Kyzivat wrote:

>> using actually supports this. In practice you should determine what 
>> the implementation you are using supports.
>>
>>

I don't follow this. Lets consider watchers for a moment. There two 
things for a watcher:

1. could it issue a SUBSCRIBE request to a pres: URI; appropriately 
doing the DNS operations needed to resolve it to a SIP URI

2. if it receives a presence document in a notification, could it handle 
an entity attribute that is a pres URI

For the presence agent, there are a bunch of cases:

1. Could the PA receive a SUBSCRIBE request where the r-uri is a pres 
URI, presumably equating it to presence data associated with a SIP URI?

2. Could the PA receive a presence document in a PUBLISH where one or 
both of the r-uri and entity tags in the published document are pres URI?

These are complicated questions. I think we should place the burden on 
the owner of the domain to really worry about correlation of these 
identifiers. That would argue for the following:

1. If a watcher genreates a SUBSCRIBE request with a pres URI in the 
r-uri, and the presence agent is responsible for generation of the 
presence document and can thus create one with either a pres or SIP URI 
in the entity attribute, it MUST create one using the pres URI.

2.  If a watcher genreates a SUBSCRIBE request with a sip URI in the 
r-uri, and the presence agent is responsible for generation of the 
presence document and can thus create one with either a pres or SIP URI 
in the entity attribute, it MUST create one using the sip URI.

3. If the PA cannot genreate the document or otherwise modify its entity 
attribute (for example if covered by an e2e signature), it MUST be 
capable of receiving subscriptions to either the pres or SIP URI in the 
request URI (thus be capable of equating the two URI) and thus return 
whatever it has.

Rules (1) and (2) also operate under the principle of least surprise; I 
should get documents where the entity attribute matches what I 
subscribed to. It also means that a watcher which has never even heard 
of a pres URI would never see a notification containing a document with 
a pres URI in the entity attribute, unless e2e signatures prevents it.

 From a publishing perspective, I think the PA should support any of the 
four combinations of pres/sip URI in the r-uri and entity attributes.

Where does this discussion belong? Since it largely deals with the 
construction of presence documents, I'd argue in the data model, but I'm 
open to suggestions.

Thoughts?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jan 2005 10:13:03 -0500

inline.

Jonathan Rosenberg wrote:
>> *issue* a presence subscription to a { sip / pres } URI, and whether 
>> it is able to *accept* a presence subscription to a { sip / pres } URI.
>>

I just reviewed RFC3861 to refresh my memory. As I understand it, the 
domain name from the pres uri is used to select the address where the 
subscription will be sent, but that the request URI will remain 
unchanged, in pres: form, when it arrives at the server.

> URI, presumably equating it to presence data associated with a SIP URI?

 From above, this should be possible if suitable DNS entries have been 
made that reference this PA.

> both of the r-uri and entity tags in the published document are pres URI?

By same logic, it could receive a publish with r-uri being pres:

In both of these cases, the operable question is not *could* it, but 
*should* it.

I think I recall from the discussions leading up to 3861 that we 
concluded that no *normative* algorithmic relationship exists between 
pres: and sip: URIs. (I.e. even if both pres:foo@bar and sip:foo@bar 
exist, there is no reason to believe these identify the same presentity.)

As a result, a watcher should not be using a pres: uri unless it knows 
this is valid. This could be because it was explicitly told to use it, 
or because it is aware of both a valid sip URI *and* a domain specific 
relationship between sip and pres URIs. (E.g. In the acme.com domain 
pres and sip URIs may be used interchangably to identify the same users.)

The PA needs the same information. It needs to know what URIs may be 
used to reference the state of a particular presentity. There should be 
no surprises here. If a PA receives a request addressed to pres:foo@bar,
and it has a def for sip:foo@bar but not pres:foo@bar, then it should be 
free to reject the request. Even if it does have a def for sip:foo.bar 
it shouldn't use it unless there is domain policy that says these should 
be equated.

> identifiers.

Beyond should. MUST.

> That would argue for the following:
> 

Seems reasonable, *if* the PA believes there is a correspondence.

> in the entity attribute, it MUST create one using the sip URI.

Again, seems reasonable, *if* the PA believes there is a correspondence.

> request URI (thus be capable of equating the two URI) and thus return 

*If* the PA believes there is a correspondence.

> four combinations of pres/sip URI in the r-uri and entity attributes.

*If* the PA believes there is a correspondence.

The discomforting part of this is that I think it means that I could 
subscribe to presence of pres:[email-masked] and receive a result 
where the entity attribute contains sip:[email-masked].

While, based on the logic here this doesn't seem entirely unexpected, is 
there anything special the watcher should do in this case? Assuming it 
was alice that was in the buddy list, what should be in the buddylist 
display? Do we care?

> construction of presence documents, I'd argue in the data model, but I'm 

Don't know.

	Paul

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 24 Jan 2005 14:28:00 +0100

On Jan 21, 2005, at 3:57 AM, Jonathan Rosenberg wrote:

>> receiving an entity attribute containing the URI used to subscribe 
>> for that presence. (And I suspect many will require that - don't 
>> recall if the specs require it.)
> 2. if it receives a presence document in a notification, could it 
> handle an entity attribute that is a pres URI
>

I totally agree, a domain offering presence service should decide if it 
wants to issue a pres URI as well as a sip URI to the same user. 
Further, it should also decide how to handle PUBLISH and SUBSCRIBE 
requests to one of the two. How should the PA handle 2 PUAs where one 
is PUBLISHing to the sip URI and the other is PUBLISHing to the pres 
URI of that user? This is a question that implementers need to answer.

> presence document and can thus create one with either a pres or SIP 
> URI in the entity attribute, it MUST create one using the pres URI.
>
> presence document and can thus create one with either a pres or SIP 
> URI in the entity attribute, it MUST create one using the sip URI.
>
> 3. If the PA cannot genreate the document or otherwise modify its 
> entity attribute (for example if covered by an e2e signature), it MUST 
> be capable of receiving subscriptions to either the pres or SIP URI in 
> the request URI (thus be capable of equating the two URI) and thus 
> return whatever it has.

These seem fair, but i think the text should be non-normative.

>
> Rules (1) and (2) also operate under the principle of least surprise; 
> I should get documents where the entity attribute matches what I 
> of a pres URI would never see a notification containing a document 
> with a pres URI in the entity attribute, unless e2e signatures 
> prevents it.
>
> From a publishing perspective, I think the PA should support any of 
> the four combinations of pres/sip URI in the r-uri and entity 
> attributes.
>
> construction of presence documents, I'd argue in the data model, but 
> I'm open to suggestions.

Well, the first part of this thread talks about how a PA handles 
SUBSCRIBE and PUBLISH requests to a pres uri and how a domain handles 
those requests. This should have been in RFC3856, but it's too late 
now. I guess data model document is good enough.

Regards,
Hisham

>
> Thoughts?
>
> -Jonathan R.
>
>
>
>
>> The ability to issue subscription requests to one kind or the other