Subject: [Ecrit] Comment on ecrit-requirements-00 item L10

From: "Clive D.W. Feather" <[email-masked]>
Date: Tue, 27 Sep 2005 09:07:04 +0100

Item L10 says that "The preferred coordinate reference system for emergency
calls MUST be WGS-84".

Firstly, I'm not sure how "MUST" interacts with "preferred".

Secondly, in the UK the preferred coordinate system for emergency services
is OSGB National Grid. Emergency services won't easily know what to do with
a lat-long pair. Even if there is software at each end of the call to do
the conversion, it feels the wrong thing to do; furthermore, as I
understand it the conversion isn't exact and I'd hate a rounding error to
creep in.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 27 Sep 2005 15:11:41 -0400

Where is "preferred" in RFC 2119?

Also, is the IETF establishing some sort of national variant, or are we
saying here is the global method and if you like national variants, do
the conversion at the local site that uses the data.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tim Dunn
> Sent: Tuesday, September 27, 2005 11:11 AM
> To: James Polk (jmpolk); 'Clive D.W. Feather'; 'ECRIT'
> Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10
> 
> I think, yes, we prefer WGS-84 (I read that as the crux of 
> that original requirement). But if you're using a coordinate 
> system other than WGS-84, you should have a facility that 
> allows you to convert from that system to WGS-84.
> 
> By the way I said I preferred must in the second requirement 
> but was OK with should (because I thought there would be 
> consternation with requiring coordinate transformation).
> 
> So to re-reword to a much more generic set of requirements that:
> 
> A:  The preferred coordinate reference system for emergency 
> calls is WGS-84.
> B:  Systems should have an ability to perform coordinate 
> transformation between differing coordinate reference systems.
> 
> 
> Tim
> 
> 
> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, September 27, 2005 8:46 AM
> To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT'
> Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10
> 
> At 08:21 AM 9/27/2005 -0600, Tim Dunn wrote:
> >Clive-
> >
> >How about an alternate presentation of the requirement, specifically:
> >
> >A:  The preferred coordinate reference system for emergency calls is
> WGS-84.
> >B:  Systems using coordinate reference systems other than WGS-84
> >(should/must) have the ability to perform coordinate transformation 
> >from
> the
> >alternate system to WGS-84 and vice-versa.
> 
> Tim
> 
> so what you're saying is:
> 
>          "we prefer you use WGS84, and if you don't, you (should/must)
>            convert to/from it"
> 
> ..this seems like a MUST to me dressed up to sound more 
> palatable by those that don't use it.
> 
> I agree with Clive - we cannot have the words "preferred" and 
> "MUST" in the same sentence anywhere.
> 
> 
> >I feel the best classifier is MUST but I'm OK with SHOULD.
> >
> >Tim Dunn
> >Timothy N. Dunn Consulting
> >
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of
> >Clive D.W. Feather
> >Sent: Tuesday, September 27, 2005 2:07 AM
> >To: ECRIT
> >Subject: [Ecrit] Comment on ecrit-requirements-00 item L10
> >
> cheers,
> James
>                                  *******************
>                  Truth is not to be argued... it is to be presented.
>

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 27 Sep 2005 12:14:12 -0700

I don't think that use of the OSGB should be prevented, but do think
that WGS-84 should be the sole standard referred to, mostly because
wgs-84 is already prevalent and is global in scope, whereas OSGB does
not have the same reach.

I agree with Clive's first point and other subsequent suggestions from
James & Tim.

So to clarify L10 as to "preferred" vs. "MUST", I proposed text (item
added to issue tracker at, http://www.ietf-ecrit.org:8080/ecrit-req/)

So the proposal is to reword L10 into two separate requirements,

"L10a.  Reference Datum: The preferred coordinate reference system is
WGS-84."

"L10b.  Reference Datum Conversion: Systems SHOULD support the ability
to perform coordinate transformation from any used coordinate reference
system to the WGS-84 coordinate reference system."

Roger Marshall

>On Behalf Of Tom-PT Taylor
>Sent: Tuesday, September 27, 2005 11:20 AM
>To: James M. Polk
>Cc: 'ECRIT'
>Subject: Re: [Ecrit] Comment on ecrit-requirements-00 item L10
>
>I don't see why a UK system (not sure what "system" refers to, 
>BTW) would want to convert to WGS-84.  I would think it would 
>be the other way around.
>
>James M. Polk wrote:
>> At 09:11 AM 9/27/2005 -0600, Tim Dunn wrote:
>> 
>>> I think, yes, we prefer WGS-84 (I read that as the crux of that 
>>> original requirement). But if you're using a coordinate 
>system other 
>>> than WGS-84, you should have a facility that allows you to convert 
>>> from that system to WGS-84.
>>>
>>> By the way I said I preferred must in the second 
>requirement but was 
>>> OK with should (because I thought there would be consternation with 
>>> requiring coordinate transformation).
>>>
>calls is 
>>> transformation between differing coordinate reference systems....
>> 
>> 
>> ...to WGS84.
>> 
>> then I agree with this wording
>> 
>> 
>> 
>>> Tim
>>>
>>>
>>> I agree with Clive - we cannot have the words "preferred" 
>and "MUST" 
>>> in the
>>> same sentence anywhere.
>>>
>>>
>>> >From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of
>>> >Clive D.W. Feather
>>> >a lat-long pair. Even if there is software at each end of the call 
>>> >to do the conversion, it feels the wrong thing to do; furthermore, 
>>> >as I understand it the conversion isn't exact and I'd hate a 
>>> >rounding
>>> error to
>>> >creep in.
>>> >
>>> >--
>>> >Demon Internet      | WWW: http://www.davros.org | Mobile: 
>+44 7973 
>>> 377646
>>> >Thus plc            |                            |
>>> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Sep 2005 17:38:14 -0500

