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

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
example.

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.

Cheers,
Martin

> -----Original Message-----
> From: Ted Hardie [mailto:[email protected]]
> 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
consensus
> (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
in
> subsequent
> documents for this use".
> 
> There are a variety of ways to make the ABNF say the latter, but the
key
> difference
> is that it will always be a constrained list, but the list will grow
over
> time.
> 
> I would not be happy with a unconstrained ABNF, as there are lots of
URI
> schemes
> that would not make sense here (tag?  info?  opaquelocktocken? mid?
> modem?).
> 
> I am wearing no hats here.
> 				Ted
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip