Re: [Ecrit] PhoneBCP

[Richard Barnes <[e-mail]>]

I still think we're disagreeing; let me try to clarify why.  I was wrong 
to focus on the word "constrain" in your message; the real issue is 
"assumptions".

This document doesn't have any "assumptions under which it works" other 
than those that need to be true for any emergency calling system, namely 
that
(1) the endpoint can be located,
(2) there's a location-to-service mapping system.
(3) relevant entities communicate over IP
These assumptions need to be true in whatever IP network you want to do 
emergency calling -- in the Internet, in a 3G network, in a WiMAX 
network, etc.  The IMS emergency calling architecture also makes these 
assumptions.

As a corollary, the solution described in this document works in any IP 
network where the above assumptions hold (including cellular networks as 
a case in point).

So one should not draw from the additional text in the latest draft that 
there are assumptions underlying the solution in this document that 
would prevent its applicability in some IP networks.  If that's how it 
is being interpreted, then we need to revise it again.

--Richard




Randall Gellens wrote:
> At 12:42 AM -0400 4/28/09, Richard Barnes wrote:
> 
>>  Ok, we clearly need to revise the text, since that's a pretty serious 
>> misunderstanding.  The text doesn't constrain the use of the protocols 
>> at all
> 
> I think the text as written is pretty clear that there is no constraint.
> 
>>  -- in fact it says "they underlying protocols can also be used to 
>> support other models in which parts of the process are delegated to 
>> the Communications Service Provider".
> 
> Yes, exactly correct.
> 
>>  The point of the current text is just that those scenarios aren't 
>> discussed in this draft, not that the overall model doesn't apply to 
>> those scenarios.
> 
> Yes, exactly.  The text merely clarifies what the draft discusses.
> 
>>  Randall Gellens wrote:
>>>  I hum for the text, which doesn't constrain the use of the 
>>> protocols, but merely describes the assumptions under which it 
>>> works.  As such, it is useful and helpful.  Even for those who think 
>>> the assumptions are obvious, it does no harm to state them.
>>>
>>>  We had a lot of debate on this in SFO, and the text in this version 
>>> was discussed on the mailing list in the days during and following 
>>> the meeting.
>