Subject: Re: [paws] JSON encoding

From: <[email-masked]>
Date: Thu, 4 Oct 2012 21:10:54 +0000

I'd like to repost my request for volunteers to define a json encoding for RFC5491 (geolocation) and RFC6350 (vCard).
These could/should be separate documents, referenced by the data structure to be defined in the main solution document.

-          Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, September 25, 2012 1:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] JSON encoding

5194 is an unrelated RFC, did you mean 5491 instead? That is what I also proposed for geolocation.
That has all the things Ben is looking  for, including uncertainty, altitude, the datum ID (I guess) is part of the GML 3.1.1

I was not proposing to use 6350 for geolocation, but instead for the contact and schedule information.

-          gabor

From: ext Rosen, Brian [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, September 25, 2012 10:59 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] JSON encoding

<as individual>
Use 5194, which is based on OGC's GML in preference to 6350.  Among other things, you may need the ability to encode uncertainty of location.

You could consider the Geo URI (RFC5870), but it has the same uncertainty problem.

Brian

On Sep 25, 2012, at 1:41 PM, [email-masked]<mailto:[email-masked]> wrote:

I scanned through the data which has to be carried by PAWS, and it looks to me that there are two RFCs which we may consider re-using: RFC5491 defines the xml encoding for geo-location, I did not find a JSON encoding for it. The other one is vCard, RFC6350. There is a so called xCard, RFC6351, the xml representation of vCard, but again, I have not found a JSON encoding for vCard. vCard seems to be able to handle contact information, schedule, etc, but there are obviously other data fields, like antenna parameters, which need to be defined in PAWS.

First, I'd like to get some opinions on whether the reuse of the data structures defined in the above two RFCs is generally considered a good idea or not. If we want to reuse them, we'll need to define a JSON encoding for those. The alternative is to define the whole data structure with JSON encoding in PAWS.

I'd like to hear opinions on which way is more feasible.

-          Gabor

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

---

From: Vincent Chen <[email-masked]>
Date: Fri, 5 Oct 2012 09:09:59 -0700

Did RFC5870 also come up before as a possible model?

It seems simpler and captures (longitude, latitude, altitude, uncertainty).
It seems to fit our needs.

I think it may have been rejected before for not having uncertainty, but it
actually does.

As for vCard, I think we can go for a straight-forward encoding to JSON,
but it appears to be much more complex than what we would need for PAWS
(maybe).
It contains things like Photo, Birthday, Anniversary, etc. Should we select
a subset?

On Thu, Oct 4, 2012 at 2:10 PM, <[email-masked]> wrote:

>  I’d like to repost my request for volunteers to define a json encoding
> for RFC5491 (geolocation) and RFC6350 (vCard).****
>
> These could/should be separate documents, referenced by the data structure
> to be defined in the main solution document.****
>
> ** **
>
> **-          **Gabor****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Bajko Gabor (Nokia-CIC/SiliconValley)
> *Sent:* Tuesday, September 25, 2012 1:32 PM
> *To:* [email-masked]
>
> *Cc:* [email-masked]
> *Subject:* Re: [paws] JSON encoding****
>
>  ** **
>
> 5194 is an unrelated RFC, did you mean 5491 instead? That is what I also
> proposed for geolocation.****
>
> That has all the things Ben is looking  for, including uncertainty,
> altitude, the datum ID (I guess) is part of the GML 3.1.1****
>
> ** **
>
> I was not proposing to use 6350 for geolocation, but instead for the
> contact and schedule information.****
>
> ** **
>
> **-          **gabor****
>
> ** **
>
> ** **
>
> *From:* ext Rosen, Brian [mailto:[email-masked]]
> *Sent:* Tuesday, September 25, 2012 10:59 AM
> *To:* Bajko Gabor (Nokia-CIC/SiliconValley)
> *Cc:* [email-masked]
> *Subject:* Re: [paws] JSON encoding****
>
> ** **
>
> <as individual>****
>
> Use 5194, which is based on OGC's GML in preference to 6350.  Among other
> things, you may need the ability to encode uncertainty of location.****
>
> ** **
>
> You could consider the Geo URI (RFC5870), but it has the same uncertainty
> problem.****
>
> ** **
>
> Brian****
>
> ** **
>
> ** **
>
> ** **
>
> On Sep 25, 2012, at 1:41 PM, [email-masked] wrote:****
>
> ** **
>
> I scanned through the data which has to be carried by PAWS, and it looks
> to me that there are two RFCs which we may consider re-using: RFC5491
> defines the xml encoding for geo-location, I did not find a JSON encoding
> for it. The other one is vCard, RFC6350. There is a so called xCard,
> RFC6351, the xml representation of vCard, but again, I have not found a
> JSON encoding for vCard. vCard seems to be able to handle contact
> information, schedule, etc, but there are obviously other data fields, like
> antenna parameters, which need to be defined in PAWS.****
>
>  ****
>
> First, I’d like to get some opinions on whether the reuse of the data
> structures defined in the above two RFCs is generally considered a good
> idea or not. If we want to reuse them, we’ll need to define a JSON encoding
> for those. The alternative is to define the whole data structure with JSON
> encoding in PAWS.****
>
>  ****
>
> I’d like to hear opinions on which way is more feasible.****
>
>  ****
>
> -          Gabor****
>
>  ****
>
>  ****
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws****
>
> ** **
>
> [email-masked]

-- 
-vince