Skip to main content

A Presence Event Package for the Session Initiation Protocol (SIP)
draft-ietf-simple-presence-10

Revision differences

Document history

Date Rev. By Action
2004-09-17
10 (System) This was part of a ballot set with: draft-ietf-simple-winfo-format, draft-ietf-simple-winfo-package
2004-09-17
10 (System) Ballot writeup text was added
2004-09-17
10 (System) Ballot approval text was added
2003-04-24
10 Natalia Syracuse State Changes to RFC Ed Queue from Approved-announcement sent by Syracuse, Natalia
2003-04-23
10 Jacqueline Hargest State Changes to Approved-announcement sent from Approved-announcement to be sent by Hargest, Jacqueline
2003-04-18
10 Jacqueline Hargest State Changes to Approved-announcement to be sent from IESG Evaluation  :: AD Followup by Hargest, Jacqueline
2003-04-18
10 (System) IESG has approved the document
2003-03-17
10 Patrik Fältström Verifying with AD's which have comments wether new version is ok or not.
2003-03-17
10 Patrik Fältström State Changes to IESG Evaluation  :: AD Followup from IESG Evaluation  :: Revised ID Needed by Faltstrom, Patrik
2003-02-05
10 Patrik Fältström
RFC-Editor note on request from Ned:

Replace the first paragraph in section 5, which currently reads:

A presentity is identified in the most general way …
RFC-Editor note on request from Ned:

Replace the first paragraph in section 5, which currently reads:

A presentity is identified in the most general way through a presence
URI [3], which is of the form pres:user@domain. These URIs are
protocol independent. They are resolved to protocol specific URIs,
such as a SIP or SIPS URI, through domain-specific mapping policies.

with:

A presentity is identified in the most general way through a presence
URI [3], which is of the form pres:user@domain. These URIs are
protocol independent. They are resolved to protocol specific URIs,
such as a SIP or SIPS URI, through domain-specific mapping policies maintained on the server.

(i.e., add the text "maintained on the server" to the end of the last sentence).
2003-02-04
10 Patrik Fältström
From: Jonathan Rosenberg
Date: tis feb 4, 2003  00:20:40 Europe/Stockholm
To: Patrik Fältström , ned.freed@mrochek.com
Cc: Jon Peterson , Robert Sparks , Jonathan Rosenberg
Subject: …
From: Jonathan Rosenberg
Date: tis feb 4, 2003  00:20:40 Europe/Stockholm
To: Patrik Fältström , ned.freed@mrochek.com
Cc: Jon Peterson , Robert Sparks , Jonathan Rosenberg
Subject: Re: updates to SIMPLE presence documents submitted

Ned,

Thanks for the comments on the SIMPLE documents. Enclosed are some responses to your comments.

Ned writes:
>[My concern can easily be addressed by an RFC Editor >note; no need to delay the
>document for it]
>The (brief) discussion of the pres: URL in >draft-ietf-simple-presence
>concerns me. It says:
>  A presentity is identified in the most general way >through a presence
>  URI [3], which is of the form pres:user@domain. >These URIs are
>  protocol independent. They are resolved to protocol >specific URIs,
>  such as a SIP or SIPS URI, through domain-specific >mapping policies.
>This doesn't make it clear that while the mapping >policies may vary from
>domain to domain, the way those policies are expressed >does not.

This doesn't quite match my understanding of draft-ietf-impp-srv, so let me try to make sure we are on the same page. My definition of a "mapping policy" is something that takes a pres URI like "pres:jdrosen@dynamicsoft.com" and maps it so "sip:jrosenberg@dynamicsoft.com". My understanding of draft-ietf-impp-srv is that these policies are not expressed in DNS at all. The DNS is used for a client that, for example, clicks on "pres:jdrosen@dynamicsoft.com" in a web page, to obtain the IP address and port of a server in dynamicsoft.com that it can send its presence request to (perhaps in a Jabber request). That presence request would still indicate "pres:jdrosen@dynamicsoft.com" as the target. That server would then apply its mapping policies, convert this to "sip:jdrosen@dynamicsoft.com", and then send that request using normal SIP procedures. Those mapping policies are never expressed anywhere beyond some local database on the server.

