[sipcore] Location-conveyance, option tags and URI scheme support

"Peterson, Jon" <jon.peterson@neustar.biz> Wed, 10 November 2010 02:04 UTC

Return-Path: <jon.peterson@neustar.biz>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE2E3A6902 for <sipcore@core3.amsl.com>; Tue, 9 Nov 2010 18:04:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.305
X-Spam-Level:
X-Spam-Status: No, score=-102.305 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVFFZE4VA8ab for <sipcore@core3.amsl.com>; Tue, 9 Nov 2010 18:04:22 -0800 (PST)
Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id BB0553A67E3 for <sipcore@ietf.org>; Tue, 9 Nov 2010 18:04:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1289354686; x=1604174761; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=vK8QNNkibcPvS/7USD4SuKXjKSOa7+5f1xep3OqDbBI=; b=ZmvGg4iS2m8vBfSfyXx2uiNcqeqsL1slZB9pMGnZJgaTWJoq5X5Pyb7hYB7Xhk nDe/8ViidNj5LD7G7UG4xkuA==
Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.39250220; Tue, 09 Nov 2010 21:04:45 -0500
Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 9 Nov 2010 21:04:45 -0500
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Tue, 9 Nov 2010 21:04:39 -0500
Thread-Topic: Location-conveyance, option tags and URI scheme support
Thread-Index: AcuAe6GOF4JGUmD4TEKI1iKWD+xc3A==
Message-ID: <C9001EB7.480D2%jon.peterson@neustar.biz>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA==
x-ems-stamp: SyrbKu4yLFscN+SAjwH1HQ==
Content-Type: multipart/alternative; boundary="_000_C9001EB7480D2jonpetersonneustarbiz_"
MIME-Version: 1.0
Subject: [sipcore] Location-conveyance, option tags and URI scheme support
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Nov 2010 02:04:27 -0000

As much as I hoped not to have to introduce any "clever" new ideas for location-conveyance, some of Mr. Elwell's comments caused us to circle round and think about the intended application of option tags in location-conveyance, especially in conjunction with the various mechanisms intended to negotiate URI scheme support.

For a while, I've been uncomfortable with the various error codes proposed to negotiate URI scheme support for a couple of reasons: mostly because a URI scheme does not completely express the behavior that an endpoint needs to support. For example, what does it mean to say that an endpoint supports SIP as a URI scheme for acquiring location by reference? That it supports SUBSCRIBE/NOTIFY, or specifically fetch behavior, or specifically the presence event package, or specifically some subset thereof? The same applies to HTTP - one can easily imagine a bare HTTP GET for a location object, or one can imagine a broader package like HELD. Simply articulating support for a URI scheme seems insufficient. To invoke an overloaded term, we lack a means to support these sorts of "profiles" for delivering location by reference.

Meanwhile, the way the draft is written today, the use case for an option tag expressing support for "geolocation" is certainly murky at best. Rather than removing the tag, however, perhaps we should replace it instead with more specific tags for those "profiles." In this model, if you imagine we have a "presence" profile (and send requests with that tag in a Supported), and you send location to a server that supports the "held" profile, it could return a 421 with that "held" in a Require or what have you and inform the UAC what it needs to send.

This would also replace the proposed IANA registry of supported URI schemes, presumably with a registry of these "profiles," which would have something roughly like Spec Required for its policy.

Thoughts about whether or not we can endure this cleverness at this stage in the process? Backwards compatibility snafus?

Jon Peterson
NeuStar, Inc.