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

["James M. Polk" <[e-mail]>]

At 10:45 AM 7/15/2005 +1000, James Winterbottom wrote:

>The example is spot on with the exception of where you have put method, it 
>resides outside the location-info.

oops - of course it does

>This is what I would support.
>
>If I had also requested a DHCP Civic address then I would place this in a 
>separate tuple but inside the same PIDF document. That is, my PIDF would 
>contain two tuples, one for each location. The first tuple would be as 
>shown in your example, the second tuple would be the full civic.
>
>Does that clarify things?

Now at least, you and I know what each other is talking about. I hope 
others do too. From this we can discuss a common thing.


>-----Original Message-----
>From: James M. Polk [<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Friday, 15 July 2005 10:33 AM
>To: Winterbottom, James [WOLL:5500:EXCH]
>Cc: 'GEOPRIV'
>Subject: RE: AW: [Geopriv] Quickrandomcommentsondraft-ietf-geopriv-pdif-lo 
>-profile-00
>
>At 09:39 AM 7/15/2005 +1000, James Winterbottom wrote:
>
> >In Line
> >
> > >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.
> >
> >AJW-- If the altitude is expressed as floors, then yes you do have a
> >civic
> >component. This in my opinion MUST be represented inside the same
> >location-info element. That is, the same location-info element will
> >contain a Geo for Lat Long, AND a civic detailing the floor.
>
>so, under gml 3.0 speak (gml 3.1 replaces "point" with "pos" for position),
>you would produce something like this (subset) from a DHCP Option 123 Reply
>(I start at the status line, and omit all others above and below for 
>brevity):
>
><status>
>   <gp:geopriv>
>    <gp:location-info>
>     <gml:location>
>      <gml:Point gml:id="point96" srsName="epsg:4326">
>        <gml:coordinates>33.001111N
>                  96.68142W</gml:coordinates>
>      </gml:Point>
>     </gml:location>
>     <method>dhcp</method>
>     <gml:location>
>     <cl:civilAddress>
>      <cl:FLR>2</cl:FLR>
>     <cl:civilAddress>
>     <method>dhcp</method>
>    <gp:location-info>
>   <gp:geopriv>
><status>
>
>[I also purposely left out the retention and distribution elements]
>
>Or would you want to create a larger PIDF-LO with more information within
>the Civic location-info portion of the message body?
>
> >If this is the only "location" a client knows - Henning - are you
> >asking for:
> >
> >AJW-- We need to be very careful what we mean by a PIDF-LO here. Do you
> >mean 2 location types in the same location-info element, 2 GeoPriv
> >elements in the same tuple->status, 2 separate tuples, or two PIDF 
> documents?
>
>this is what's not clear to me - which is the reason I give a partial
>example above to discuss.
>
> >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.
> >
> >AJW-- Not quite sure that I agree here, isn't the Civic DHCP draft
> >going
> >to have its own DHCP option?.. My suggestion and thoughts are that one
> >option, 1 location-info element, that is ONE GeoPriv status element.
> >
> > >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
> > >[e-mail]
> > ><<https://www1.ietf.org/mailman/listinfo/geopriv>https://www1.ietf.org/ 
> mailman/listinfo/geopriv>https://www1.ietf.org
> > >/mai
> > lman/listinfo/geopriv
> >
> >cheers,
> >James
> >
> >                                  *******************
> >                  Truth is not to be argued... it is to be presented.
>
>cheers,
>James
>
>                                  *******************
>                  Truth is not to be argued... it is to be presented.


cheers,
James

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

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