Subject: RE: [Ecrit] Phonebcp comments

From: "Brian Rosen" <[email-masked]>
Date: Wed, 19 Sep 2007 17:06:42 -0400

3. Section 4.5 
Converting to PIDF-LO - Isn't there an IETF reference for how to do this for
a DHCP-delivered location? 

If there is, I'm not aware, or have forgotten it.

7. Section 6.5 
Last paragraph - where did "5 minutes" come from? Is this a recommended
default, or is it exactly the right number? If it's a default, what would be
a reasonable range for configuration?

The text now reads "The suggested timer period is 5 minutes".  I've taken
flack from several people about hard numbers.  My defense is that an
implementer needs to know what to do.  This case, like several others, the
time isn't hard.  You need something.  5 minutes is as good as anything.
You don't want to configure it.  This case isn't a good example, but in some
of these, the number could be overridden by local regulation.  How a device
vendor is supposed to deal with that is beyond me, but that won't stop
regulators.  I think it's essential to put a stake in the ground and say
"here is a value".  I've tried to reword the text to be equivocal, as in
this case "suggested".

8. Section 6.6 Disabling of features 
I would prefer to see the first sentence reworded to be more explicit, like
"When a calling device and/or service determines an emergency call is being
made or is in progress, it SHOULD disable outgoing call features such as:"

The text now says ". MUST disable . when an emergency call is established".
Do I need to explicitly cover the case of "being established"?

9. Section 6.6 Disabling of features 
I'm not sure we should disable 3-way calling (which may require use of flash
hook). I think there could be a case where someone has called their best
friend to ask for help, instead of 9-1-1, and the friend then calls 9-1-1
and bridges the two legs together. If the first leg is lost, then the friend
may need to try to re-establish the first leg, because the PSAP may not have
the necessary info.

I probably need some help to word this correctly.  I think if you have a 2
way up, flash, and try to establish a call to 9-1-1, you don't end up with a
3 way call in today's system.  In NENA we have an explicit way to set up a 3
way using a bridge at the PSAP.  It's for use by a call center (like
OnStar).  

12. Section 9.1 Testing Mechanism 
2nd paragraph, "For the latter, the PSAP SHOULD return location-by-value
even if the original location delivered with the test was by-reference." I
completely disagree. I believe the appropriate requirement is "For the
latter, the PSAP MUST NOT return location-by-value when the original
location delivered with the test was by-reference."

The point is to see if the PSAP gets the right location for you.  The
problem you are having is, I assume, location hiding.  The text now says
that the PSAP uses credentials supplied by the LIS for that purpose.  That
would let the LIS decide what it returns for testing.

13. Section 9.1 
4th paragraph. 
I'm not comfortable with the potential frequency of testing that these
requirements would cause. Is there some way a PSAP can specifically tell an
end device to not query this same PSAP uri in a given (in the SIP response)
amount of time?

The text is now more clear.  In -framework, there is text that analyzes what
it takes to support a million callers with an update of location per day.
It's 12 queries a second.  Supporting 10 million NYC callers in 30 days
seems reasonable.

