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 protected]> 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 protected] [mailto:[email protected]] *On Behalf > Of *Bajko Gabor (Nokia-CIC/SiliconValley) > *Sent:* Tuesday, September 25, 2012 1:32 PM > *To:* [email protected] > > *Cc:* [email protected] > *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 protected]] > *Sent:* Tuesday, September 25, 2012 10:59 AM > *To:* Bajko Gabor (Nokia-CIC/SiliconValley) > *Cc:* [email protected] > *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 protected] 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 protected] > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
