Subject: [Geopriv] New location payload offered

From: "James M. Polk" <[email-masked]>
Date: Thu, 16 Jul 2009 18:04:15 -0500

Geopriv

Several of us have updated an old idea to make it exactly what we 
intended in the first place, a TLV based location payload for usage 
by binary protocols.  Here is the link:

http://www.ietf.org/internet-drafts/draft-polk-geopriv-xml-to-tlv-00.txt

For the most part, we have taken the Geopriv Shapes doc and created a 
TLV for each element needed to form each shape. We didn't have the 
time to complete all the shapes, but you should be able to get the 
idea from what's there now.

There is no transport protocol mentioned in the doc, and I actually 
don't have one in mind within the IETF.

Comments are appreciated

James

---

From: <[email-masked]>
Date: Fri, 17 Jul 2009 01:54:32 +0200

>-----Original Message-----
  >From: [email-masked] 
  >[mailto:[email-masked]] On Behalf Of ext James M. Polk
  >Sent: Thursday, July 16, 2009 4:04 PM
  >To: [email-masked]
  >Subject: [Geopriv] New location payload offered
  >
  >Geopriv
  >
  >Several of us have updated an old idea to make it exactly 
  >what we intended in the first place, a TLV based location 
  >payload for usage by binary protocols.  Here is the link:
  >
  >For the most part, we have taken the Geopriv Shapes doc and 
  >created a TLV for each element needed to form each shape. We 
  >didn't have the time to complete all the shapes, but you 
  >should be able to get the idea from what's there now.
  >
  >There is no transport protocol mentioned in the doc, and I 
  >actually don't have one in mind within the IETF.

Then why to have the document in IETF?

The binary encoding of these shapes is already done in 3GPP and widely used. That should be good enough, there is no need to define yet another binary encoding.

- gabor

  >Comments are appreciated
  >
  >James
  >
  >_______________________________________________
  >Geopriv mailing list
  >[email-masked]
  >https://www.ietf.org/mailman/listinfo/geopriv
  >

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 16 Jul 2009 23:50:44 -0500

>Then why to have the document in IETF?

just to name a few ideas why...

#1 because Geopriv is the place to define a binary location payload in the IETF

#2 just because we have no current plans for defining how this 
payload would be used, doesn't mean someone might not have a need for 
it in an IETF binary protocol

#3 other SDOs that have some in-fighting about location formats would 
prefer an SDO (i.e., other than themselves) be in charge of defining 
and change control over this payload.

#4 it appears that the IETF is the only place where we have group 
consensus on the ideal of mapping any format to a PIDF-LO, and this 
ID has that mapping - where other SDOs have not offered that mapping.

>The binary encoding of these shapes is already done in 3GPP and 
>widely used. That should be good enough, there is no need to define 
>yet another binary encoding.

it's not like this is different than the RFC 4776 (civic locations) 
format, so please don't paint this as a BXML type "other" format.

In fact, we have this format now - called civic - if you extract out 
the DHCP part.  This new ID just adds GML fields to the existing 
format *without* bis-ing or updating 4776.

James