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

From: Ted Hardie <[email-masked]>
Date: Tue, 1 Aug 2006 11:53:39 -0700

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-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 2 Aug 2006 04:13:02 -0500

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-masked]]
> 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
> 
> >Brian is right.  They are not the same issue, atleast they do not
have to
> be.
> 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

------------------------------------------------------------------------------------------------
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]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 2 Aug 2006 08:57:32 -0400

I'll also re-iterate and rephrase another point made by somebody else  
before: Restricting URL schemes makes the system non-upgradeable. If  
a proxy supports "RFC-conveyance" that restricts URLs to a particular  
scheme list, it will have to reject as flawed a request that contains  
a newly-defined protocol it doesn't yet know about. Thus, reliably  
introducing a new protocol would have to wait until every location- 
aware proxy in the world has been upgraded, which I hope we agree is  
untenable. The right model is that a proxy that doesn't implement or  
doesn't want to support (by policy) a certain URL scheme is to ignore  
it. SIP always has strived to make it possible to evolve systems  
incrementally, so this type of restriction is well outside  
established SIP design practice.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Wed, 02 Aug 2006 09:24:32 -0400

Henning Schulzrinne wrote:
> before: Restricting URL schemes makes the system non-upgradeable. If a 
> proxy supports "RFC-conveyance" that restricts URLs to a particular 
> scheme list, it will have to reject as flawed a request that contains a 
> newly-defined protocol it doesn't yet know about. Thus, reliably 
> introducing a new protocol would have to wait until every location-aware 
> proxy in the world has been upgraded, which I hope we agree is 
> incrementally, so this type of restriction is well outside established 
> SIP design practice.

Henning, these are separable issues.  Codification of rejection of unknown 
URI schemes and maintenance of a list sanctioned schemes are two different 
things.

-andy

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 Aug 2006 11:52:06 -0700

At 9:24 AM -0400 8/2/06, Andrew Newton wrote:
>>I'll also re-iterate and rephrase another point made by somebody else before: Restricting URL schemes makes the system non-upgradeable. If a proxy supports "RFC-conveyance" that restricts URLs to a particular scheme list, it will have to reject as flawed a request that contains a newly-defined protocol it doesn't yet know about. Thus, reliably introducing a new protocol would have to wait until every location-aware proxy in the world has been upgraded, which I hope we agree is untenable. The right model is that a proxy that doesn't implement or doesn't want to support (by policy) a certain URL scheme is to ignore it. SIP always has strived to make it possible to evolve systems incrementally, so this type of restriction is well outside established SIP design practice.
>
>Henning, these are separable issues.  Codification of rejection of unknown URI schemes and maintenance of a list sanctioned schemes are two different things.
>

Henning,

What difference do you see between the proxy behavior when something
is rejected as "flawed" because it contains a newly defined protocol and proxy behavior
when the URL scheme list is open and the proxy encounters one it does not understand?

Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 02 Aug 2006 14:57:21 -0400

> when the URL scheme list is open and the proxy encounters one it does not understand?

There are three cases, in general:

- "flawed" -> reject request with 4xx error

- "don't understand any" -> ignore (and maybe special-case route it to 
some smart entity that might) or generate error

- "don't understand one of the schemes" -> ignore and pick one you 
understand

I'm assuming a model where a request may contain multiple location 
references, just like LoST responses can point to multiple PSAP URI schemes.

That, by the way, is the level of detail that the draft might want to 
have and seems to be leaving somewhat under-defined.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 02 Aug 2006 15:03:37 -0400

> some smart entity that might) or generate error

The other case for "don't understand any" could be reject.  To reject or 
ignore or smart-host forward would be a matter of local policy.

> have and seems to be leaving somewhat under-defined.

Very definitely agreed.  Thanks for the mental exploration.

-andy