We concur with Henning's statements below and are supportive of no
restriction on the URI scheme for expressing a location reference in the
SIP location conveyance draft.
Regards,
Gary Sacra
Michael Armstrong
Verizon
----- Forwarded by GARY M. SACRA/EMPL/MD/Verizon on 08/02/2006 02:37 PM
-----
"Henning
Schulzrinne"
<[email protected]. To
edu> "Dawson, Martin"
<[email protected]>
08/02/2006 08:57 cc
AM "Ted Hardie" <[email protected]>,
"IETF SIP List" <[email protected]>,
"GEOPRIV" <[email protected]>
Subject
Re: [Sip] RE: [Geopriv] Does
Location-Conveyance have an HTTP
dereferencemechanism defined
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
On Aug 2, 2006, at 5:13 AM, Dawson, Martin wrote:
> 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]
>
> _______________________________________________
> Geopriv mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/geopriv
_______________________________________________
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
_______________________________________________
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.