This sounds remarkably like similar statements I have read on UTF-8 support in XML and many protocol specs.  What you want is a common baseline that everyone understands, otherwise interoperation becomes challenging.  I'd suggest a MUST is better.

Also the wording that you have chosen could be interpreted as requiring implementations to convert from arbitrary CRS's.  Instead suggest something like:

"Implementations MUST support the WGS-84 coordinate reference system for emergency calls.  Implementations MAY support other coordinate reference systems, but they MUST be able to perform a coordinate transformation to WGS-84 where necessary."

There is a precedent for this sort of statement, see Section 7.8 of: 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-01.txt

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James M. Polk
Sent: Wednesday, 28 September 2005 2:51 AM
To: Tim Dunn; 'Clive D.W. Feather'; 'ECRIT'
Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10

At 09:11 AM 9/27/2005 -0600, Tim Dunn wrote:
>I think, yes, we prefer WGS-84 (I read that as the crux of that original
>requirement). But if you're using a coordinate system other than WGS-84, you
>should have a facility that allows you to convert from that system to
>WGS-84.
>
>By the way I said I preferred must in the second requirement but was OK with
>should (because I thought there would be consternation with requiring
>coordinate transformation).
>
>A:  The preferred coordinate reference system for emergency calls is WGS-84.
>B:  Systems should have an ability to perform coordinate transformation
>between differing coordinate reference systems....

...to WGS84.

> >(should/must) have the ability to perform coordinate transformation from
>the
>..this seems like a MUST to me dressed up to sound more palatable by those
>that don't use it.
>
>I agree with Clive - we cannot have the words "preferred" and "MUST" in the
>same sentence anywhere.
>
>
> >From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >Clive D.W. Feather

cheers,
James

                                 *******************

------------------------------------------------------------------------------------------------
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: "James M. Polk" <[email-masked]>
Date: Tue, 27 Sep 2005 18:50:25 -0500

I've changed my mind on this matter, and like Martin's wording better.

Remember, this is a requirements ID. Requirements docs say "MUST" a lot.