>I
>suggest changing this to read:
>  A presentity is identified in the most general way >through a presence
>  URI [3], which is of the form pres:user@domain. >These URIs are
>  protocol independent. They are resolved to protocol >specific URIs,
>  such as a SIP or SIPS URI, through the mapping >algorithm specified in
>  [5] and domain-specific mapping policies.

Assuming we are in agreement that draft-ietf-impp-srv works as I describe above (if I have misunderstood, then ignore the proposed text!), how about this:

A presentity is identified in the most general way through a presence
URI [3], which is of the form pres:user@domain. These URIs are
protocol independent. They are resolved to protocol specific URIs,
such as a SIP or SIPS URI, using the DNS procedures specified in [5], along with domain-specific mapping policies.



>One additional nit: These drafts have reference
>entries of the form:
>  [5] D. H. Crocker and J. Peterson, "Address
>resolution for instant
>  messaging and presence," internet draft, Internet >Engineering Task
>  Force, Dec. 2002.  Work in progress.
>I really don't like this:

Me neither. Its an artifact of the tool I've been using. About two months back I switched to xml2rfc, which doesnt have this problem (this was one of several reasons I switched). However, I didnt go through the pain of converting the source of all my older-than-2months drafts to xml2rfc.

If you like, I will construct the neccesary rfc-editor note to add the filename to the references.


Thanks,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                            First Floor
dynamicsoft                                East Hanover, NJ 07936
jdrosen@dynamicsoft.com                    FAX:  (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
2003-02-03
10 Patrik Fältström
Comment from Ned:

[My concern can easily be addressed by an RFC Editor note; no need to delay the
document for it]

The (brief) discussion …
Comment from Ned:

[My concern can easily be addressed by an RFC Editor note; no need to delay the
document for it]

The (brief) discussion of the pres: URL in draft-ietf-simple-presence
concerns me. It says:

  A presentity is identified in the most general way through a presence
  URI [3], which is of the form pres:user@domain. These URIs are
  protocol independent. They are resolved to protocol specific URIs,
  such as a SIP or SIPS URI, through domain-specific mapping policies.

This doesn't make it clear that while the mapping policies may vary from
domain to domain, the way those policies are expressed does not. I
suggest changing this to read:

  A presentity is identified in the most general way through a presence
  URI [3], which is of the form pres:user@domain. These URIs are
  protocol independent. They are resolved to protocol specific URIs,
  such as a SIP or SIPS URI, through the mapping algorithm specified in
  [5] and domain-specific mapping policies.

One additional nit: These drafts have reference entries of the form:

  [5] D. H. Crocker and J. Peterson, "Address resolution for instant
  messaging and presence," internet draft, Internet Engineering Task
  Force, Dec. 2002.  Work in progress.

I really don't like this: I want to see the name of the Internet Draft in there
somewhere. Perhaps some folks keep a mapppint of the draft titles to draft
id name in their heads, but I'm not one of them so this omission makes
chasing the references fairly painful.
2003-01-31
10 (System) New version available: draft-ietf-simple-presence-10.txt
2003-01-09
10 Harald Alvestrand

The simple-presence document says:

> 5 Usage of Presence URIs
>
>    A presentity is identified in the most general way through a presence …

The simple-presence document says:

> 5 Usage of Presence URIs
>
>    A presentity is identified in the most general way through a presence
>    URI [3], which is of the form pres:user@domain. These URIs are
>    protocol independent. They are resolved to protocol specific URIs,
>    such as a SIP or SIPS URI, through domain-specific mapping policies.
>
>    If a subscriber is only aware of the protocol-independent pres URI
>    for a presentity, it follows the procedures defined in [5]. These
>    procedures will result in the placement of the pres URI in the
>    Request-URI of the SIP request, followed by the usage of the DNS
>    procedures defined in [5] to determine the host to send the SIP
>    request to. Of course, a local outbound proxy may alternatively be
>    used, as specified in RFC 3261 [1]. If the subscriber is aware of
>    both the protocol-independent pres URI and the SIP or SIPS URI for
>    the same presentity, it SHOULD use the SIP or SIPS URI.
>
>    SUBSCRIBE messages also contain logical identifiers that define the
>    originator and recipient of the subscription (the To and From header
>    fields). These SHOULD contain SIP or SIPS URIs whenever possible, but
>    MAY contain a pres URI if a SIP or SIPS URI is not known or
>    available.

[5] is D. Crocker et al.  , "Address resolution for instant messaging
  and presence," Internet Draft, Internet Engineering Task Force, Oct.
  2002.  Work in progress.

I assume this is draft-ietf-impp-srv-01.txt (same title!).
That draft seems to envision DNS entries of the form
"_pres._sip.example.com" to look up which host to contact when one wants to use SIP to contact a presentity named "pres:xyzzy@example.com".
There's no mapping from one type of URI to another - in either direction.

This has two problems:

1) If a client uses SIP, he presumably has SIP URIs for himself. So he will use that SIP URI in the From field of a SUBSCRIBE, even though he also has his own PRES URI.
If the SUBSCRIBE has to be gatewayed to a non-SIP domain, per CPIM, how is the gateway to find the corresponding PRES URI?