14. Section 10.1 
1st paragraph, last sentence, "The [L7 LCP] is not limited and TLS SHOULD be
used to protect location privacy." 
It's possible to implement theL7 LCP in an environment and manner so that it
is limited. I would prefer for this to read "The [L7 LCP] may not be limited
and TLS SHOULD be used to protect location privacy."
I actually went the other way on you and changed it to MUST :-(.  The
"limited" text is gone.  There is a generic TLS MUST be used to protect
location (but see Section 9.1).  Section 9.1 says ED-58/AN-27 https: MUST be
specified when attempting to retrieve location (configuration or 

dereferencing) with HELD.  The use of [RFC4507] is RECOMMENDED to minimize
the time to establish TLS sessions.

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon this information by persons or
entities other than the intended recipient is prohibited. If you received
this in error, please contact the sender and delete the material from all
computers. GA623

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

---

From: John Schnizlein <[email-masked]>
Date: Wed, 19 Sep 2007 17:23:18 -0400

That is the subject of draft-ietf-geopriv-binary-lci-00, which  
expired July 1 after the (previous) GeoPriv chair let it languish  
after the WG adopted it as a WG item.

There is a misinterpretation about the resolution parameter in RFC  
3825 that this draft was written to clarify, but the dispute of the  
meaning of resolution has not gone away.

John

On Sep 19, 2007, at 5:06 PM, Brian Rosen wrote:

> 3. Section 4.5
> Converting to PIDF-LO – Isn’t there an IETF reference for how to do  
> this for a DHCP-delivered location?
>
> If there is, I’m not aware, or have forgotten it.

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Thu, 20 Sep 2007 17:58:16 +0200

Hi John 

when RFC 3825 returns a point (without LoRes, LaRes, AltRes) and AT = 1 then this would translate to a point (2d or 3d depending on the altitude value) in the PIDF-LO (such as described in http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-08#section-5.2.1 .

When RFC 3825 returns a point (without LoRes, LaRes, AltRes)  and AT = 2 then the encoding described in http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-08#section-3.2 is used. 

What type of PIDF-LO encoding is used when LoRes, LaRes, AltRes is provided? 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: ext John Schnizlein [mailto:[email-masked]] 
> Gesendet: Mittwoch, 19. September 2007 23:23
> An: Brian Rosen
> Cc: 'Stark, Barbara'; 'ECRIT'
> Betreff: Re: [Ecrit] Phonebcp comments
> 
> > Converting to PIDF-LO - Isn't there an IETF reference for 
> how to do

---

From: Andrew Newton <[email-masked]>
Date: Thu, 20 Sep 2007 12:16:54 -0400

> after the WG adopted it as a WG item.

This is a bit incorrect.

Despite the fact that the binary-lci-00 draft was a very useful  
document, the working group did not adopt it.  What the working group  
consented to adopt was a draft that updated 3825.  The previous chair  
simply held to that wish, and did not allow the submittal of binary- 
lci until it was revised to be an update of 3825.  Though they were  
asked to do so by the previous chair, the authors of binary-lci never  
revised the document as needed.

> meaning of resolution has not gone away.

The working group did reach a consensus (though it was very rough) on  
this matter.

-andy

---

From: John Schnizlein <[email-masked]>
Date: Thu, 20 Sep 2007 12:54:31 -0400

There is no such thing as an RFC-3825 location "without LoRes, LaRes,  
AltRes".

RFC 3825 is all about a single point of location.  What draft-ietf- 
geopriv-binary-lci-00 clarifies is that the number of significant  
digits in the decimal-string representation of a PIDF-LO depends on  
the resolution of the binary values in an RFC-3825 location, if  
derived from there.

John

On Sep 20, 2007, at 11:58 AM, Tschofenig, Hannes (NSN - DE/Germany -  
MiniMD) wrote:

> Hi John
>
> when RFC 3825 returns a point (without LoRes, LaRes, AltRes) and AT  
> = 1 then this would translate to a point (2d or 3d depending on the  
> altitude value) in the PIDF-LO (such as described in http:// 
> tools.ietf.org/html/draft-ietf-geopriv-pdif-lo- 
> profile-08#section-5.2.1 .
>
> When RFC 3825 returns a point (without LoRes, LaRes, AltRes)  and  
> AT = 2 then the encoding described in http://tools.ietf.org/html/ 
> draft-ietf-geopriv-pdif-lo-profile-08#section-3.2 is used.
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 20 Sep 2007 14:53:12 -0500

I agree with your first point.

For your second point however the only known implementers of this argue otherwise. Please see the georpiv archives for evidence of this.

Regards
James

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Friday, 21 September 2007 2:55 AM
> To: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)
> Cc: Stark, Barbara; ECRIT
> Subject: Re: AW: [Ecrit] Phonebcp comments
> 

------------------------------------------------------------------------------------------------
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: "Stark, Barbara" <[email-masked]>
Date: Thu, 20 Sep 2007 16:25:20 -0400

Let me see if I've got this translation thing right.
For Civic:
RFC 4776 (DHCP-Civic) and ANSI/TIA-1057 (LLDP-MED) describe within those docs how their fields map to a PIDF-LO. draft-ietf-geopriv-revised-civic-lo-05 has an additional paragraph (3.5.1) for converting from DHCP when the same element is included multiple times. I don't know enough to know whether this also applies to LLDP-MED. I suppose it doesn't matter, since it looks like the easiest thing to do would be to put DHCP and LLDP-MED civic locations through the same conversion routine.

For Geo:
RFC 3825 (DHCP-Geo) and ANSI/TIA-1057 (LLDP-MED) have the same fields. Which means they should be converted through the same rules. I took a look at OGC 02-023r4 (GML 3.0), and all I can say, is thank goodness geopriv is doing draft-ietf-geopriv-pdif-lo-profile-08, or I wouldn't have a clue what to do to get the DHCP/LLDP-MED fields into the "right" format. If I read that draft correctly, it looks like the procedure would be to say "<gml:pos>Latitude Longitude</gml:pos>" if there is no Altitude, or "<gml:pos>Latitude Longitude Altitude</gml:pos>" if there is (and if AT is meters)? But this only works if Datum is WGS-84? And, as John S. and Hannes have pointed out, there's no mention of what to do with the "Res" parameters. There is a description of what to do when AT is floor.

It seems like there do need to be rules for what to do with the Res parameters, and either a reference for how to translate other Media to WGS-84, rules for it, or a prohibition (in phonebcp?) against it, if PIDF-LO will only take WGS-84.

If it appears from my statements that I'm totally ignorant of Geo formats, I just want to say that "Yes, I am". But so are most of the SIP endpoint and router developers that I deal with. And I'm asking them to be able to code this conversion into their devices. Please, geopriv WG, take pity on me (and them) and be explicit. I'd really like it if either pdif-lo-profile-08 had a section that described exactly how to convert (all fields, and all allowed values of all fields), or if there were a separate draft that said exactly how to convert. I don't care who did what to whom in the past. I just want to be given enough info to make this all work.
Barbara

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]] 
Sent: Thursday, September 20, 2007 12:55 PM
To: Tschofenig, Hannes (NSN - DE/Germany - MiniMD)
Cc: Brian Rosen; Stark, Barbara; ECRIT
Subject: Re: AW: [Ecrit] Phonebcp comments

John

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: John Schnizlein <[email-masked]>
Date: Thu, 20 Sep 2007 17:22:06 -0400

It seems perfectly clear to me that any more significant digits in  
the pidf-lo location values than there are in the binary-lci values  
are pseudo precision.

The rule would be the same as from High School chemistry class: don't  
show any more significant digits in the result of a calculation than  
were present in the measurements.

John

On Sep 20, 2007, at 4:25 PM, Stark, Barbara wrote:

> It seems like there do need to be rules for what to do with the Res  
> parameters,

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2007 10:04:10 +0200

Hi John,

you are not going to tell me that the values of the LoRes, LaRes, and 
AltRes parameters have absolutely no impact on the PIDF-LO representation.

Ciao
Hannes

John Schnizlein wrote:
> RFC 3825 is all about a single point of location.  What 
> draft-ietf-geopriv-binary-lci-00 clarifies is that the number of 
> significant digits in the decimal-string representation of a PIDF-LO 
> depends on the resolution of the binary values in an RFC-3825 
> location, if derived from there.
>
> John
>
>> when RFC 3825 returns a point (without LoRes, LaRes, AltRes) and AT = 
>> 1 then this would translate to a point (2d or 3d depending on the 
>> altitude value) in the PIDF-LO (such as described in 
>> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-08#section-5.2.1 
>> .
>>
>> When RFC 3825 returns a point (without LoRes, LaRes, AltRes)  and AT 
>> = 2 then the encoding described in 
>> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-08#section-3.2 
>> is used.
>>

---

From: John Schnizlein <[email-masked]>
Date: Fri, 21 Sep 2007 09:03:05 -0400

Hannes,

Not only did I not say that "the values of the LoRes, LaRes, and  
AltRes parameters have absolutely no impact on the PIDF-LO  
representation", but I said precisely what impact they do have: they  
determine the number of significant digits that should be included in  
the corresponding location point values.

John

On Sep 21, 2007, at 4:04 AM, Hannes Tschofenig wrote:

> Hi John,
>
> you are not going to tell me that the values of the LoRes, LaRes,  
> and AltRes parameters have absolutely no impact on the PIDF-LO  
> representation.
>
> Ciao
> Hannes
>
> John Schnizlein wrote:
>> There is no such thing as an RFC-3825 location "without LoRes,  
>> LaRes, AltRes".
>>
>> digits in the decimal-string representation of a PIDF-LO depends  
>> on the resolution of the binary values in an RFC-3825 location, if  
>> derived from there.
>>
>> John
>>
>> On Sep 20, 2007, at 11:58 AM, Tschofenig, Hannes (NSN - DE/Germany  
>> - MiniMD) wrote:
>>
>>> Hi John
>>>
>>> when RFC 3825 returns a point (without LoRes, LaRes, AltRes) and  
>>> AT = 1 then this would translate to a point (2d or 3d depending  
>>> on the altitude value) in the PIDF-LO (such as described in  
>>> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-

---

From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Fri, 21 Sep 2007 16:14:12 +0200

Hi John, 

> the corresponding location point values.

But this information about the LoRes, LaRes and AltRes would be lost in the translation since a PIDF-LO does not carry these parameters.

In other words, given the example below can you tell me what the LoRes, and LaRes values are? What does the indicated point mean?

   <?xml version="1.0" encoding="UTF-8"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
    xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
    xmlns:gs="http://www.opengis.net/pidflo/1.0"
    xmlns:gml="http://www.opengis.net/gml"
      entity="pres:[email-masked]">
     <tuple id="sg89abcd">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"
                  xmlns:gml="http://www.opengis.net/gml">
               <gml:pos>-34.407 150.883</gml:pos>
             </gml:Point>
           </gp:location-info>
           <gp:usage-rules/>
         </gp:geopriv>
       </status>
       <timestamp>2007-06-22T20:57:29Z</timestamp>
     </tuple>
   </presence>

Do I totally miss something here?

Ciao
Hannes

> draft-ietf-

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 21 Sep 2007 11:36:50 -0400

John,
Thanks. I went back and really read through RFC 3825. I see that you're
quite right in that it explains very clearly in the Appendix how to
apply the Res parameters to Latitude, Longitude, and Altitude. I think
that just left my question about the Datum parameter. Should phonebcp
restrict this to WGS 84, or should there be a recommended way to express
Datum in a PIDF-LO? Are there other conversion issues that need to be
addressed?  
Barbara

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]] 
Sent: Thursday, September 20, 2007 5:22 PM
To: Stark, Barbara
Cc: Tschofenig, Hannes (NSN - DE/Germany - MiniMD); Brian Rosen; ECRIT
Subject: Re: AW: [Ecrit] Phonebcp comments

John

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 21 Sep 2007 12:05:22 -0400

Hannes, 

> In other words, given the example below can you tell me what 
> the LoRes, and LaRes values are? What does the indicated point mean?
> 

Significant digits!

LoRes and LaRes allow you to determine your values are -34.407 150.883 and
not -34.40700000 150.88300000.  LoRes and LaRes are determined during the
conversion to binary and used in the conversion from binary.  That's it.  No
magic.

-Marc-

---

From: John Schnizlein <[email-masked]>
Date: Fri, 21 Sep 2007 12:36:46 -0400

On Sep 21, 2007, at 10:14 AM, Tschofenig, Hannes (NSN - DE/Germany -  
MiniMD) wrote:

> But this information about the LoRes, LaRes and AltRes would be  
> lost in the translation since a PIDF-LO does not carry these  
> parameters.

The (variable length) decimal string of Latitude and Longitude does  
carry resolution implicitly in the length of the string, which is its  
representation of significant digits.  Because it is fixed-length  
binary, the representation of significant digits in the LCI is an  
explicit parameter.

> In other words, given the example below can you tell me what the  
> LoRes, and LaRes values are?

Interesting puzzle.  Without all the syntactic sugar, the (Lat, Long)  
is (-34.407 150.883), which has 3 decimal digits of fraction.  Since  
2^10 ~= 10^3, the 10 fractional (binary) digits, plus the 9 (integer  
part) implies LaRes = LoRes = 19.

It is true that the (over 3 times) finer grain of binary resolution  
is lost somewhat in the coarser grain of decimal resolution.   
Certainly, not all the information is lost, just slightly less than  
two bits of information.

> What does the indicated point mean?

GoogleEarth conveniently displays decimal degrees, and from the map,  
this appears to be the Computer Science building at the University of  
Wollongong.

To see the expressive power of resolution, notice the fewer  
significant digits in the location (-34.406, 150.88) of the entire  
campus, and (-34.40691, 150.88299) for a corner office in the NE wing  
of that building.

John

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Sep 2007 22:40:20 +0200

Hi Marc,
Hi John,

thanks for responding so quickly on this subject.

I had a chat with Brian about this topic and he explained me the 
assumptions that are being made.
For me it would have helped to read a bit background on the translation 
to a PIDF-LO in draft-ietf-geopriv-binary-lci. 
</html/draft-ietf-geopriv-binary-lci-00.txt>

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 22 Sep 2007 03:10:42 -0500

And the normative text from section 2.1 of RFC-3825

"The examples in the appendix illustrate that a smaller value in the
   resolution field increases the area within which the device is
   located."

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Saturday, 22 September 2007 2:05 AM
> To: 'Hannes Tschofenig'
> Cc: 'ECRIT'
> Subject: RE: AW: [Ecrit] Phonebcp comments
> 
> Hannes,
> 
> conversion to binary and used in the conversion from binary.  That's
it.
> No

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 23 Sep 2007 19:33:49 -0500

It seems that this discussion has wandered over the ECRIT/GEOPRIV divide.  I only read titles in ECRIT when I'm busy, so this escaped my notice.

Firstly, GML does not include mention of significant figures and how to interpret digital representations.  Therefore, we cannot rely on using the length of any number to convey any information.  Sorry, we can't rely on implied meaning.

Based on this interpretation, it is impossible to represent a point in space, irrespective of any requirement to do so.  The 3825 representation is an area (c.f. Section 2.1); similarly, the GML representation of a point is actually an area too.

I propose that we do away with any implied or assumed meaning.  Significant figures are useless because they rely on an assumption.

It seems to me that it would be best to resolve this on the GEOPRIV list and simply have -phone-bcp reference what is produced there.

Therefore, I propose that the answer to the original question is in Section 3.2 of (my) 3825bis:

http://tools.ietf.org/html/draft-thomson-geopriv-3825bis-00#section-3.2

Cheers,
Martin

"If you ever feel you need to write something using sig[nificant] fig[ure]s, you should lie down until the feeling goes away.  Figure out what you are trying to say, and find a better way of saying it. If you are going to express the uncertainty at all, express it separately and explicitly."

> Sent: Saturday, 22 September 2007 2:37 AM
> Subject: Re: AW: AW: [Ecrit] Phonebcp comments
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 23 Sep 2007 23:41:57 -0500

Hi Barbara,

The appendix in RFC3825 shows how to use the resolution to express an
area, I strongly recommend that you do not use this encoding to do this
as the results are totally unpredictable.

Regards
James

> From: Stark, Barbara [mailto:[email-masked]]
> Sent: Saturday, 22 September 2007 1:37 AM
> To: John Schnizlein
> Cc: Tschofenig,Hannes (NSN - DE/Germany - MiniMD); ECRIT
> privileged material. Any review, retransmission, dissemination or
other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited.
If
> you received this in error, please contact the sender and delete the
> material from all computers. GA625
> 
> 
>