Subject: [paws] JSON encoding

From: <[email-masked]>
Date: Tue, 25 Sep 2012 17:41:52 +0000

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Sep 2012 13:59:21 -0400

<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:

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: Tue, 25 Sep 2012 11:03:09 -0700

FYI. http://json-schema.org/ Version 4 of the IETF draft is active.
 - This link references JSON schemas for Geographic Coordinate and Card.

I have mixed feelings about re-using when the referenced schema is complex
and contains many fields that might not make sense for PAWS. We would end
up documenting which portions of those schemas are required, optional, etc.
I think that's a case-by-case decision.

On Tue, Sep 25, 2012 at 10:41 AM, <[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]

-- 
-vince

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 25 Sep 2012 14:09:18 -0400

Same problem, no way to represent uncertainty (or confidence, but we could specify confidence at 95%).

Brian

On Sep 25, 2012, at 2:03 PM, Vincent Chen <[email-masked]<mailto:[email-masked]>> wrote:

I have mixed feelings about re-using when the referenced schema is complex and contains many fields that might not make sense for PAWS. We would end up documenting which portions of those schemas are required, optional, etc.
I think that's a case-by-case decision.

On Tue, Sep 25, 2012 at 10:41 AM, <[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.

-          Gabor

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Tue, 25 Sep 2012 11:49:32 -0700

The ability to include uncertainty seems like it may be important.
I can imagine as protection criteria evolve, we may see criteria
based on relative proximity to protected devices, and position
uncertainty is important for figuring that out. We also see it
specified in the exchange of information between dependent devices
and the internet connected device (802); Proposed standards in
802.11 and 802.15 under development use an encoding based on
RFC6225, which includes uncertainty, and it could be quite handy if
it is obvious how to map from this form to whatever PAWS transports.

So yes, use one that supports that. It'd be even better if it can be
elided when not needed to save bits on the air.

-Ben

<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

paws mailing list

[email-masked]

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Tue, 25 Sep 2012 12:00:16 -0700

The 'geo' representation does not include all the information that
typically is carried around with Lat/Lon. We will need altitude and
most likely the datum ID, uncertainty as mentioned before.

Did I look at the wrong thing?

Ben

FYI. http://json-schema.org/ Version
4 of the IETF draft is active.

- This link references JSON schemas for Geographic
Coordinate and Card.

I have mixed feelings about re-using when the referenced
schema is complex and contains many fields that might not
make sense for PAWS. We would end up documenting which
portions of those schemas are required, optional, etc.

On Tue, Sep 25, 2012 at 10:41 AM,
<[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]

--

-vince

---

From: <[email-masked]>
Date: Tue, 25 Sep 2012 20:31:42 +0000

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>

Brian

-          Gabor

---

From: Teco Boot <[email-masked]>
Date: Tue, 25 Sep 2012 23:06:22 +0200

> 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 de…

I prefer to use current encoding as much as possible, with as a goal a clean and straightforward data structure. With compact messages in mind.

Teco

---

From: <[email-masked]>
Date: Wed, 26 Sep 2012 00:52:53 +0000

Those are simplistic, not suitable for our purpose. - gabor

From: ext Vincent Chen [mailto:[email-masked]]
Sent: Tuesday, September 25, 2012 11:03 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: Re: [paws] JSON encoding

-          Gabor

--
-vince