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 |