Re: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard
Harald Tveit Alvestrand <harald@alvestrand.no> Fri, 17 January 2003 07:49 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15040 for <simple-archive@odin.ietf.org>; Fri, 17 Jan 2003 02:49:45 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0H85E207866 for simple-archive@odin.ietf.org; Fri, 17 Jan 2003 03:05:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H85DJ07863 for <simple-web-archive@optimus.ietf.org>; Fri, 17 Jan 2003 03:05:13 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15036 for <simple-web-archive@ietf.org>; Fri, 17 Jan 2003 02:49:13 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H859J07851; Fri, 17 Jan 2003 03:05:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0H84MJ07817 for <simple@optimus.ietf.org>; Fri, 17 Jan 2003 03:04:22 -0500
Received: from eikenes.alvestrand.no (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15028 for <simple@ietf.org>; Fri, 17 Jan 2003 02:48:21 -0500 (EST)
Received: from [192.168.1.4] (askvoll.hjemme.alvestrand.no [192.168.1.4]) by eikenes.alvestrand.no (Postfix) with ESMTP id 186BA625F6; Fri, 17 Jan 2003 08:51:43 +0100 (CET)
From: Harald Tveit Alvestrand <harald@alvestrand.no>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, Patrik Fältström <paf@cisco.com>
Cc: simple@ietf.org, Allison Mankin <mankin@psg.com>
Subject: Re: [Simple] Fwd: Evaluation: draft-ietf-simple-winfo-package - A Session Initiation Protocol (SIP)Event Template-Package for Watcher Information to Proposed Standard
Message-ID: <566820000.1042789903@askvoll.hjemme.alvestrand.no>
In-Reply-To: <3E274D76.3080604@dynamicsoft.com>
References: <8AA01134-23F4-11D7-871D-0003934B2128@cisco.com> <3E274D76.3080604@dynamicsoft.com>
X-Mailer: Mulberry/2.2.1 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: simple-admin@ietf.org
Errors-To: simple-admin@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/simple/>
Date: Fri, 17 Jan 2003 08:51:43 +0100
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
--On torsdag, januar 16, 2003 19:25:26 -0500 Jonathan Rosenberg <jdrosen@dynamicsoft.com> wrote: >>> 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? > > This is a good question. > > Unfortunately, this is a case which is unavoidable. We are going to run > into cases where a SIMPLE client has no pres URI at all, and so the From > field has a SIP URI. This case worries me not at all; if there is no pres: URL, we can't use it, and just have to live with that. > Worse yet, there is a great deal of SIMPLE deployed > today, and most of it (unsurprisingly) using the URI format native to > SIMPLE, the SIP URI. > > So, what would happen at the gateway? I would imagine that, like happens > in email systems today I believe, that when receiving a SUBSCRIBE request > with From field sip:jdrosen@dynamicsoft.com, the gateway at > gw.example.com would create a pres URI like this: > > pres:sip%3Ajdrosen%40dynamicsoft.com@gw.example.com this is not exactly new - those of us who've been using email since the 80s will remember hosts of addresses like user%machine.bitnet@gateway.net and the even more horrifying decwrl!some!where!else!user@gateway. exactly the same problems abound - including "route pinning", gateway traversal authentication and so on (the gatway machine can easily be used as an open relay, with all the problems that causes for spam injection, for instance). If there is value to the pres: format, just as there was value to the user@dns.listed.name format, the pres: URL will eventually become ubiquitous. > Should someone reply to this, it would route to the gateway, which would > extract the user part, un-escape it, and send it using the sip URI > within. Indeed, gateways might do such conversions directly between the > native URIs of the various systems (SIMPLE and Jabber, for example). > > Well, perhaps we would like to avoid this case as much as possible, even > if it cannot be prevented altogether. So, making it a SHOULD to use a > pres URI when you know both covers some cases. However, there is a > practical issue that many existing presence servers don't use the pres > URI at this time, and so there will be potential interop problems or bugs > that surface. No doubt this is a transient problem, but it is very > possible that it will come up. > > Thus, I would ask you, in your experience with other protocols, do you > feel that given, (1) we will still have the issue you are worried about > even if we make it a SHOULD to use the pres URI when you know both, and > (2) there may be short term interoperability and deployment problems, > that the benefit of this outweighs the cost? If we were to change the document to say "SHOULD use pres: when one knows both pres: and sip:", I would be much happier. One may even include an explanatory paragraph that the reason it's not a MUST is for communication to environments with legacy SIP-only systems. If we agree that this is the only problem. >>> 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? > > Another good question. > > Really, it comes down to how you learn these URI in the first place. I > might send a SIP SUBSCRIBE to a pres URI, and the Contact header that > comes back in the 200 OK will definitely be a SIP URI. It identifies the > specific SIP user agent device I am in contact with. Perhaps you would > then use this SIP URI instead for future SUBSCRIBE. However, RFC 3261 > intends for the Contact URI to be scoped (in terms of temporal validity) > to the duration of the dialog (aka subscription). Combing over the text > in RFC3261 its not fabulously clear on this point, but thats the intent. > So, there is a built in expiration mechanism which would make it invalid > for future use. The SIP redirect response could also provide a SIP URI > for the presence URI. Redirect responses have a built in mechanism for > declaring the lifetime of the mapping, through the Expires header field. > > Alternatively, if you somehow got the SIP URI from DNS when looking up > the pres URI (note that the SRV spec does NOT give you back the SIP URI, > but let us assume it did), the DNS TTLs would tell you when it expires. I would be happier with this part if it added a note saying something like: "NOTE: For many mechanisms that allow users to learn URIs, there is a validity period implied; for instance, RFC 3261 Contact: headers are implicitly scoped to the duration of the dialog on which they are sent, and URIs that are built using information from the DNS need to respect DNS TTL values." Then it's up to the mechanisms from which you learn URIs to make sure you have a TTL when you query - I guess you have already noted this issue for the next time RFC 3261 is revised....:-) This is really an orthogonal issue to which format you want to give preference to; the problem is equally valid for both possible preferences. > So, I would argue that the only real way a user can get a hold of both > the pres and the SIP URI for the user, and not be sure for how long the > SIP URI is valid, is if they were handed to that person, on a business > card, or on a web page. I'd be hesitant to predict the future. I suspect that there will be many more ways than we currently think of that URIs are handed around. I don't think we added TTL values to LDAP or the EPP protocol, for instance.... but back to arguing about which one should be preferred: > In such cases, I would argue that it is not the > role of the IETF to dictate which is more authoritative. I could agree with this argument, if the current document didn't say the complete opposite.... if the IETF is to give guidance, I want the guidance to be what's best for the Internet..... > After all, we do > not say that if given an H.323 and a SIP URI you must use the SIP URI. > Or, given a tel URI and a SIP URI, you must use the tel. This latter case > is actually closer to the pres/sip case, since the tel URI can be looked > up in DNS to obtain a SIP URI (using ENUM, RFC 2916). [Red herring alert - arguing about analogous cases can lead the discussion far astray..... but anyway.... I don't think they're analogous - someone using a pres: URI will certainly have installed the <technology>._pres. DNS records for his domain, since the pres: URI is meaningless without such installed records. there are lots of reasons why people can have a valid tel: URI without installing records into ENUM (including the fact that the ENUM subtree for my country and your country aren't even delegated yet). If you want analogy, I would rather liken the pres: URI to a telephone number in the format +47 41 44 29 94 (international), while the SIP URI is 41 44 29 94 (national). (Perhaps the analogy even fits.. in the US, I sometimes dial US numbers in international format - it's simply simpler than figuring out what number of digits I have to cut out/revise/add in order to get the right result in *this* particular location....) .... end of analogy discussion] > The reason that the draft states a preference here is that within SIP, > there will be interoperability problems with placeing the pres URI into > the request URI. In many cases, SIP user agents use an outbound proxy, > similar to an http proxy. This proxy must understand the request URI > format in order to forward the request. If I place the pres URI in the > request URI, and this goes to the outbound proxy, and it doesnt > understand how to process the pres URI, the subscription will fail. > Ultimately, our aim is to use our own native addressing format within SIP > networks, since that promotes maximum interoperability. I think this is not the best thing for the Internet. Using the SIP addressing format exclusively within SIP networks promotes maximum interoperability *within SIP networks*. It also promotes "walling off the SIP garden", making the cost of communicating with SIP users higher for people who are not using SIP services, and it does all the lock-in and lack of flexibility that we've seen with explictly-addressed email gateways. (No, I don't want to talk about NATs....) > So, once more, I would ask - do you think that the benefits of using the > pres URI in the request URI (which are, that it is possibly more > authoritative, although I am not so sure), outweigh the drawback of > potential interoperability issues? I think so. No matter what you do, you will have interoperability issues. And if you allow people to avoid supporting pres: URIs in the first rollout of the service (when it can be added at the cost of a few extra DNS lookups), you make it that much harder to add support for it in the next version (when the "installed base" argument is a hundred times larger). At the moment, there is no widely deployed presence service that conforms to the simple-presence document. In a year, we both hope that there will be one. Harald _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple
- [Simple] Fwd: Evaluation: draft-ietf-simple-winfo… Patrik Fältström
- Re: [Simple] Fwd: Evaluation: draft-ietf-simple-w… Jonathan Rosenberg
- Re: [Simple] Fwd: Evaluation: draft-ietf-simple-w… Harald Tveit Alvestrand
- RE: [Simple] Fwd: Evaluation: draft-ietf-simple-w… hisham.khartabil
- Re: [Simple] Fwd: Evaluation: draft-ietf-simple-w… Jonathan Rosenberg