2) If a client starts with the PRES URI, and later learns the SIP URI of someone, and those two identities part way for some reason (perhaps the client stops using SIP, or the SIP URI was to a proxy service, or something) - how does the client learn that it's time to go back to the PRES URI?

Both problems would be avoided if this document said to use PRES URI when both are available.

draft-ietf-impp-serv says:

>    CPIM and CPP both specify operations that have 'source' and
>    'destination' attributes.  While only the semantics, not the syntax,
>    of these attributes are defined by CPIM and CPP, many instant
>    messaging and presence protocols today support the use of URIs to
>    reflect the source and destination of their operations.  Such
>    protocols might be able to use the 'im' and 'pres' URI schemes
>    directly to express the identities of the principals associated with
>    a protocol exchange.  When these operations pass through a CPIM or
>    CPP gateway, these URIs could be relayed without modification, which
>    has a number of desirable properties for the purposes of
>    interoperability.

Seems to me like a good argument for preferring "pres:" here.
2002-12-27
10 Jacqueline Hargest State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Hargest, Jacqueline
2002-12-23
10 Jacqueline Hargest State Changes to Waiting for AD Go-Ahead from Waiting for Writeup by Hargest, Jacqueline
2002-12-06
09 (System) New version available: draft-ietf-simple-presence-09.txt
2002-12-04
08 (System) New version available: draft-ietf-simple-presence-08.txt
2002-10-07
10 Stephen Coya State Changes to Wait for Writeup  -- 0 from In Last Call by scoya
2002-09-20
10 Stephen Coya responsible has been changed to Patrik from IETF Secretary
2002-09-20
10 Stephen Coya State Changes to Last Call Issued from Last Call Requested by scoya
2002-09-19
10 Jacqueline Hargest Due date has been changed to 2002-10-3 from
by jhargest
2002-09-19
10 (System) Last call sent
2002-06-05
10 Stephen Coya Draft Added by scoya
2002-05-21
07 (System) New version available: draft-ietf-simple-presence-07.txt
2002-04-03
06 (System) New version available: draft-ietf-simple-presence-06.txt
2002-03-04
05 (System) New version available: draft-ietf-simple-presence-05.txt
2001-11-30
04 (System) New version available: draft-ietf-simple-presence-04.txt
2001-09-25
03 (System) New version available: draft-ietf-simple-presence-03.txt
2001-09-04
02 (System) New version available: draft-ietf-simple-presence-02.txt
2001-07-24
01 (System) New version available: draft-ietf-simple-presence-01.txt
2001-04-02
00 (System) New version available: draft-ietf-simple-presence-00.txt