Subject: [Simple] Preference for Individual URI

From: "Ngo, Dai (c)" <[email-masked]>
Date: Fri, 10 Aug 2001 19:35:40 +0000

All,

In section "5.1 Contact, Accept-Contact and Reject-Contact Parameters" of
the draft-ietf-sip-callerprefs-04.txt it states that the Methods parameter,
Description parameter, and priority parameter for a contact header are NOT
used in the matching operation described in Section 6.4.1 of the same draft.
In addition, the contact URI comparison is based on SIP URI matching rules.
This implies that in the following example described in the
draft-ietf-simple-presence-01.txt, the second contact:
<sip:[email-masked]>;methods="SUBSCRIBE" will completely *REPLACE* the
first contact: <sip:[email-masked]>;methods=MESSAGE;description="open"
due to the fact that the contact URI <sip:[email-masked]> is the same
for both:

	REGISTER sip:example.com SIP/2.0
       Via: SIP/2.0/UDP pua.example.com:5060
       To: <sip:[email-masked]>
       From: <sip:[email-masked]>
       Call-ID: [email-masked]
       CSeq: 1 REGISTER
       Contact: <sip:[email-masked]>;methods="MESSAGE"
                 ;description="open"
       Contact: <sip:[email-masked]>;methods="SUBSCRIBE"
       Expires: 600

So if I'm login into a computer and have one SIP URI
<sip:[email-masked]>, the only choice I have is to send a REGISTER with:
	contact: <sip:[email-masked]>;methods="MESSAGE,
SUBSCRIBE";description="open".

Now, later, I want to continue receiving SUBSCRIBEs (description="open") but
not to receive MESSAGEs (description="close"). What options do I have
besides having to have two different sip contact URIs?

Thanks for helping.

-- Dai

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2001 23:48:24 -0400

-----Original Message-----
From: Ngo, Dai (c) [mailto:[email-masked]]
Sent: Friday, August 10, 2001 3:36 PM
To: [email-masked]
Subject: [Simple] Preference for Individual URI

>In section "5.1 Contact, Accept-Contact and Reject-Contact Parameters" of
the 
>draft-ietf-sip-callerprefs-04.txt it states that the Methods parameter, 

>This implies that in the following example described in the
draft-ietf-simple-
>presence-01.txt, the second contact: 
due 
>to the fact that the contact URI <sip:[email-masked]> is the same for 
>both:

>       Contact: <sip:[email-masked]>;methods="SUBSCRIBE" 

Excellent observation. You are correct.

>So if I'm login into a computer and have one SIP URI
<sip:[email-masked]>, 
>the only choice I have is to send a REGISTER with:

Yes.

>not to receive MESSAGEs (description="close"). What options do I have
besides 
>having to have two different sip contact URIs?

Well, this depends on whether you interpret the description param as
indicating open/closed. I don't think thats the right mapping, since
description is a textual phrase. I think that maps to the <note> element in
draft-ietf-impp-cpim-pidf-00.txt. 

So, if you want to cease receiving IM, you would REGISTER the following:

i.e., MESSAGE is no longer listed as an allowed method.

Now, there is an important process question here to be answered. What do we,
or do we not, say about mapping registered information to presence
documents? Is this purely implementation choice? Is this part of the core
presence specification?

I think that we should not say anything about it. Presence documents can be
constructed from a large variety of sources, only one of which is
registrations. How the document is constructed is really a local
implementation choice. Now, interop issues do arise when a client wants to
achieve a particular effect in the presence document. For example, Dai is
concerned above about how a client can achieve the result of indicating a
particular communications means is closed.

I think that if a client wants direct controls over presence documents, it
should directly control them. That is, it should upload a presence document
directly, rather than guessing at server interpretation of the registered
contacts and its impact on the presence document. 

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com