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

  It's not entirely different from what we were talking about, but it's 
not the main thrust, either. At least, not with respect to the point *I* 
was trying to make.

The analogy I was making with "data:" URLs was an attempt to debunk the 
notion that the syntactic use of "anyURI" somehow implicitly allowed the 
use of a "geo:" URI. The comparison I made was to the myriad header 
fields in SIP that allow any URI -- such as Alert-Info -- but for which 
it would be patently ridiculous to include a "data:" URL.

/a

On 7/26/10 6:02 PM, James M. Polk wrote:
> I'm not fighting you, but that's not how I remember the exchange 
> between Jon and Adam.
>
> james
>
> At 10:47 AM 7/26/2010, Richard L. Barnes wrote:
>> I wouldn't say it was explicitly ruled out.  We just noticed that it
>> was inconsistent with the requirements RFC 3693/5808 in this context.
>> What we're discussing now is how to make GEO URIs satisfy those
>> requirements.
>>
>>
>>
>> On Jul 26, 2010, at 5:10 PM, James M. Polk wrote:
>>
>>> At 08:28 AM 7/26/2010, Thomson, Martin wrote:
>>>> I missed the conclusions regarding geo URI.  I got the bit where we
>>>> decided that we needed to have _some_ text, but I'm not sure what
>>>> we decided what the text might look like.
>>>>
>>>> Help me?
>>>
>>> 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).
>>>
>>> James
>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> sipcore@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore