Subject: RE: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo -profile-00

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Jul 2005 18:27:05 -0500

At 07:47 AM 7/15/2005 +1000, James Winterbottom wrote:

>Let me go away and read RFC-3825 again (spent a lot of time reading it a 
>week or so back), but it does have the notion of partial floors, as floors 
>are still expressed as decimal number.

John quoted that text in an earlier message. 3825 accounts for up to 99 
subfloors between any two decimal numbered floors.

>I am pretty sure that examples are used also.

we give one example above the ground floor, and two examples below the 
ground floor.

>They are however as explicit as the subfloor-basement B.
>
>Henning, are you suggesting that if we do a DHCP request and a DHCP 
>request for Geo that we put the results into the same 
>tuple->status->GeoPriv->location-info?

I don't understand this question.

If a client requests a DHCP Option 123, the client will get a 3 axis geo 
back (if altitude is known. There is no civic here.

If this is the only "location" a client knows - Henning - are you asking for:

1) two PIDF-LOs (one for geo, and one just for the <FLR/> element)?

2) one PIDF-LO - with a full vert/hor gml elements and altitude in the 
separate gl elements?

3) something else?

>My preference would be for there to be two tuples in this case, one for 
>the Geo and one for the civic, since they were provided with separate 
>requests.

I think Henning is asking for two of your tuples from the same DHCP Option 
123 reply - and I don't like that.

>This being the case, I see a need for both. The selection of which 
>location to actually use in any PIDF-LO can then be addressed with the 
>earlier rules.
>
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/geopriv

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jul 2005 20:46:33 -0400

Since I'm not sure I understand the question and since partial answers 
may confuse more than help, let me try to explain what I see as the 
process and issues systematically.

The DHCP client wants to get location information and then PUBLISH this 
information via PIDF-LO.

I assume that the DHCP client has no out-of-band knowledge what location 
information, if any, is available locally.

Let's assume that the DHCP client hasn't participated in the 35 geo vs. 
civic discussions on this list and just wants to get all the location 
information it can lay its virtual hands on. I know it's bad form these 
days to be an agnostic, but maybe we can tolerate it in protocols.

The most expedient way is to request both civic and geo options in one 
DHCP request, requesting them by their respective DHCP option numbers.

Let's assume both are available and are returned. (If just one, there's 
no problem except that you'll possibly generate an incomplete civic record.)

The question at hand is what the PIDF should look like, with its 1, 2 or 
3 location objects. (One: combined civic+geo, Two: one each, Three: one 
civic from the geo object, plus the full civic plus the geo object). It 
sure would be nice if we can give an answer which is something other 
than "maybe 1, maybe 2, maybe 3, depending on the weather".

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Jul 2005 20:23:39 -0500

At 08:46 PM 7/14/2005 -0400, Henning Schulzrinne wrote:
>The question at hand is what the PIDF should look like, with its 1, 2 or 3 
>location objects. (One: combined civic+geo, Two: one each, Three: one 
>sure would be nice if we can give an answer which is something other than 
>"maybe 1, maybe 2, maybe 3, depending on the weather".

don't we need to make it (state it needs to be?) parsable in any 
combination as long as the included components don't contradict (for 
example: within the same <status> have a geo and civic pointing to two 
different locations, in whole or in part)?

Using the example I gave a few minutes ago is something to be talked 
directly to, and it is not a new discussion.

Of concern about that example is if the 123 Reply came back with an 
altitude of 2.2 floors. How is that populated within 
the  <cl:civilAddress>  elements? It certainly cannot be done exactly as is 
in the <FLR> element (which is only integers now).

Whereas, according to 3825, floor 2.2 is the second floor above the 2nd 
floor, but below the 3rd floor (meaning some version of a mezzanine).

cheers,
James

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