Subject: Re: AW: [Geopriv] Quick random comments ondraft-ietf-geopriv-pdif-lo-profile-00

From: "James M. Polk" <[email-masked]>
Date: Tue, 05 Jul 2005 17:40:21 -0500

At 11:34 PM 7/5/2005 +0200, Tschofenig, Hannes wrote:
>hi henning,
>
> >
> > On a more general level, I'm also doubtful about the wisdom of having
> > partial civic (country and floor). I have a hard time
> > picturing a real
> > scenario where you would just have these two elements as
> > opposed to both
> > full civic (including city and street) and maybe geo. This
> > offers much
> > more value to recipients and avoids having to deal with
> > various strange
> > incomplete civic address objects. If floor and country is ok, why not
> > have people send street number and directional only (125 S), just for
> > the entertainment value :-)?
>
>a motivating example would certainly help.
>
>one example is the currently specified dhcp-geo where floor is combined
>with geospatial location info.

if coordinates are delivered to the DHCP client, it's wise to include the 
floor that client is on (if known). This was why we inlcuded that field 
parameter in RFC3825 (since the civic ID hadn't been written at that point).

I think we've not agreed that a coordinate PIDF-LO should include a <FLR> 
element if it learned both from a 3825 network.

this is *that* ID that Jon Peterson had Marc Linsner and I agree to write 
into this WG (at the interim meeting) as explanatory for 3825-to-GML 
implementors. That ID will not be submitted until the Vancouver IETF.

>ideally, i would like to avoid these representations. however, james
>might have better examples.

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: Tue, 05 Jul 2005 20:13:47 -0400

James M. Polk wrote:

> if coordinates are delivered to the DHCP client, it's wise to include 
> the floor that client is on (if known). This was why we inlcuded that 
> field parameter in RFC3825 (since the civic ID hadn't been written at 
> that point).

Historically, this makes sense. I would argue that carrying this forward 
is less of a good idea. I'm trying to reduce complexity here.

> 
> I think we've not agreed that a coordinate PIDF-LO should include a 
> <FLR> element if it learned both from a 3825 network.

I'm afraid I can't quite parse this sentence.

> 
> this is *that* ID that Jon Peterson had Marc Linsner and I agree to 
> write into this WG (at the interim meeting) as explanatory for 
> 3825-to-GML implementors. That ID will not be submitted until the 
> Vancouver IETF.

You can simplify your problem in Paris already :-)

Henning