Re: [sipcore] geo URI and conveyance: conclusion?

Alexander Mayrhofer <> Mon, 26 July 2010 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF0253A6807 for <>; Mon, 26 Jul 2010 08:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.604
X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 01aVfPMYH6fq for <>; Mon, 26 Jul 2010 08:17:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 66BDE3A686E for <>; Mon, 26 Jul 2010 08:17:16 -0700 (PDT)
Received: from ([]) by over TLS secured channel with XWall v3.45 ; Mon, 26 Jul 2010 17:17:35 +0200
Received: from ( by ( with Microsoft SMTP Server id 14.0.694.0; Mon, 26 Jul 2010 17:17:35 +0200
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 26 Jul 2010 17:17:34 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [sipcore] geo URI and conveyance: conclusion?
Thread-Index: Acss1LmFCudfXwsZTqezBRaozLkaiAAAC4GQ
References: <> <>
From: Alexander Mayrhofer <>
To: "James M. Polk" <>, "Thomson, Martin" <>,
Subject: Re: [sipcore] geo URI and conveyance: conclusion?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Jul 2010 15:17:24 -0000

> I believe the agreement in the room was to explicitly avoid it (i.e., 
> "MUST NOT appear in the Geolocation header value (i.e., 
> locationValue)"). As it's too close to being a data-URL (per Adam).

I wasn't in the room for the discussion. But i have to disagree that the
geo: URI scheme is "close to being a data-URL". While the data: URI
scheme has opaque semantics by definition, the geo: URI was specifically
developed to have precise and unambigious semantics associated with its
components, and a lot of time was spent on this.

So, if "too close to data-URL" translates into "lack of semantics", than
this is definitely true for the data: scheme, but definitely not for the
geo: scheme.