RE: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP dereferencemechanism defined

From: Dawson, Martin ^lt;>
Date: Wed Aug 02 2006 - 05:13:02 EDT

Hi Ted,

This gets back to what I and others are in disagreement with.

I don't agree with a SIP document specifying a list of approved geopriv
using protocols. I also disagree that a location reference in a
particular form actually indicate the protocol that will be used to do
the de-reference operation. Your own example, in the strawman you
submitted, showed how a http uri could reference a service which
actually applies a geopriv-compliant set of semantics. It's also the
case that it could be used to access a service that wasn't compliant.

Beyond that, if there was going to be a master set of approved
protocols, it would be appropriately maintained as a geopriv document
wouldn't it?

SIP is not going to be the only conveyance protocol that could send a
location reference around. Indeed, it isn't already since the V2
interface protocol defined in the NENA i2 specification is another

It does not make sense from a maintenance perspective, to have to go
around every conveyance protocol definition in the world and update them
each time a new using protocol is defined. That is excessive coupling -
and not good engineering.


> -----Original Message-----
> From: Ted Hardie []
> Sent: Wednesday, 2 August 2006 4:54 AM
> To: Andrew Newton; Winterbottom, James
> Cc: IETF SIP List; Rosen, Brian; GEOPRIV
> Subject: Re: [Sip] RE: [Geopriv] Does Location-Conveyance have an HTTP
> dereferencemechanism defined
> At 9:03 PM -0400 7/31/06, Andrew Newton wrote:
> >
> >Brian is right. They are not the same issue, atleast they do not
have to
> be.
> >
> >From where I sit, I think the consensus is:
> > - do not constrain the ABNF
> > - HTTP goes in another document
> >
> >Keep in mind, my hat is labeled "GEOPRIV" and this is a SIP document.
> I agree with the "HTTP goes in another document" statement of
> (and the consensus appears to be that HTTP MUST be a using protocol).
> I think "do not constrain the ABNF" is not the right formulation
though; I
> think the consensus is: "limit URI schemes to those approved here or
> subsequent
> documents for this use".
> There are a variety of ways to make the ABNF say the latter, but the
> difference
> is that it will always be a constrained list, but the list will grow
> time.
> I would not be happy with a unconstrained ABNF, as there are lots of
> schemes
> that would not make sense here (tag? info? opaquelocktocken? mid?
> modem?).
> I am wearing no hats here.
> Ted
> _______________________________________________
> Geopriv mailing list

This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.

Geopriv mailing list
Received on Wed, 2 Aug 2006 04:13:02 -0500

This archive was generated by hypermail 2.1.8 : Wed Aug 02 2006 - 05:30:29 EDT