ECRIT is based on work done in Geopriv, which has a single datum for 
interoperability - WGS84 - even though endpoints of a communication can 
choose to use another datum, all MUST support WGS84 (EPSG's CRS 4326, I think).

As Henning pointed out correctly, this isn't about national variants, yet 
anyone's device has to work in the US, just as US devices have to work 
elsewhere. If we give in to national variants - we'll lose interoperability 
on day one to all those not native within their home nation.

We need to specify one datum, and let others be used between devices that 
negotiate the other datum(s).

At 05:38 PM 9/27/2005 -0500, Thomson, Martin wrote:
>This sounds remarkably like similar statements I have read on UTF-8 
>support in XML and many protocol specs.  What you want is a common 
>baseline that everyone understands, otherwise interoperation becomes 
>challenging.  I'd suggest a MUST is better.
>
>Also the wording that you have chosen could be interpreted as requiring 
>implementations to convert from arbitrary CRS's.  Instead suggest 
>something like:
>
>"Implementations MUST support the WGS-84 coordinate reference system for 
>emergency calls.  Implementations MAY support other coordinate reference 
>systems, but they MUST be able to perform a coordinate transformation to 
>WGS-84 where necessary."
>
>James M. Polk

cheers,
James

                                 *******************

---

From: "Roger Marshall" <[email-masked]>
Date: Thu, 29 Sep 2005 10:35:05 -0700

Clive:

With the idea of keeping the requirements more general (not saying your
system can't impose more detailed requirements on top), I believe that
the following single requirement proposed by Henning is sufficient:

L10.  Reference Datum: "The server MUST understand WGS-84 coordinate
reference system and MAY understand other reference systems."

Roger Marshall

>On Behalf Of Clive D.W. Feather
>Sent: Thursday, September 29, 2005 2:17 AM
>To: Tim Dunn
>Cc: 'ECRIT'
>Tim Dunn said:
>[...]
>Having read the discussion over the last couple of days, what 
>I think is needed is:
>
>A:  There MUST be a way in the protocol for the caller's equipment to
>    negotiate a choice of coordinate system with the PSAP.
>Aa: Calling equipment MUST be able to convert its location to 
>any of the
>    coordinate systems it offers in the negotiation.
>Ab: PSAP equipment MUST be able to convert the received 
>location from any
>    of the coordinate systems it offers in the negotiation to that
>    required internally.
>B:  Both calling equipment and PSAP MUST offer WGS-84 as part of the
>    negotiation (even if not the first choice). [This could be 
>implemented
>    either by requiring it to be on any lists, or by making it 
>the fallback
>    if negotiation fails.]
>
>Then, if the negotiation is the common one of "offer an 
>ordered list, use the first one on both side's lists":
>
>    UK CPE offers:         OSGB, WGS-84
>    other CPE offers:      XXX, YYY, WGS-84
>    UK PSAP accepts:       OSGB, WGS-84
>    other PSAP accepts:    ZZZ, WGS-84
>
>(where XXX, YYY, ZZZ are other systems) and all works.
>
>--

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 29 Sep 2005 16:13:07 -0500

A couple of points:

Clive - you suggest a negotiation (of datums) MUST be supported, and I read 
round-trips are surely the result, and at least one extension to the SIP 
protocol is needed as well.

I believe not even a worse case scenario is the UA negotiates with the ESRP 
(one or more extra round trip involved), then the ESRP negotiates with the 
PSAP (one or more extra round trip involved). And the ESRP cannot start its 
negotiation until it has agreement from the UA as to which datum to start 
with. In-series delays are not good.

While I sympathize with your suggestion, I think mandating one "mandatory 
to implement <thingy> " (the thingy here is the datum) is the best way to 
ensure there will always be *one* common <thingy> so that there is not 
additional delays and incompatibilities from the negotiation.  Perhaps in 
your coutry's case, you could accept WGS84 from the UA or ESRP into the 
PSAP and then convert to OSGB. This ensures it occurs once, and always in 
the same way with the same inaccuracy if there is any introduced with the 
conversion. This inaccuracy can become measurable and adjusted for with 
testing or time.

Also, this negotiation will have to be built into SIP spec(s) for all UAs 
to understand the new error or Reason codes involved with conveying that 
"the message was otherwise good, if it were not for the datum choice". 
Neither a 406 (Unacceptable) or 488 (Not Acceptable Here) Response message 
state this in SIP today, and this is also voilating another tenant within 
this reqs doc that 3261 compliant UAs be able to set-up an emergency call.

As to Henning's wording... comments below

>reference system and MAY understand other reference systems."

Stating the Server MUST understand WGS84 doesn't mean the UA MUST send 
WGS84 (if it is sending coordinates for location). That is one loophole I 
see in the wording that could result in interoperability problems.  May I 
suggest this wording expansion:

L10.  Reference Datum: "If a coordinate reference system is to be 
transmitted by the UA, the WGS-84 coordinate reference system MUST be used, 
and MUST be understand by the server. Additional reference systems MAY be 
used if negotiated prior to the initial emergency INVITE message."

cheers,
James

                                 *******************

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 29 Sep 2005 17:19:14 -0500

You need to identify what you mean by "The server", the context doesn't make that clear.  Are we talking about an LCMS server?  If so, use "LCMS servers MUST...".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: Friday, 30 September 2005 3:35 AM
To: Clive D.W. Feather; Tim Dunn
Cc: ECRIT
Subject: RE: [Ecrit] Comment on ecrit-requirements-00 item L10

Clive:

Roger Marshall

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 29 Sep 2005 20:59:27 -0500

Hi,

Maybe I am missing something here, but this seems to be being
represented as a requirement for how location is presented to the PSAP
rather than how the network will use location to determine a route to
the PSAP. I see these as potentially two different problems and I am not
even sure that the presentation issue is in scope for ECRIT.

Cheers
James

> Sent: Thursday, 29 September 2005 7:17 PM
> To: Tim Dunn
> Cc: 'ECRIT'
> Having read the discussion over the last couple of days, what I think
is
> needed is:
> Aa: Calling equipment MUST be able to convert its location to any of
the
> Ab: PSAP equipment MUST be able to convert the received location from
any
implemented
>     either by requiring it to be on any lists, or by making it the
> fallback
>     if negotiation fails.]
> 
> Then, if the negotiation is the common one of "offer an ordered list,
use
> the first one on both side's lists":
>