Subject: Re: [paws] XML schema versus JSON, vCard & iCal

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 13 Aug 2012 18:14:02 -0400

json is okay with me.  
I'd prefer an ISO time stamp rather than a time in seconds since epoch.  It's very easy to parse, and its simpler to use and debug.  Don't care a whole lot about that

Brian <as individual>

 -----Original Message-----
From: 	Vincent Chen [mailto:[email-masked]]
Sent:	Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:	Peter Stanforth
Cc:	Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]
Subject:	Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Between XML and JSON, JSON messages are more compact and easier to process (parsing, synthesis). As clarification, JSON does not require JavaScript or a Browser. It is a text-based representation of data that is language independent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see of http://json.org) and seem to be reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for datetime-string parsing on devices, assuming devices already have native libraries that provide time in this format. Is that a valid assumption? Of course, this is less human-readable....

On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth <[email-masked]> wrote:

	Whenever we built mobile devices we never dealt with IETF, in our sensor
	days even an IP stack was a challenge,so I would defer to the device guys
	on that one.
	
	On MonAug/13/12 Mon Aug 13, 9:30 AM, "Rosen, Brian"
	
	<[email-masked]> wrote:
	
	>Our experience in the IETF over many years is that economizing message
	>size and compromising utility and security in search of efficiency of
	>implementation on small devices is a poor trade off.  I am not advocating
	>being wasteful of resources, but I don't think we should seriously
	>consider the overhead of XML or json to be significant.
	>
	>Assuming a json library can be loaded on a small device is reasonable.
	>
	>Brian (as individual)
	>
	>
	>
	> -----Original Message-----
	>From:  Peter Stanforth [mailto:[email-masked]]
	>Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
	>To:    Teco Boot; Benjamin A.Rolfe
	>Cc:    [email-masked]
	>Subject:       Re: [paws] XML schema versus JSON, vCard & iCal
	>
	>Not all masters run over the core network.
	>Some of the Use cases have a master talking to another OTA
	>We should not assume that all Masters are attached to utility power so we
	>should be sympathetic to processing energy use also.
	>
	>On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <[email-masked]> wrote:
	>
	>>
	>>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende
	>>geschreven:
	>>
	>>> Compactness of messages is important, but it is also important (to me
	>>>at least) to be realizable in an implementation with limited resources,
	>>>such as embedded devices in what are now popularly called "M2M"
	>>>applications.  A lot of these devices could use IP all the end to end,
	>>>but may have a very compact, simple stack and applications (i.e.  no
	>>>browser).  Is JSON typically implemented when there is no browser?
	>>>Would it be hard to do in a resource constrained device (i.e. where we
	>>>talk about memory size in Kilo-bytes still).
	>>
	>>In use cases and requirements document, there are no requirements for
	>>protocol performance. I guess OS/IP/TCP/TLS code size supersedes needs
	>>for JSON or XML.
	>>
	>>Same for timing: TCP/TLS connection setup will take more than the PAWS
	>>message exchange, I think. This may be of importance when using satcom
	>>links.
	>>
	>>Because PAWS runs between master and database, over core network,
	>>performance is not our primary concern. But as always, it is good to keep
	>>an eye on efficiency.
	>>
	>>Teco
	>>
	>>> Thanks
	>>> Ben
	>>>
	>>>
	>>>> We had a discussion on XML vs. JSON. I prefer the one with most
	>>>>compact messages.
	>>>>
	>>>> On vCard and JSON: what is the status of "A JavaScript Object Notation
	>>>>(JSON) Representation for vCard"?
	>>>> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
	>>>>
	>>>> On valid times: can we use same format as certificates? They have
	>>>>similar simple requirements: valid notBefore&  notAfter.
	>>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
	>>>>
	>>>> Teco
	>>>> _______________________________________________
	>>>> paws mailing list
	>>>> [email-masked]
	>>>> https://www.ietf.org/mailman/listinfo/paws
	>>>>
	>>>
	>>> _______________________________________________
	>>> paws mailing list
	>>> [email-masked]
	>>> https://www.ietf.org/mailman/listinfo/paws
	>>
	>>_______________________________________________
	>>paws mailing list
	>>[email-masked]
	>>https://www.ietf.org/mailman/listinfo/paws
	>
	>_______________________________________________
	>paws mailing list
	>[email-masked]
	>https://www.ietf.org/mailman/listinfo/paws
	
	_______________________________________________
	paws mailing list
	[email-masked]
	https://www.ietf.org/mailman/listinfo/paws

-- 
-vince

---

From: <[email-masked]>
Date: Thu, 16 Aug 2012 23:25:54 +0000

We have not heard any objections for using JSON encoding instead of XML. 
Therefore, let's go for JSON, and close this thread.

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.  

Brian <as individual>

 -----Original Message-----
From: 	Vincent Chen [mailto:[email-masked]]
Sent:	Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:	Peter Stanforth
Cc:	Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]
Subject:	Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

	

	

-- 
-vince

---

From: Weixinpeng <[email-masked]>
Date: Fri, 17 Aug 2012 01:28:34 +0000

Hi all, 
	I am not sure whether there is something in JSON to define the value type or the range of value, because in XML 
the type and the value range of every element can be defined exactly. Is it necessary to deal this in XML/JSON ?

--Xinpeng Wei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, August 17, 2012 7:26 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.  

Brian <as individual>

 -----Original Message-----
From: 	Vincent Chen [mailto:[email-masked]]
Sent:	Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:	Peter Stanforth
Cc:	Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]
Subject:	Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

	

	

-- 
-vince

---

From: Manikkoth Sajeev <[email-masked]>
Date: Thu, 16 Aug 2012 19:37:38 -0700 (PDT)

Hi,
 
Can it not be both JSON and XML supported? I would vote for that. Future implementations may prefer XML as it is generic, omni present, easy to understand and validate. For compactness may be a  binary xml option can also work. JSON I think will necessitate implementation to be native Java and may not be as friendly with other implementation languages.

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002
Email: [email-masked]
http://www.linkedin.com/in/mksajeev

________________________________
 From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked] 
Cc: [email-masked] 
Sent: Friday, 17 August 2012, 4:55
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

- Gabor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.  

Brian <as individual>

-----Original Message-----

XML vs JSON

Between XML and JSON, JSON messages are more compact and easier to process (parsing, synthesis). As clarification, JSON does not require JavaScript or a Browser. It is a text-based representation of data that is language independent, yet well-matched to all major languages. JSON-handling libraries exist for numerous languages (see of http://json.org/) and seem to be reasonably light weight.

Timestamps

    

    >Our experience in the IETF over many years is that economizing message
    >size and compromising utility and security in search of efficiency of
    >implementation on small devices is a poor trade off.  I am not advocating
    >being wasteful of resources, but I don't think we should seriously
    >consider the overhead of XML or json to be significant.
    >
    >Assuming a json library can be loaded on a small device is reasonable.
    >
    >Brian (as individual)
    >
    >
    >
    > -----Original Message-----
    >From:  Peter Stanforth [mailto:[email-masked]]
    >Sent:  Saturday, August 11, 2012 07:13 AM Eastern Standard Time
    >To:    Teco Boot; Benjamin A.Rolfe
    >Cc:    [email-masked]
    >Subject:       Re: [paws] XML schema versus JSON, vCard & iCal
    >
    >Not all masters run over the core network.
    >Some of the Use cases have a master talking to another OTA
    >We should not assume that all Masters are attached to utility power so we
    >should be sympathetic to processing energy use also.
    >
    >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <[email-masked]> wrote:
    >
    >>
    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe het volgende
    >>geschreven:
    >>
    >>> Compactness of messages is important, but it is also important (to me
    >>>at least) to be realizable in an implementation with limited resources,
    >>>such as embedded devices in what are now popularly called "M2M"
    >>>applications.  A lot of these devices could use IP all the end to end,
    >>>but may have a very compact, simple stack and applications (i.e.  no
    >>>browser).  Is JSON typically implemented when there is no browser?
    >>>Would it be hard to do in a resource constrained device (i.e. where we
    >>>talk about memory size in Kilo-bytes still).
    >>
    >>In use cases and requirements document, there are no requirements for
    >>protocol performance. I guess OS/IP/TCP/TLS code size supersedes needs
    >>for JSON or XML.
    >>
    >>Same for timing: TCP/TLS connection setup will take more than the PAWS
    >>message exchange, I think. This may be of importance when using satcom
    >>links.
    >>
    >>Because PAWS runs between master and database, over core network,
    >>performance is not our primary concern. But as always, it is good to keep
    >>an eye on efficiency.
    >>
    >>Teco
    >>
    >>> Thanks
    >>> Ben
    >>>
    >>>
    >>>> We had a discussion on XML vs. JSON. I prefer the one with most
    >>>>compact messages.
    >>>>
    >>>> On vCard and JSON: what is the status of "A JavaScript Object Notation
    >>>>(JSON) Representation for vCard"?
    >>>> http://tools.ietf.org/html/draft-bhat-vcarddav-json-00
    >>>>
    >>>> On valid times: can we use same format as certificates? They have
    >>>>similar simple requirements: valid notBefore&  notAfter.
    >>>> http://tools.ietf.org/html/rfc3280#section-4.1.2.5
    >>>>
    >>>> Teco
    >>>> _______________________________________________
    >>>> paws mailing list
    >>>> [email-masked]
    >>>> https://www.ietf.org/mailman/listinfo/paws
    >>>>
    >>>
    >>> _______________________________________________
    >>> paws mailing list
    >>> [email-masked]
    >>> https://www.ietf.org/mailman/listinfo/paws
    >>
    >>_______________________________________________
    >>paws mailing list
    >>[email-masked]
    >>https://www.ietf.org/mailman/listinfo/paws
    >
    >_______________________________________________
    >paws mailing list
    >[email-masked]
    >https://www.ietf.org/mailman/listinfo/paws

-- 
-vince

---

From: Cuiyang <[email-masked]>
Date: Fri, 17 Aug 2012 02:49:40 +0000

Hi, Sajeev

I prefer to the support of both xml and json, too.

Best Regards,
Yang
==================
Yang Cui,  Ph.D.
Huawei Technologies
[email-masked]

发件人: [email-masked] [mailto:[email-masked]] 代表 Manikkoth Sajeev
发送时间: 2012年8月17日 10:38
收件人: [email-masked]; [email-masked]; [email-masked]; [email-masked]
抄送: [email-masked]
主题: Re: [paws] XML schema versus JSON, vCard & iCal

Hi,

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002
Email: [email-masked]

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:

    <[email-masked]<mailto:[email-masked]>> wrote:

    >From:  Peter Stanforth [mailto:[email-masked]<mailto:[email-masked]>]
    >Cc:    [email-masked]<mailto:[email-masked]>
    >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <[email-masked]<mailto:[email-masked]>> wrote:
    >
    >>
    >>>> [email-masked]<mailto:[email-masked]>
    >>> [email-masked]<mailto:[email-masked]>
    >>[email-masked]<mailto:[email-masked]>
    >[email-masked]<mailto:[email-masked]>

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

--
-vince

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 17 Aug 2012 09:25:44 -0400

I don't really care whether we use json or xml as a matter of protocol design or implementation, but I am a big fan of reusing standards rather than defining new ones, and I would not want to see the choice of json mean we then decide to roll our own versus using existing standards based on the idea there is no json representation of an existing standard.  So, if choosing json means folks feel free to ignore existing xml based standards such as xCard and LoST, then I would not want to use json.

I would prefer to not have "both", because of interoperability complications.  If there is rough consensus for both, then I would assert that all servers have to implement both and the client can implement either.

There are json validators, so I don't think that is a big deal.

My experience in protocol design on the Internet is that decisions made solely or even largely because of compactness advantages rarely are good choices.  If you like json because it is smaller, then I believe you need a much better reason.  Binary doesn't work for me, at all.  I have been involved in big binary vs text wars in protocol design.  Text wins, binary loses, in my opinion.

Brian <as individual>

From: Manikkoth Sajeev <[email-masked]<mailto:[email-masked]>>
Reply-To: Manikkoth Sajeev <[email-masked]<mailto:[email-masked]>>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Rosen, Brian" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Hi,

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002
Email: [email-masked]<mailto:[email-masked]>
http://www.linkedin.com/in/mksajeev

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Sent: Friday, 17 August 2012, 4:55
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

---

From: Don Joslyn <[email-masked]>
Date: Fri, 17 Aug 2012 14:22:47 -0400

I vote for supporting both XML and JSON. From a database perspective, it's not that much trouble supporting both (I'm speaking from experience), and supporting both provides the radio vendors with more than one option to chose from.
We have already worked with 6 different radio vendors that have successfully used XML parsers in their devices to support whitespace messaging via XML.

I would NOT make it a requirement that every database MUST implement both XML and JSON. Let that be a business decision; If you implement both, you potentially get more customers. The regulators don't care which format we use.

If for some very good reason it's impossible for PAWS to support both, let me know and I'll vote for only one.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, August 17, 2012 9:26 AM
To: Manikkoth Sajeev; [email-masked]; [email-masked]; Peter Stanforth
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

---

From: Weixinpeng <[email-masked]>
Date: Sat, 18 Aug 2012 01:06:05 +0000

Considering of the design of database discovery protocol, the LoST protocol may be used and LoST is based on XML, so I think XML may be preferred.

--Xinpeng Wei

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, August 17, 2012 9:26 PM
To: Manikkoth Sajeev; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Mon, 20 Aug 2012 11:56:22 -0700

*

   - One of our goals is to strive to lower the cost and complexity for
   device manufacturers. This lowers the barrier for building a robust
   ecosystem.

   - To reduce complexity and cost for device makers, supporting 1 encoding
   is better than both, as Brian points out. WiFi access points that "just
   work" anywhere in the world serves as a good model.

   - There's a trend for APIs on the web towards JSON (Twitter, FourSquare,
   Facebook, Google, etc.). One of the major reasons is that developers
   (client-side) prefer it for its simplicity:
      - Representation closely matches most data models (nested lists and
      maps)
      - Simple-to-use libraries exist for all major languages/platforms
      - Don't need a tool chain to work with the data, as is typically
      needed for XML.

Apparently, the efficiency gains of JSON also matter to the scalability of
serving systems.

   - At the end of the day, it's the data model that matters, rather than
   the encoding. We (Google) are actually neutral on XML vs JSON, as long as
   we're clear on what device makers want. It would be good to get feedback
   from device makers (especially of embedded devices) regarding experiences
   supporting XML vs JSON.

Don, can you elaborate on the types of devices that already support XML?

*

On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <[email-masked]> wrote:

>  Considering of the design of database discovery protocol, the LoST
> protocol may be used and LoST is based on XML, so I think XML may be
> preferred.****
>
> ** **
>
> --Xinpeng Wei****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Rosen, Brian
>
> *Sent:* Friday, August 17, 2012 9:26 PM
> *To:* Manikkoth Sajeev; [email-masked]; [email-masked];
> [email-masked]
>
> *Cc:* [email-masked]
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal****
>
>  ** **
>
> I don't really care whether we use json or xml as a matter of protocol
> design or implementation, but I am a big fan of reusing standards rather
> than defining new ones, and I would not want to see the choice of json mean
> we then decide to roll our own versus using existing standards based on the
> idea there is no json representation of an existing standard.  So, if
> choosing json means folks feel free to ignore existing xml based standards
> such as xCard and LoST, then I would not want to use json.****
>
> ** **
>
> I would prefer to not have "both", because of interoperability
> complications.  If there is rough consensus for both, then I would assert
> that all servers have to implement both and the client can implement either.
> ****
>
> ** **
>
> There are json validators, so I don't think that is a big deal.  ****
>
> ** **
>
> My experience in protocol design on the Internet is that decisions made
> solely or even largely because of compactness advantages rarely are good
> choices.  If you like json because it is smaller, then I believe you need a
> much better reason.  Binary doesn't work for me, at all.  I have been
> involved in big binary vs text wars in protocol design.  Text wins, binary
> loses, in my opinion.****
>
> ** **
>
> Brian <as individual>****
>
> ** **
>
> *From: *Manikkoth Sajeev <[email-masked]>
> *Reply-To: *Manikkoth Sajeev <[email-masked]>
> *Date: *Thu, 16 Aug 2012 22:37:38 -0400
> *To: *"[email-masked]" <[email-masked]>, "Rosen, Brian" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [paws] XML schema versus JSON, vCard & iCal****
>
> ** **
>
> Hi,****
>
>  ****
>
> Can it not be both JSON and XML supported? I would vote for that. Future
> implementations may prefer *XML as it is generic, omni present, easy to
> understand and validate.* For compactness may be a  *binary xml option*can also work. JSON I think will necessitate implementation to be native
> Java and may not be as friendly with other implementation languages.****
>
>  ****
>
> *Best Regards,*****
>
> *Sajeev Manikkoth
> Mobile: +918792292002
> Email: [email-masked]
> http://www.linkedin.com/in/mksajeev*****
>
> ** **
>
> *From:* "[email-masked]" <[email-masked]>
> *To:* [email-masked]; [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Sent:* Friday, 17 August 2012, 4:55
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal****
>
>
> I'd prefer an ISO time stamp rather than a time in seconds since epoch.
> It's very easy to parse, and its simpler to use and debug.  Don't care a
> whole lot about that
>
> Brian <as individual>
>
>
>
> Between XML and JSON, JSON messages are more compact and easier to process
> (parsing, synthesis). As clarification, JSON does not require JavaScript or
> a Browser. It is a text-based representation of data that is language
> independent, yet well-matched to all major languages. JSON-handling
> libraries exist for numerous languages (see of http://json.org/) and seem
> to be reasonably light weight.
>
> Timestamps
>
> As for timestamp specifications, should we consider just using seconds
> since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need
> for datetime-string parsing on devices, assuming devices already have
> native libraries that provide time in this format. Is that a valid
> assumption? Of course, this is less human-readable....
>
>
> ****

-- 
-vince

---

From: Don Joslyn <[email-masked]>
Date: Mon, 20 Aug 2012 16:54:21 -0400

Please see my comments below...
Thanks,
Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Monday, August 20, 2012 2:56 PM
To: Weixinpeng
Cc: [email-masked]; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

 *   One of our goals is to strive to lower the cost and complexity for device manufacturers. This lowers the barrier for building a robust ecosystem.
[DJ - The "cost" and complexity of using XML has not been an issue for the half dozen TVBD vendors that have already used XML. Maybe we need to better define "cost"?]

 *   To reduce complexity and cost for device makers, supporting 1 encoding is better than both, as Brian points out. WiFi access points that "just work" anywhere in the world serves as a good model.
[DJ - I proposed that the databases support both XML and JSON, devices only need to support one to talk to the database. Our current database supports XML and JSON, but if I'm forced to pick only one, then I will vote for XML because it's the one that we currently use on all embedded devices.]

 *   There's a trend for APIs on the web towards JSON (Twitter, FourSquare, Facebook, Google, etc.). One of the major reasons is that developers (client-side) prefer it for its simplicity:
    *   Representation closely matches most data models (nested lists and maps)
    *   Simple-to-use libraries exist for all major languages/platforms
    *   Don't need a tool chain to work with the data, as is typically needed for XML.

Apparently, the efficiency gains of JSON also matter to the scalability of serving systems.

[DJ - I can't argue against these listed pros for JSON, especially when you're dealing with a lot of data (like Twitter, FourSquare, Facebook and Google does). But I'm assuming that PAWS messages will not be exchanged nearly as often as the applications mentioned above. But again, I know JSON is more efficient, can't argue with that.]

 *   At the end of the day, it's the data model that matters, rather than the encoding. We (Google) are actually neutral on XML vs JSON, as long as we're clear on what device makers want. It would be good to get feedback from device makers (especially of embedded devices) regarding experiences supporting XML vs JSON.

[DJ - We currently support half a dozen TVDB radio vendors (embedded devices) using XML, non using JSON. XML has not been a burden, and the amount of data that needs to be exchanged between device and database is not that much or exchanged that often.]
On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <[email-masked]<mailto:[email-masked]>> wrote:
Considering of the design of database discovery protocol, the LoST protocol may be used and LoST is based on XML, so I think XML may be preferred.

--Xinpeng Wei

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Rosen, Brian

Sent: Friday, August 17, 2012 9:26 PM
To: Manikkoth Sajeev; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002<tel:%2B918792292002>
Email: [email-masked]<mailto:[email-masked]>
http://www.linkedin.com/in/mksajeev

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

---

From: "Das, Subir" <[email-masked]>
Date: Mon, 20 Aug 2012 21:49:54 +0000

We have a half a dozen or more TVDB radio vendors that use/prefer JSON and we will vote for JSON if we had to pick one.
Also I will copy the following two important points:

     *   Simple-to-use libraries exist for all major languages/platforms
     *   Don't need a tool chain to work with the data, as is typically needed for XML

From: [email-masked] [mailto:[email-masked]] On Behalf Of Don Joslyn
Sent: Monday, August 20, 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc: [email-masked]; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Monday, August 20, 2012 2:56 PM
To: Weixinpeng
Cc: [email-masked]<mailto:[email-masked]>; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 04:41:38 +0000

Now I can't see anymore any willingness to agree on one or the other encoding.
To prevent endless discussions on this topic I'd suggest we move forward with supporting both in the DB and either one in the master device.
Any objections?

-          Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Das, Subir
Sent: Monday, August 20, 2012 2:50 PM
To: Don Joslyn; Vincent Chen; Weixinpeng
Cc: [email-masked]; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Don Joslyn

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

---

From: Don Joslyn <[email-masked]>
Date: Thu, 23 Aug 2012 14:15:06 -0400

Sounds good to me.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, August 21, 2012 12:42 AM
To: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

-          Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Das, Subir

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 23 Aug 2012 12:05:12 -0700

Someone suggested that PAWS define both, and let the vendors decide
which ones to implement.

That makes the most sense for both DB and device vendors.  Markets
will probably drive DB vendors to do both. Device vendors will do
what fits the market segment they're after. Why over-constrain (or
argue when natural selection will take care of it for us?).

B

Sounds good to me.

From:
[email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]

To: [email-masked]

Subject: Re: [paws] XML schema versus JSON, vCard
& iCal

Now I can’t see anymore any willingness to agree
on one or the other encoding.

To prevent endless discussions on this topic I’d
suggest we move forward with supporting both in the DB and
either one in the master device.

Any objections?

-          Gabor

From: [email-masked]
[mailto:[email-masked]]
On Behalf Of ext Das, Subir

Cc: [email-masked];
Manikkoth Sajeev

Subject: Re: [paws] XML schema versus JSON, vCard
& iCal

We have a half a dozen or more TVDB radio vendors
that use/prefer JSON and we will vote for JSON if we had to
pick one.

Also I will copy the following two important
points:

Simple-to-use
libraries exist for all major languages/platforms

Don't need
a tool chain to work with the data, as is typically
needed for XML

From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Don Joslyn

Cc: [email-masked];
Manikkoth Sajeev

Subject: Re: [paws] XML schema versus JSON, vCard
& iCal

Please see my comments below…

Thanks,

Don

From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Vincent Chen

To: Weixinpeng

Cc: [email-masked]; Manikkoth
Sajeev

Subject: Re: [paws] XML schema versus JSON, vCard
& iCal

One of our
goals is to strive to lower the cost and complexity for
device manufacturers. This lowers the barrier for building
a robust ecosystem.

[DJ
- The “cost” and complexity of using XML has not been an
issue for the half dozen TVBD vendors that have already used
XML. Maybe we need to better define “cost”?]

To reduce
complexity and cost for device makers, supporting 1
encoding is better than both, as Brian points out. WiFi
access points that "just work" anywhere in the world
serves as a good model.

[DJ
- I proposed that the databases support both XML and JSON,
devices only need to support one to talk to the database.
Our current database supports XML and JSON, but if I’m
forced to pick only one, then I will vote for XML because
it’s the one that we currently use on all embedded devices.]

There's a trend
for APIs on the web towards JSON (Twitter, FourSquare,
Facebook, Google, etc.). One of the major reasons is that
developers (client-side) prefer it for its simplicity:

Representation
closely matches most data models (nested lists and maps)

Simple-to-use
libraries exist for all major languages/platforms

Don't need a
tool chain to work with the data, as is typically needed
for XML.

Apparently,
the efficiency gains of JSON also matter to the scalability
of serving systems.

[DJ
– I can’t argue against these listed pros for JSON,
especially when you’re dealing with a lot of data (like
Twitter, FourSquare, Facebook and Google does). But I’m
assuming that PAWS messages will not be exchanged nearly as
often as the applications mentioned above. But again, I know
JSON is more efficient, can’t argue with that.]

At the end of
the day, it's the data model that matters, rather than the
encoding. We (Google) are actually neutral on XML vs JSON,
as long as we're clear on what device makers want. It
would be good to get feedback from device makers
(especially of embedded devices) regarding experiences
supporting XML vs JSON.

Don,
can you elaborate on the types of devices that already
support XML?

[DJ - We currently
support half a dozen TVDB radio vendors (embedded devices)
using XML, non using JSON. XML has not been a burden, and
the amount of data that needs to be exchanged between
device and database is not that much or exchanged that
often.]

On Fri, Aug 17, 2012 at 6:06 PM,
Weixinpeng <[email-masked]>
wrote:

Considering of the design of
database discovery protocol, the LoST protocol may
be used and LoST is based on XML, so I think XML may
be preferred.

--Xinpeng Wei

From: [email-masked]
[mailto:[email-masked]] On
Behalf Of Rosen, Brian

To: Manikkoth Sajeev; [email-masked]; [email-masked];
[email-masked]

Cc: [email-masked]

Subject: Re: [paws] XML schema versus
JSON, vCard & iCal

I
don't really care whether we use json or xml
as a matter of protocol design or
implementation, but I am a big fan of reusing
standards rather than defining new ones, and I
would not want to see the choice of json mean
we then decide to roll our own versus using
existing standards based on the idea there is
no json representation of an existing
standard.  So, if choosing json means folks
feel free to ignore existing xml based
standards such as xCard and LoST, then I would
not want to use json.

I
would prefer to not have "both", because of
interoperability complications.  If there is
rough consensus for both, then I would assert
that all servers have to implement both and
the client can implement either.

There
are json validators, so I don't think that is
a big deal.

My
experience in protocol design on the Internet
is that decisions made solely or even largely
because of compactness advantages rarely are
good choices.  If you like json because it is
smaller, then I believe you need a much better
reason.  Binary doesn't work for me, at all.
I have been involved in big binary vs text
wars in protocol design.  Text wins, binary
loses, in my opinion.

Brian
<as individual>

From:
Manikkoth
Sajeev <[email-masked]>

Reply-To: Manikkoth Sajeev <[email-masked]>

To: "[email-masked]"
<[email-masked]>,
"Rosen, Brian" <[email-masked]>,
"[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>

Cc: "[email-masked]"
<[email-masked]>

Subject: Re: [paws] XML schema versus
JSON, vCard & iCal

Hi,

Can it not be
both JSON and XML supported? I would vote
for that. Future implementations may
prefer XML as it is generic, omni
present, easy to understand and
validate. For compactness may
be a  binary xml option
can also work. JSON I think will
necessitate implementation to be native
Java and may not be as friendly with other
implementation languages.

Best
Regards,

Sajeev Manikkoth

Mobile: +918792292002

Email: [email-masked]

From: "[email-masked]"
<[email-masked]>

To: [email-masked];
[email-masked];
[email-masked]

Cc: [email-masked]

Sent: Friday, 17 August 2012,
4:55

Subject: Re: [paws] XML
schema versus JSON, vCard & iCal

We have not heard any objections for
using JSON encoding instead of XML.

Therefore, let's go for JSON, and close
this thread.

- Gabor

-----Original Message-----

From: [email-masked]
[mailto:[email-masked]]
On Behalf Of ext Rosen, Brian

Cc: [email-masked]'

Subject: Re: [paws] XML schema versus
JSON, vCard & iCal

json is okay with me.

I'd prefer an ISO time stamp rather than
a time in seconds since epoch.  It's
very easy to parse, and its simpler to
use and debug.  Don't care a whole lot
about that

Brian <as individual>

-----Original Message-----

Sent:    Monday, August 13, 2012 06:04
PM Eastern Standard Time

To:    Peter Stanforth

Cc:    Rosen, Brian; Teco Boot; Benjamin
A.Rolfe; [email-masked]

Subject:    Re: [paws] XML schema versus
JSON, vCard & iCal

XML vs JSON

Between XML and JSON, JSON messages are
more compact and easier to process
(parsing, synthesis). As clarification,
JSON does not require JavaScript or a
Browser. It is a text-based
representation of data that is language
independent, yet well-matched to all
major languages. JSON-handling libraries
exist for numerous languages (see of http://json.org/)
and seem to be reasonably light weight.

Timestamps

As for timestamp specifications, should
we consider just using seconds since the
UNIX Epoch (1970-01-01T00:00:00Z)? This
would eliminate the need for
datetime-string parsing on devices,
assuming devices already have native
libraries that provide time in this
format. Is that a valid assumption? Of
course, this is less human-readable....

On Mon, Aug 13, 2012 at 6:49 AM, Peter
Stanforth <[email-masked]>
wrote:

Whenever we built mobile devices we
never dealt with IETF, in our sensor

days even an IP stack was a
challenge,so I would defer to the device
guys

on that one.

On MonAug/13/12 Mon Aug 13, 9:30 AM,
"Rosen, Brian"

<[email-masked]>

>implementation on small devices
is a poor trade off.  I am not
advocating

>We should not assume that all
Masters are attached to utility power so
we

>On SatAug/11/12 Sat Aug 11, 5:30
AM, "Teco Boot" <[email-masked]>
wrote:

>>> Compactness of messages
is important, but it is also important
(to me

>>>at least) to be
realizable in an implementation with
limited resources,

>>>applications.  A lot of
these devices could use IP all the end
to end,

>>>but may have a very
compact, simple stack and applications
(i.e.  no

>>>browser).  Is JSON
typically implemented when there is no
browser?

>>>Would it be hard to do
in a resource constrained device (i.e.
where we

>>In use cases and
requirements document, there are no
requirements for

>>protocol performance. I
guess OS/IP/TCP/TLS code size supersedes
needs

>>Same for timing: TCP/TLS
connection setup will take more than the
PAWS

>>message exchange, I think.
This may be of importance when using
satcom

>>performance is not our
primary concern. But as always, it is
good to keep

>>>> We had a discussion
on XML vs. JSON. I prefer the one with
most

>>>> On vCard and JSON:
what is the status of "A JavaScript
Object Notation

>>>> On valid times: can
we use same format as certificates? They
have

>>>>similar simple
requirements: valid notBefore&
notAfter.

paws mailing list

[email-masked]

--

-vince

paws mailing list

[email-masked]

paws mailing list

[email-masked]

--

-vince

---

From: Don Joslyn <[email-masked]>
Date: Thu, 23 Aug 2012 15:11:17 -0400

Hi Ben,
That was my original suggestion, and I still think it makes the most sense.
Thanks for supporting the proposal.
Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Benjamin A. Rolfe
Sent: Thursday, August 23, 2012 3:05 PM
To: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Someone suggested that PAWS define both, and let the vendors decide which ones to implement.
That makes the most sense for both DB and device vendors.  Markets will probably drive DB vendors to do both. Device vendors will do what fits the market segment they're after. Why over-constrain (or argue when natural selection will take care of it for us?).
B

Sounds good to me.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, August 21, 2012 12:42 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 23 Aug 2012 15:43:49 -0400

One of my favorite IETF expressions is "There are no protocol police".  We apply that in lots of ways, but one of them is that if you don't implement what the document says, you may not get interoperability with other implementations.  On the other hand, the whole point of a protocol document like ours is that two independent implementations who both follow the document will interwork.  If that wasn't true, why do you need a standard?

If you say "either" to both ends, then you don't get interoperability.

By your argument, we should stop working, and the product managers will figure it out using proprietary protocols.  The market will decide.

So, I feel strongly that if one end is "either", the other end must be "both".  It's also acceptable to say both ends implement one choice and the other is optional at both ends.  Here, I think it's server does both and client does either.

It's always possible to build an implementation of a server that only does one: there are no protocol police.

Brian <as individual>

On Aug 23, 2012, at 3:11 PM, Don Joslyn <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ben,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Benjamin A. Rolfe
Sent: Thursday, August 23, 2012 3:05 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Sounds good to me.

Now I can’t see anymore any willingness to agree on one or the other encoding.
To prevent endless discussions on this topic I’d suggest we move forward with supporting both in the DB and either one in the master device.
Any objections?

Gabor

[DJ - The “cost” and complexity of using XML has not been an issue for the half dozen TVBD vendors that have already used XML. Maybe we need to better define “cost”?]

[DJ - I proposed that the databases support both XML and JSON, devices only need to support one to talk to the database. Our current database supports XML and JSON, but if I’m forced to pick only one, then I will vote for XML because it’s the one that we currently use on all embedded devices.]

[DJ – I can’t argue against these listed pros for JSON, especially when you’re dealing with a lot of data (like Twitter, FourSquare, Facebook and Google does). But I’m assuming that PAWS messages will not be exchanged nearly as often as the applications mentioned above. But again, I know JSON is more efficient, can’t argue with that.]

--Xinpeng Wei

Brian <as individual>

Hi,

Can it not be both JSON and XML supported? I would vote for that. Future implementations may prefer XML as it is generic, omni present, easy to understand and validate. For compactness may be a  binary xml optioncan also work. JSON I think will necessitate implementation to be native Java and may not be as friendly with other implementation languages.

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

---

From: Peter McCann <[email-masked]>
Date: Thu, 23 Aug 2012 19:44:06 +0000

We should be defining requirements that lead to interoperable implementations.

If we specify both encodings, but allow both the DB and the master device to
implement only one, there will be instances of master device/database pairs
that won't interoperate.

In my opinion, we should standardize on a single encoding.  Failing that, 
we should require the DB to implement both and allow the master device to
choose one.  This will achieve our goal of interoperable implementations.

-Pete

Don Joslyn wrote:
> will probably drive DB vendors to do both. Device vendors will do what 
> fits the market segment they're after. Why over-constrain (or argue 
> when natural selection will take care of it for us?).
> B
> 
> 
> 
> Sounds good to me.
> 
> 
> 
> To prevent endless discussions on this topic I'd suggest we move 
> forward with supporting both in the DB and either one in the master device.
> 
> Any objections?
> 
> 
> 
> Gabor
> 
> 
> 
> 
> 
> We have a half a dozen or more TVDB radio vendors that use/prefer JSON 
> and we will vote for JSON if we had to pick one.
> 
> *	One of our goals is to strive to lower the cost and complexity
> for device manufacturers. This lowers the barrier for building a 
> robust ecosystem.
> 
> [DJ - The "cost" and complexity of using XML has not been an issue for 
> the half dozen TVBD vendors that have already used XML. Maybe we need 
> to better define "cost"?]
> 
> *	To reduce complexity and cost for device makers, supporting 1
> encoding is better than both, as Brian points out. WiFi access points 
> that "just work" anywhere in the world serves as a good model.
> 
> [DJ - I proposed that the databases support both XML and JSON, devices 
> only need to support one to talk to the database. Our current database 
> supports XML and JSON, but if I'm forced to pick only one, then I will 
> vote for XML because it's the one that we currently use on all 
> embedded devices.]
> 
> *	There's a trend for APIs on the web towards JSON (Twitter,
> FourSquare, Facebook, Google, etc.). One of the major reasons is that 
> 	*	Representation closely matches most data models (nested lists and
> maps) 	*	Simple-to-use libraries exist for all major languages/platforms
> [DJ - I can't argue against these listed pros for JSON, especially 
> when you're dealing with a lot of data (like Twitter, FourSquare, 
> Facebook and Google does). But I'm assuming that PAWS messages will 
> not be exchanged nearly as often as the applications mentioned above.
> But again, I know JSON is more efficient, can't argue with that.]
> 
> *	At the end of the day, it's the data model that matters, rather
> than the encoding. We (Google) are actually neutral on XML vs JSON, as 
> long as we're clear on what device makers want. It would be good to 
> get feedback from device makers (especially of embedded devices) 
> regarding experiences supporting XML vs JSON.
> 
> 
> 
> [DJ - We currently support half a dozen TVDB radio vendors (embedded
> devices) using XML, non using JSON. XML has not been a burden, and the 
> amount of data that needs to be exchanged between device and database 
> is not that much or exchanged that often.]
> 
> preferred.
> design or implementation, but I am a big fan of reusing standards 
> rather than defining new ones, and I would not want to see the choice 
> of json mean we then decide to roll our own versus using existing 
> standards based on the idea there is no json representation of an 
> existing standard.  So, if choosing json means folks feel free to 
> ignore existing xml based standards such as xCard and LoST, then I 
> would not want to use json.
> 
> 
> 
> complications.  If there is rough consensus for both, then I would 
> assert that all servers have to implement both and the client can 
> implement either.
> 
> 
> 
> My experience in protocol design on the Internet is that decisions 
> made solely or even largely because of compactness advantages rarely 
> are good choices.  If you like json because it is smaller, then I 
> believe you need a much better reason.  Binary doesn't work for me, at 
> all.  I have been involved in big binary vs text wars in protocol 
> design.  Text wins, binary loses, in my opinion.
> 
> 
> 
> Brian <as individual>
> 
> 
> 
> From: Manikkoth Sajeev <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "Rosen, Brian"
> <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Can it not be both JSON and XML supported? I would vote for that. 
> Future implementations may prefer XML as it is generic, omni present, 
> easy to understand and validate. For compactness may be a  binary xml 
> option can also work. JSON I think will necessitate implementation to 
> be native Java and may not be as friendly with other implementation languages.
> 
> 
> 
> Best Regards,
> 
> Sajeev Manikkoth
> Mobile: +918792292002 <tel:%2B918792292002>
> Email: [email-masked]
> From: "[email-masked]" <[email-masked]> To:
> [email-masked]; [email-masked]; [email-masked] Cc:
> [email-masked] Sent: Friday, 17 August 2012, 4:55 Subject: Re: [paws] 
> XML schema versus JSON, vCard & iCal
> 
> 
> It's very easy to parse, and its simpler to use and debug.  Don't care 
> a whole lot about that
> 
> Brian <as individual>
> 
> 
> 
> Between XML and JSON, JSON messages are more compact and easier to 
> process (parsing, synthesis). As clarification, JSON does not require 
> JavaScript or a Browser. It is a text-based representation of data 
> that is language independent, yet well-matched to all major languages.
> JSON- handling libraries exist for numerous languages (see of
> http://json.org/) and seem to be reasonably light weight.
> 
> Timestamps
> 
> since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the 
> need for datetime-string parsing on devices, assuming devices already 
> have native libraries that provide time in this format. Is that a 
> valid assumption? Of course, this is less human-readable....
> 
> 
>     Whenever we built mobile devices we never dealt with IETF, in our
>     sensor days even an IP stack was a challenge,so I would defer to the
>     device guys on that one.
>     
>> Our experience in the IETF over many years is that economizing 
>> message size and compromising utility and security in search of 
>> efficiency of implementation on small devices is a poor trade off.  I 
>> am not advocating being wasteful of resources, but I don't think we 
>> should seriously consider the overhead of XML or json to be significant.
>> 
>> Not all masters run over the core network. Some of the Use cases have 
>> a master talking to another OTA We should not assume that all Masters 
>> are attached to utility power so we should be sympathetic to 
>> processing energy use also.
>> 
>> On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot"
> <[email-masked]>
> wrote:
>> 
>>> 
>>>> Compactness of messages is important, but it is also important (to 
>>>> me at least) to be realizable in an implementation with limited 
>>>> resources, such as embedded devices in what are now popularly 
>>>> called "M2M" applications.  A lot of these devices could use IP all 
>>>> the end to end, but may have a very compact, simple stack and 
>>>> applications (i.e. no browser).  Is JSON typically implemented when 
>>>> there is no browser? Would it be hard to do in a resource 
>>>> constrained device (i.e. where we talk about memory size in Kilo-bytes still).
>>> 
>>> In use cases and requirements document, there are no requirements 
>>> for protocol performance. I guess OS/IP/TCP/TLS code size supersedes 
>>> needs for JSON or XML.
>>> 
>>> Same for timing: TCP/TLS connection setup will take more than the 
>>> PAWS message exchange, I think. This may be of importance when using 
>>> satcom links.
>>> 
>>> performance is not our primary concern. But as always, it is good to 
>>> keep an eye on efficiency.
>>> 
>>> Teco
>>> 
>>>> Thanks
>>>> Ben
>>>> 
>>>> 
>>>>> On vCard and JSON: what is the status of "A JavaScript Object 
>>>>> Notation (JSON) Representation for vCard"?

---

From: Robert Smith <[email-masked]>
Date: Thu, 23 Aug 2012 14:57:39 -0600

In my experience with the IETF at the final levels of RFC acceptance 
they reject duplicate implementations of objects or protocols. We tried 
that with CALSCH, (xml and iCal/vCard format).

They rejected it in both formats. We had to pick only one. In a separate 
draft that never went
to RFC status we proposed a translation guide (iCal data translation 
to/from XML). However
only one could be the 'standard' format.

I mostly just follow this WG. I would suggest that the WG leads check 
with the IETF to make sure that they will accept a specification that 
has 2 formats for the same data.

-

---

From: <[email-masked]>
Date: Thu, 23 Aug 2012 21:43:31 +0000

I agree with Brian.
There needs to be a default mandatory to implement option in order to achieve interoperability.
And this applies to the device and database side of the protocol.

-Raj

From: "<ext Rosen>", "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 23, 2012 2:43 PM
To: Don Joslyn <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Brian <as individual>

Hi Ben,

Sounds good to me.

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

---

From: Don Joslyn <[email-masked]>
Date: Fri, 24 Aug 2012 10:51:59 -0400

It appears that we have a growing consensus that the database must support both formats while allowing the device to support either format (or both). I agree with this decision. As Gabor originally suggested, let's move forward with supporting both in the DB and either one in the master device.

Regards, Don

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, August 23, 2012 5:44 PM
To: [email-masked]; Don Joslyn
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

I agree with Brian.

-Raj

Brian <as individual>

Hi Ben,

Sounds good to me.

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 24 Aug 2012 11:16:14 -0400

Brian is right .. sorry but the rest of you are wrong. J 

This is why you have MUST and SHOULD in RFC 2119.  

This BTW is a classic argument in IETF terms .. but the argument "let the
market decide" only holds so much validity.  You actually have to choose
SOMETHING to create a baseline of interoperability.

A virtually identical argument  is now playing out in discussions of
mandatory audio and codec implementations for WEBRTC like things.

IMHO XML MUST anything else defined SHOULD, but MUST on XML and JSON could
work as well. It just leads to a level of complexity in implementations. 

End of argument you now can go back to your regularly schedule programming.
J 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, August 23, 2012 5:44 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

I agree with Brian.

There needs to be a default mandatory to implement option in order to
achieve interoperability. 

-Raj

From: "<ext Rosen>", "[email-masked]" <[email-masked]>
Date: Thursday, August 23, 2012 2:43 PM
To: Don Joslyn <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

One of my favorite IETF expressions is "There are no protocol police".  We
apply that in lots of ways, but one of them is that if you don't implement
what the document says, you may not get interoperability with other
implementations.  On the other hand, the whole point of a protocol document
like ours is that two independent implementations who both follow the
document will interwork.  If that wasn't true, why do you need a standard? 

By your argument, we should stop working, and the product managers will
figure it out using proprietary protocols.  The market will decide.

So, I feel strongly that if one end is "either", the other end must be
"both".  It's also acceptable to say both ends implement one choice and the
other is optional at both ends.  Here, I think it's server does both and
client does either. 

It's always possible to build an implementation of a server that only does
one: there are no protocol police.

Brian <as individual>

 

On Aug 23, 2012, at 3:11 PM, Don Joslyn <[email-masked]> wrote:

Hi Ben,

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Benjamin A. Rolfe
Sent: Thursday, August 23, 2012 3:05 PM
To: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Someone suggested that PAWS define both, and let the vendors decide which
ones to implement.
That makes the most sense for both DB and device vendors.  Markets will
probably drive DB vendors to do both. Device vendors will do what fits the
market segment they're after. Why over-constrain (or argue when natural
selection will take care of it for us?).
B

Sounds good to me.

From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf Of
<mailto:[email-masked]> [email-masked]
Sent: Tuesday, August 21, 2012 12:42 AM
To:  <mailto:[email-masked]> [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Now I can't see anymore any willingness to agree on one or the other
encoding.

To prevent endless discussions on this topic I'd suggest we move forward
with supporting both in the DB and either one in the master device.

Any objections?

Gabor

From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf Of
ext Das, Subir
Sent: Monday, August 20, 2012 2:50 PM
To: Don Joslyn; Vincent Chen; Weixinpeng
Cc:  <mailto:[email-masked]> [email-masked]; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

We have a half a dozen or more TVDB radio vendors that use/prefer JSON and
we will vote for JSON if we had to pick one.

*	Simple-to-use libraries exist for all major languages/platforms
*	Don't need a tool chain to work with the data, as is typically
needed for XML

From:  <mailto:[email-masked]> [email-masked]
<mailto:[mailto:[email-masked]]> [mailto:[email-masked]] On
Behalf Of Don Joslyn
Sent: Monday, August 20, 2012 4:54 PM
To: Vincent Chen; Weixinpeng
Cc:  <mailto:[email-masked]> [email-masked]; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Please see my comments below.

Thanks,

Don

From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf Of
Vincent Chen
Sent: Monday, August 20, 2012 2:56 PM
To: Weixinpeng
Cc:  <mailto:[email-masked]> [email-masked]; Manikkoth Sajeev
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

*	One of our goals is to strive to lower the cost and complexity for
device manufacturers. This lowers the barrier for building a robust
ecosystem.

[DJ - The "cost" and complexity of using XML has not been an issue for the
half dozen TVBD vendors that have already used XML. Maybe we need to better
define "cost"?]

*	To reduce complexity and cost for device makers, supporting 1
encoding is better than both, as Brian points out. WiFi access points that
"just work" anywhere in the world serves as a good model.

[DJ - I proposed that the databases support both XML and JSON, devices only
need to support one to talk to the database. Our current database supports
XML and JSON, but if I'm forced to pick only one, then I will vote for XML
because it's the one that we currently use on all embedded devices.]

*	Representation closely matches most data models (nested lists and
maps)
*	Simple-to-use libraries exist for all major languages/platforms
*	Don't need a tool chain to work with the data, as is typically
needed for XML.

[DJ - I can't argue against these listed pros for JSON, especially when
you're dealing with a lot of data (like Twitter, FourSquare, Facebook and
Google does). But I'm assuming that PAWS messages will not be exchanged
nearly as often as the applications mentioned above. But again, I know JSON
is more efficient, can't argue with that.]

*	At the end of the day, it's the data model that matters, rather than
the encoding. We (Google) are actually neutral on XML vs JSON, as long as
we're clear on what device makers want. It would be good to get feedback
from device makers (especially of embedded devices) regarding experiences
supporting XML vs JSON.

[DJ - We currently support half a dozen TVDB radio vendors (embedded
devices) using XML, non using JSON. XML has not been a burden, and the
amount of data that needs to be exchanged between device and database is not
that much or exchanged that often.]

On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng < <mailto:[email-masked]>
[email-masked]> wrote:

Considering of the design of database discovery protocol, the LoST protocol
may be used and LoST is based on XML, so I think XML may be preferred.

--Xinpeng Wei

From:  <mailto:[email-masked]> [email-masked] [mailto:
<mailto:[email-masked]> [email-masked]] On Behalf Of Rosen,
Brian

To: Manikkoth Sajeev;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]

Cc:  <mailto:[email-masked]> [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

such as xCard and LoST, then I would not want to use json.

Brian <as individual>

From: Manikkoth Sajeev < <mailto:[email-masked]> [email-masked]>
Reply-To: Manikkoth Sajeev < <mailto:[email-masked]> [email-masked]>
Date: Thu, 16 Aug 2012 22:37:38 -0400
To: " <mailto:[email-masked]> [email-masked]" <
<mailto:[email-masked]> [email-masked]>, "Rosen, Brian" <
<mailto:[email-masked]> [email-masked]>, "
<mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]>
[email-masked]>, " <mailto:[email-masked]>
[email-masked]" < <mailto:[email-masked]>
[email-masked]>
Cc: " <mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]>
[email-masked]>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Hi,

Can it not be both JSON and XML supported? I would vote for that. Future
implementations may prefer XML as it is generic, omni present, easy to
understand and validate. For compactness may be a  binary xml optioncan also
work. JSON I think will necessitate implementation to be native Java and may
not be as friendly with other implementation languages.

Best Regards,

Sajeev Manikkoth
Mobile:  <tel:%2B918792292002> +918792292002
Email:  <mailto:[email-masked]> [email-masked]
 <http://www.linkedin.com/in/mksajeev> http://www.linkedin.com/in/mksajeev

From: " <mailto:[email-masked]> [email-masked]" <
<mailto:[email-masked]> [email-masked]>
To:  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked] 
Cc:  <mailto:[email-masked]> [email-masked] 
Sent: Friday, 17 August 2012, 4:55
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

- Gabor

-----Original Message-----
From:  <mailto:[email-masked]> [email-masked] [mailto:
<mailto:[email-masked]> [email-masked]] On Behalf Of ext
Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: ' <mailto:[email-masked]> [email-masked]'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.  

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto: <mailto:[email-masked]> [email-masked]]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe;  <mailto:[email-masked]>
[email-masked]

XML vs JSON

libraries exist for numerous languages (see of  <http://json.org/>

Timestamps

As for timestamp specifications, should we consider just using seconds since
the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for
datetime-string parsing on devices, assuming devices already have native
libraries that provide time in this format. Is that a valid assumption? Of
course, this is less human-readable....

On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth <
<mailto:[email-masked]> [email-masked]> wrote:

    Whenever we built mobile devices we never dealt with IETF, in our sensor
    days even an IP stack was a challenge,so I would defer to the device
guys
    on that one.

    < <mailto:[email-masked]> [email-masked]> wrote:
    
    >From:  Peter Stanforth [mailto: <mailto:[email-masked]>
[email-masked]]
    >Cc:     <mailto:[email-masked]> [email-masked]
    >On SatAug/11/12 Sat Aug 11, 5:30 AM, "Teco Boot" <
    >>> Compactness of messages is important, but it is also important (to
me
    >>performance is not our primary concern. But as always, it is good to
keep
    >>>> On vCard and JSON: what is the status of "A JavaScript Object
Notation
    >>>>  <http://tools.ietf.org/html/draft-bhat-vcarddav-json-00>
    >>>>  <http://tools.ietf.org/html/rfc3280#section-4.1.2.5>
    >>>>  <mailto:[email-masked]> [email-masked]
    >>>>  <https://www.ietf.org/mailman/listinfo/paws>
    >>>  <mailto:[email-masked]> [email-masked]
    >>>  <https://www.ietf.org/mailman/listinfo/paws>
    >> <mailto:[email-masked]> [email-masked]
    >> <https://www.ietf.org/mailman/listinfo/paws>
    > <mailto:[email-masked]> [email-masked]
    > <https://www.ietf.org/mailman/listinfo/paws>
    
    _______________________________________________
    paws mailing list
     <mailto:[email-masked]> [email-masked]
     <https://www.ietf.org/mailman/listinfo/paws>
https://www.ietf.org/mailman/listinfo/paws

-- 
-vince

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

-- 
-vince

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

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 24 Aug 2012 09:57:47 -0700

Apparently I was unclear.  I certainly an capable of being wrong as
I practice often, but in this case it is quite unlikely :-).

You do not need to choose only one form to achieve
interoperability.   If you have two, let the device implementer
figure out which is best for their particular device requirements
and trade-offs.  This is *preferable* from my perspective.

If you provide more than one form in the database, devices using the
database need some means for figuring out which are available. It
can't use it if it doesn't no about it. This is an observations, not
an argument ;-).

It is my *opinion* at the  moment that if you provide options, to
make those useful you need to provide  a protocol by which devices
can discover what options the database supports.  If you have such a
mechanism and all devices use it (a  bootstrap protocol), everything
else could be options.  This requires additional functions in both
database and device implementations.

If on the other hand the device can "just know" that the database
has two forms available, it won't need to dynamically figure it out.
The device implementer has options and simplicity, so I like it.

Since I am focused on the TVWS devices that need access to the
database, and not a database implementer, shifting burden onto the
database implementer (not me) to reduce the burden on the device
implementer (me) is preferred from my perspective.  The database
implementer may have another perspective.  Should I point out that
there will be a lot more devices than databases?  That might sound
like an argument, though, so I won't....:-j

Ben

Brian is right .. sorry but the rest of you are
wrong. J

This BTW is a classic argument in IETF terms ..
but the argument “let the market decide” only holds so much
validity.  You actually have to choose SOMETHING to create a
baseline of interoperability.

A virtually identical argument  is now playing
out in discussions of mandatory audio and codec
implementations for WEBRTC like things.

IMHO XML MUST anything else defined SHOULD, but
MUST on XML and JSON could work as well. It just leads to a
level of complexity in implementations.

End of argument you now can go back to your
regularly schedule programming. J

From:
[email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]

To: [email-masked];
[email-masked]

Cc: [email-masked]

I agree with Brian.

There needs to be a default mandatory to
implement option in order to achieve interoperability.

And this applies to the device and database
side of the protocol.

-Raj

From: "<ext
Rosen>", "[email-masked]"
<[email-masked]>

One of my favorite IETF expressions is
"There are no protocol police".  We apply that in lots
of ways, but one of them is that if you don't implement
what the document says, you may not get interoperability
with other implementations.  On the other hand, the
whole point of a protocol document like ours is that two
independent implementations who both follow the document
will interwork.  If that wasn't true, why do you need a
standard?

If you say "either" to both ends, then you
don't get interoperability.

By your argument, we should stop working, and
the product managers will figure it out using
proprietary protocols.  The market will decide.

So, I feel strongly that if one end is
"either", the other end must be "both".  It's also
acceptable to say both ends implement one choice and
the other is optional at both ends.  Here, I think
it's server does both and client does either.

It's always possible to build an
implementation of a server that only does one: there
are no protocol police.

Brian <as individual>

On Aug 23, 2012, at 3:11 PM, Don
Joslyn <[email-masked]>
wrote:

Hi Ben,

That was my original
suggestion, and I still think it makes the
most sense.

Thanks for
supporting the proposal.

Don

Behalf Of Benjamin
A. Rolfe

Sent: Thursday,
August 23, 2012 3:05 PM

To: [email-masked]

Subject: Re:
[paws] XML schema versus JSON, vCard &
iCal

Someone
suggested that PAWS define both, and let the
vendors decide which ones to implement.

That makes the most sense for both DB and
device vendors.  Markets will probably drive
DB vendors to do both. Device vendors will do
what fits the market segment they're after.
Why over-constrain (or argue when natural
selection will take care of it for us?).

B

Sounds good to me.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]

Sent: Tuesday,
August 21, 2012 12:42 AM

To: [email-masked]

Subject: Re:
[paws] XML schema versus JSON, vCard &
iCal

Now I can’t see anymore any
willingness to agree on one or the other
encoding.

To prevent endless discussions
on this topic I’d suggest we move forward with
supporting both in the DB and either one in
the master device.

Any objections?

Gabor

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext
Das, Subir

Sent: Monday,
August 20, 2012 2:50 PM

To: Don
Joslyn; Vincent Chen; Weixinpeng

Cc: [email-masked];
Manikkoth Sajeev

Subject: Re:
[paws] XML schema versus JSON, vCard &
iCal

We have a half a dozen or more
TVDB radio vendors that use/prefer JSON and we
will vote for JSON if we had to pick one.

Also I will copy the following
two important points:

Simple-to-use
libraries exist for all major
languages/platforms

Don't
need a tool chain to work with the data, as
is typically needed for XML

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Don
Joslyn

Sent: Monday,
August 20, 2012 4:54 PM

To: Vincent
Chen; Weixinpeng

Cc: [email-masked];
Manikkoth Sajeev

Subject: Re:
[paws] XML schema versus JSON, vCard &
iCal

Thanks,

Don

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vincent
Chen

Sent: Monday,
August 20, 2012 2:56 PM

To: Weixinpeng

Cc: [email-masked];
Manikkoth Sajeev

Subject: Re:
[paws] XML schema versus JSON, vCard &
iCal

One
of our goals is to strive to lower the cost
and complexity for device manufacturers. This
lowers the barrier for building a robust
ecosystem.

[DJ - The “cost” and complexity of
using XML has not been an issue for the half
dozen TVBD vendors that have already used XML.
Maybe we need to better define “cost”?]

To
reduce complexity and cost for device makers,
supporting 1 encoding is better than both, as
Brian points out. WiFi access points that
"just work" anywhere in the world serves as a
good model.

[DJ - I proposed that the databases
support both XML and JSON, devices only need
to support one to talk to the database. Our
current database supports XML and JSON, but if
I’m forced to pick only one, then I will vote
for XML because it’s the one that we currently
use on all embedded devices.]

There's
a trend for APIs on the web towards JSON
(Twitter, FourSquare, Facebook, Google, etc.).
One of the major reasons is that developers
(client-side) prefer it for its simplicity:

Representation
closely matches most data models (nested
lists and maps)

Simple-to-use
libraries exist for all major
languages/platforms

Don't
need a tool chain to work with the data, as
is typically needed for XML.

Apparently, the efficiency gains of JSON
also matter to the scalability of serving
systems.

[DJ – I can’t argue against these
listed pros for JSON, especially when you’re
dealing with a lot of data (like Twitter,
FourSquare, Facebook and Google does). But I’m
assuming that PAWS messages will not be
exchanged nearly as often as the applications
mentioned above. But again, I know JSON is
more efficient, can’t argue with that.]

At
the end of the day, it's the data model that
matters, rather than the encoding. We (Google)
are actually neutral on XML vs JSON, as long
as we're clear on what device makers want. It
would be good to get feedback from device
makers (especially of embedded devices)
regarding experiences supporting XML vs JSON.

Don, can you elaborate on the types of
devices that already support XML?

[DJ - We
currently support half a dozen TVDB radio
vendors (embedded devices) using XML, non
using JSON. XML has not been a burden, and the
amount of data that needs to be exchanged
between device and database is not that much
or exchanged that often.]

Considering of
the design of database discovery
protocol, the LoST protocol may be used
and LoST is based on XML, so I think XML
may be preferred.

--Xinpeng Wei

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Rosen,
Brian

Sent: Friday,
August 17, 2012 9:26 PM

To: Manikkoth
Sajeev; [email-masked]; [email-masked]; [email-masked]

Cc: [email-masked]

Subject: Re:
[paws] XML schema versus JSON,
vCard & iCal

I don't really care
whether we use json or xml as a
matter of protocol design or
implementation, but I am a big fan
of reusing standards rather than
defining new ones, and I would not
want to see the choice of json mean
we then decide to roll our own
versus using existing standards
based on the idea there is no json
representation of an existing
standard.  So, if choosing json
means folks feel free to ignore
existing xml based standards such as
xCard and LoST, then I would not
want to use json.

I would prefer to not
have "both", because of
interoperability complications.  If
there is rough consensus for both,
then I would assert that all servers
have to implement both and the
client can implement either.

There are json
validators, so I don't think that is
a big deal.

My experience in
protocol design on the Internet is
that decisions made solely or even
largely because of compactness
advantages rarely are good choices.
If you like json because it is
smaller, then I believe you need a
much better reason.  Binary doesn't
work for me, at all.  I have been
involved in big binary vs text wars
in protocol design.  Text wins,
binary loses, in my opinion.

Brian <as
individual>

Reply-To: Manikkoth

Date: Thu,
16 Aug 2012 22:37:38 -0400

To: "[email-masked]"
<[email-masked]>,
"Rosen, Brian" <[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]"
<[email-masked]>

Cc: "[email-masked]"
<[email-masked]>

Subject: Re:
[paws] XML schema versus JSON, vCard
& iCal

Hi,

Can it not
be both JSON and XML supported? I
would vote for that. Future
implementations may prefer XML
as it is generic, omni present,
easy to understand and validate. For
compactness may be a  binary
xml optioncan also
work. JSON I think will
necessitate implementation to be
native Java and may not be as
friendly with other implementation
languages.

Best
Regards,

Sajeev
Manikkoth

Mobile: +918792292002

Email: [email-masked]

Cc: [email-masked]

Sent: Friday,
17 August 2012, 4:55

Subject: Re:
[paws] XML schema versus JSON,
vCard & iCal

Therefore, let's go for JSON, and
close this thread.

- Gabor

-----Original Message-----

From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Rosen, Brian

Sent: Monday, August 13, 2012 3:14
PM

To: 'Vincent Chen'; 'Peter
Stanforth'

Cc: [email-masked]'

Subject: Re: [paws] XML schema
versus JSON, vCard & iCal

json is okay with me.

I'd prefer an ISO time stamp rather
than a time in seconds since epoch.
It's very easy to parse, and its
simpler to use and debug.  Don't
care a whole lot about that

Brian <as individual>

-----Original Message-----

Sent:    Monday, August 13, 2012
06:04 PM Eastern Standard Time

To:    Peter Stanforth

Cc:    Rosen, Brian; Teco Boot;
Benjamin A.Rolfe; [email-masked]

Subject:    Re: [paws] XML schema
versus JSON, vCard & iCal

XML vs JSON

Between XML and JSON, JSON messages
are more compact and easier to
process (parsing, synthesis). As
clarification, JSON does not require
JavaScript or a Browser. It is a
text-based representation of data
that is language independent, yet
well-matched to all major languages.
JSON-handling libraries exist for
numerous languages (see of http://json.org/)
and seem to be reasonably light
weight.

Timestamps

As for timestamp specifications,
should we consider just using
seconds since the UNIX Epoch
(1970-01-01T00:00:00Z)? This would
eliminate the need for
datetime-string parsing on devices,
assuming devices already have native
libraries that provide time in this
format. Is that a valid assumption?
Of course, this is less
human-readable....

On Mon, Aug 13, 2012 at 6:49 AM,
Peter Stanforth <[email-masked]>
wrote:

Whenever we built mobile devices
we never dealt with IETF, in our
sensor

days even an IP stack was a
challenge,so I would defer to the
device guys

on that one.

On MonAug/13/12 Mon Aug 13, 9:30
AM, "Rosen, Brian"

>Our experience in the IETF
over many years is that economizing
message

>size and compromising
utility and security in search of
efficiency of

>implementation on small
devices is a poor trade off.  I am
not advocating

>being wasteful of resources,
but I don't think we should
seriously

>Assuming a json library can
be loaded on a small device is
reasonable.

>We should not assume that
all Masters are attached to utility
power so we

>On SatAug/11/12 Sat Aug 11,
5:30 AM, "Teco Boot" <[email-masked]>
wrote:

>>Op 10 aug. 2012, om
18:10 heeft Benjamin A. Rolfe het
volgende

>>> Compactness of
messages is important, but it is
also important (to me

>>>such as embedded
devices in what are now popularly
called "M2M"

>>>applications.  A lot
of these devices could use IP all
the end to end,

>>>but may have a very
compact, simple stack and
applications (i.e.  no

>>>browser).  Is JSON
typically implemented when there is
no browser?

>>>Would it be hard to
do in a resource constrained device
(i.e. where we

>>protocol performance. I
guess OS/IP/TCP/TLS code size
supersedes needs

>>Same for timing: TCP/TLS
connection setup will take more than
the PAWS

>>message exchange, I
think. This may be of importance
when using satcom

>>Because PAWS runs
between master and database, over
core network,

>>performance is not our
primary concern. But as always, it
is good to keep

>>>> We had a
discussion on XML vs. JSON. I prefer
the one with most

>>>>compact
messages.

>>>> On vCard and
JSON: what is the status of "A
JavaScript Object Notation

>>>> On valid times:
can we use same format as
certificates? They have

>>>> paws mailing
list

paws mailing list

[email-masked]

--

-vince

paws mailing list

[email-masked]

paws mailing list

[email-masked]

--

-vince

paws mailing list

[email-masked]

paws mailing list

[email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 24 Aug 2012 13:09:33 -0400

There are two ways to achieve interoperability when you have an option.

One is that one end implements both choices and the other end implements one or both.

The other is that both ends implement one specific choice ("MUST implement") and both can optionally implement the other choice.  Only if both ends implement the other choice would that be available.

So, in this case we could do one of the following:
A) Databases implement both XML and JSON, devices implement either
B) Both Databases and devices implement one (say XML) and optionally implement the other (say JSON)

You are advocating for A, Richard was suggesting B.

I don't care, but choice C) Both databases and devices have a choice of what to implement doesn't work for me (or Richard).

Brian

On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe <[email-masked]<mailto:[email-masked]>> wrote:

Apparently I was unclear.  I certainly an capable of being wrong as I practice often, but in this case it is quite unlikely :-).

You do not need to choose only one form to achieve interoperability.   If you have two, let the device implementer figure out which is best for their particular device requirements and trade-offs.  This is *preferable* from my perspective.

If you provide more than one form in the database, devices using the database need some means for figuring out which are available. It can't use it if it doesn't no about it. This is an observations, not an argument ;-).

It is my *opinion* at the  moment that if you provide options, to make those useful you need to provide  a protocol by which devices can discover what options the database supports.  If you have such a mechanism and all devices use it (a  bootstrap protocol), everything else could be options.  This requires additional functions in both database and device implementations.
If on the other hand the device can "just know" that the database has two forms available, it won't need to dynamically figure it out. The device implementer has options and simplicity, so I like it.

Since I am focused on the TVWS devices that need access to the database, and not a database implementer, shifting burden onto the database implementer (not me) to reduce the burden on the device implementer (me) is preferred from my perspective.  The database implementer may have another perspective.  Should I point out that there will be a lot more devices than databases?  That might sound like an argument, though, so I won't....:-j

Ben

Brian is right .. sorry but the rest of you are wrong. :)

This BTW is a classic argument in IETF terms .. but the argument “let the market decide” only holds so much validity.  You actually have to choose SOMETHING to create a baseline of interoperability.

A virtually identical argument  is now playing out in discussions of mandatory audio and codec implementations for WEBRTC like things.

IMHO XML MUST anything else defined SHOULD, but MUST on XML and JSON could work as well. It just leads to a level of complexity in implementations.

End of argument you now can go back to your regularly schedule programming. :)

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, August 23, 2012 5:44 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

I agree with Brian.

-Raj

Brian <as individual>

Hi Ben,

Sounds good to me.

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Fri, 24 Aug 2012 10:38:51 -0700

There are two ways to achieve interoperability when you have an
option.

There are many existence proofs of the third way that I mentioned
below.

802.11 + WiFi provide many options and a means for devices to share
information about what options each supports, without requiring that
any device implement every option.  It works.

That said, I think (A) is the best choice, (B) is not as nice for
me, and (C) is more work than either of the other two.

One is that one end implements both choices and the other end
implements one or both.

The other is that both ends implement one specific choice
("MUST implement") and both can optionally implement the other
choice.  Only if both ends implement the other choice would that
be available.

A) Databases implement both XML and JSON, devices implement
either

B) Both Databases and devices implement one (say XML) and
optionally implement the other (say JSON)

I don't care, but choice C) Both databases and devices have a
choice of what to implement doesn't work for me (or Richard).

Brian

On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe <[email-masked]>
wrote:

Apparently I was
unclear.  I certainly an capable of being wrong as I
practice often, but in this case it is quite unlikely :-).

You do not need to choose only one form to achieve
interoperability.   If you have two, let the device
implementer figure out which is best for their particular
device requirements and trade-offs.  This is *preferable*
from my perspective.

If you provide more than one form in the database, devices
using the database need some means for figuring out which
are available. It can't use it if it doesn't no about it.
This is an observations, not an argument ;-).

It is my *opinion* at the  moment that if you provide
options, to make those useful you need to provide  a
protocol by which devices can discover what options the
database supports.  If you have such a mechanism and all
devices use it (a  bootstrap protocol), everything else
could be options.  This requires additional functions in
both database and device implementations.

If on the other hand the device can "just know" that the
database has two forms available, it won't need to
dynamically figure it out. The device implementer has
options and simplicity, so I like it.

Since I am focused on the TVWS devices that need access to
the database, and not a database implementer, shifting
burden onto the database implementer (not me) to reduce
the burden on the device implementer (me) is preferred
from my perspective.  The database implementer may have
another perspective.  Should I point out that there will
be a lot more devices than databases?  That might sound
like an argument, though, so I won't....:-j

Ben

Brian is right .. sorry but the
rest of you are wrong. J

This is why you have MUST and
SHOULD in RFC 2119.

This BTW is a classic argument
in IETF terms .. but the argument “let the market
decide” only holds so much validity.  You actually
have to choose SOMETHING to create a baseline of
interoperability.

A virtually identical argument
is now playing out in discussions of mandatory
audio and codec implementations for WEBRTC like
things.

IMHO XML MUST anything else
defined SHOULD, but MUST on XML and JSON could
work as well. It just leads to a level of
complexity in implementations.

End of argument you now can go
back to your regularly schedule programming. J

From: [email-masked]
[mailto:[email-masked]]
On Behalf Of [email-masked]

Cc: [email-masked]

I agree with
Brian.

There needs to
be a default mandatory to implement option in
order to achieve interoperability.

And this
applies to the device and database side of the
protocol.

-Raj

From:
"<ext

Cc: "[email-masked]"
<[email-masked]>

One
of my favorite IETF expressions is "There are
no protocol police".  We apply that in lots of
ways, but one of them is that if you don't
implement what the document says, you may not
get interoperability with other
implementations.  On the other hand, the whole
point of a protocol document like ours is that
two independent implementations who both
follow the document will interwork.  If that
wasn't true, why do you need a standard?

If
you say "either" to both ends, then you
don't get interoperability.

By
your argument, we should stop working, and
the product managers will figure it out
using proprietary protocols.  The market
will decide.

So,
I feel strongly that if one end is "either",
the other end must be "both".  It's also
acceptable to say both ends implement one
choice and the other is optional at both
ends.  Here, I think it's server does both
and client does either.

It's
always possible to build an implementation
of a server that only does one: there are no
protocol police.

Brian
<as individual>

On Aug 23, 2012,
at 3:11 PM, Don Joslyn <[email-masked]>

wrote:

Hi Ben,

That was
my original suggestion, and I still
think it makes the most sense.

Thanks for
supporting the proposal.

Don

Behalf Of Benjamin

A. Rolfe

Sent: Thursday,

August 23, 2012 3:05 PM

To: [email-masked]

Subject: Re:

Someone

suggested that PAWS define both, and
let the vendors decide which ones to
implement.

That makes the most sense for both
DB and device vendors.  Markets will
probably drive DB vendors to do
both. Device vendors will do what
fits the market segment they're
after. Why over-constrain (or argue
when natural selection will take
care of it for us?).

B

Sounds good to
me.

Sent: Tuesday,

August 21, 2012 12:42 AM

To: [email-masked]

Subject: Re:

Now I can’t see
anymore any willingness to agree on
one or the other encoding.

To prevent
endless discussions on this topic
I’d suggest we move forward with
supporting both in the DB and either
one in the master device.

Any objections?

Gabor

Behalf Of ext

Das, Subir

Sent: Monday,

August 20, 2012 2:50 PM

To: Don

Cc: [email-masked];
Manikkoth Sajeev

Subject: Re:

We have a half
a dozen or more TVDB radio vendors
that use/prefer JSON and we will
vote for JSON if we had to pick one.

Also I will
copy the following two important
points:

Simple-to-use

Don't

need a tool chain to work with the
data, as is typically needed for
XML

Behalf Of Don

Joslyn

Sent: Monday,

August 20, 2012 4:54 PM

To: Vincent

Chen; Weixinpeng

Cc: [email-masked];
Manikkoth Sajeev

Subject: Re:

Please see my
comments below…

Thanks,

Don

Behalf Of Vincent

Chen

Sent: Monday,

August 20, 2012 2:56 PM

To: Weixinpeng

Cc: [email-masked];
Manikkoth Sajeev

Subject: Re:

One

of our goals is to strive to lower
the cost and complexity for device
manufacturers. This lowers the
barrier for building a robust
ecosystem.

[DJ - The “cost”
and complexity of using XML has not
been an issue for the half dozen
TVBD vendors that have already used
XML. Maybe we need to better define
“cost”?]

To

reduce complexity and cost for
device makers, supporting 1 encoding
is better than both, as Brian points
out. WiFi access points that "just
work" anywhere in the world serves
as a good model.

[DJ - I proposed
that the databases support both XML
and JSON, devices only need to
support one to talk to the database.
Our current database supports XML
and JSON, but if I’m forced to pick
only one, then I will vote for XML
because it’s the one that we
currently use on all embedded
devices.]

There's

a trend for APIs on the web towards
JSON (Twitter, FourSquare, Facebook,
Google, etc.). One of the major
reasons is that developers
(client-side) prefer it for its
simplicity:

Representation

closely matches most data models
(nested lists and maps)

Simple-to-use

Don't

need a tool chain to work with the
data, as is typically needed for
XML.

Apparently, the
efficiency gains of JSON also matter
to the scalability of serving systems.

[DJ – I can’t
argue against these listed pros for
JSON, especially when you’re dealing
with a lot of data (like Twitter,
FourSquare, Facebook and Google
does). But I’m assuming that PAWS
messages will not be exchanged
nearly as often as the applications
mentioned above. But again, I know
JSON is more efficient, can’t argue
with that.]

At

the end of the day, it's the data
model that matters, rather than the
encoding. We (Google) are actually
neutral on XML vs JSON, as long as
we're clear on what device makers
want. It would be good to get
feedback from device makers
(especially of embedded devices)
regarding experiences supporting XML
vs JSON.

Don, can you
elaborate on the types of devices that
already support XML?

[DJ
- We currently support half a dozen
TVDB radio vendors (embedded
devices) using XML, non using JSON.
XML has not been a burden, and the
amount of data that needs to be
exchanged between device and
database is not that much or
exchanged that often.]

On
Fri, Aug 17, 2012 at 6:06 PM,
Weixinpeng <[email-masked]>

wrote:

Considering
of the design of database
discovery protocol, the LoST
protocol may be used and LoST
is based on XML, so I think
XML may be preferred.

--Xinpeng
Wei

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen,

Brian

Sent: Friday,

August 17, 2012 9:26 PM

Cc: [email-masked]

Subject: Re:

[paws] XML schema versus
JSON, vCard & iCal

I
don't really care whether
we use json or xml as a
matter of protocol design
or implementation, but I
am a big fan of reusing
standards rather than
defining new ones, and I
would not want to see the
choice of json mean we
then decide to roll our
own versus using existing
standards based on the
idea there is no json
representation of an
existing standard.  So, if
choosing json means folks
feel free to ignore
existing xml based
standards such as xCard
and LoST, then I would not
want to use json.

I
would prefer to not have
"both", because of
interoperability
complications.  If there
is rough consensus for
both, then I would assert
that all servers have to
implement both and the
client can implement
either.

There
are json validators, so I
don't think that is a big
deal.

My
experience in protocol
design on the Internet is
that decisions made solely
or even largely because of
compactness advantages
rarely are good choices.
If you like json because
it is smaller, then I
believe you need a much
better reason.  Binary
doesn't work for me, at
all.  I have been involved
in big binary vs text wars
in protocol design.  Text
wins, binary loses, in my
opinion.

Brian
<as individual>

From: Manikkoth

Reply-To: Manikkoth

Date: Thu,

"[email-masked]"
<[email-masked]>,

Cc: "[email-masked]"
<[email-masked]>

Subject: Re:

[paws] XML schema versus
JSON, vCard & iCal

Hi,

Can
it not be both JSON and
XML supported? I would
vote for that. Future
implementations may
prefer XML

as it is generic, omni
present, easy to
understand and
validate. For compactness may be a  binary

xml optioncan
also work. JSON I think
will necessitate
implementation to be
native Java and may not
be as friendly with
other implementation
languages.

Best Regards,

Sajeev

Manikkoth

Mobile: +918792292002

Email: [email-masked]

Cc: [email-masked]

Sent: Friday,

17 August 2012, 4:55

Subject: Re:

[paws] XML schema
versus JSON, vCard
& iCal

We have not heard any
objections for using JSON
encoding instead of XML.

Therefore, let's go for
JSON, and close this
thread.

- Gabor

-----Original Message-----

On Behalf Of ext Rosen,
Brian

Sent: Monday, August 13,
2012 3:14 PM

Cc: [email-masked]'

Subject: Re: [paws] XML
schema versus JSON, vCard
& iCal

json is okay with me.

I'd prefer an ISO time
stamp rather than a time
in seconds since epoch.
It's very easy to parse,
and its simpler to use and
debug.  Don't care a whole
lot about that

Brian <as
individual>

-----Original Message-----

From:     Vincent Chen
[mailto:[email-masked]]

Sent:    Monday, August
13, 2012 06:04 PM Eastern
Standard Time

To:    Peter Stanforth

Cc:    Rosen, Brian; Teco
Boot; Benjamin A.Rolfe; [email-masked]

Subject:    Re: [paws] XML
schema versus JSON, vCard
& iCal

XML vs JSON

Between XML and JSON, JSON
messages are more compact
and easier to process
(parsing, synthesis). As
clarification, JSON does
not require JavaScript or
a Browser. It is a
text-based representation
of data that is language
independent, yet
well-matched to all major
languages. JSON-handling
libraries exist for
numerous languages (see of http://json.org/)
and seem to be reasonably
light weight.

Timestamps

As for timestamp
specifications, should we
consider just using
seconds since the UNIX
Epoch
(1970-01-01T00:00:00Z)?
This would eliminate the
need for datetime-string
parsing on devices,
assuming devices already
have native libraries that
provide time in this
format. Is that a valid
assumption? Of course,
this is less
human-readable....

On Mon, Aug 13, 2012 at
6:49 AM, Peter Stanforth

wrote:

Whenever we built
mobile devices we never
dealt with IETF, in our
sensor

days even an IP stack
was a challenge,so I would
defer to the device guys

on that one.

On MonAug/13/12 Mon
Aug 13, 9:30 AM, "Rosen,
Brian"

wrote:

>Our experience in
the IETF over many years
is that economizing
message

>size and
compromising utility and
security in search of
efficiency of

>implementation on
small devices is a poor
trade off.  I am not
advocating

>being wasteful of
resources, but I don't
think we should seriously

>consider the
overhead of XML or json to
be significant.

>Assuming a json
library can be loaded on a
small device is
reasonable.

>Brian (as
individual)

>From:  Peter
Stanforth [mailto:[email-masked]]

>Sent:  Saturday,
August 11, 2012 07:13 AM
Eastern Standard Time

>Subject:      Re:
[paws] XML schema versus
JSON, vCard & iCal

>Some of the Use
cases have a master
talking to another OTA

>We should not
assume that all Masters
are attached to utility
power so we

>should be
sympathetic to processing
energy use also.

>On SatAug/11/12
Sat Aug 11, 5:30 AM, "Teco
Boot" <[email-masked]>

wrote:

>>Op 10 aug.
2012, om 18:10 heeft
Benjamin A. Rolfe het
volgende

Compactness of messages is
important, but it is also
important (to me

>>>at least)
to be realizable in an
implementation with
limited resources,

>>>such as
embedded devices in what
are now popularly called
"M2M"

>>>applications.
A lot of these devices
could use IP all the end
to end,

>>>but may
have a very compact,
simple stack and
applications (i.e.  no

>>>browser).
Is JSON typically
implemented when there is
no browser?

>>>Would it
be hard to do in a
resource constrained
device (i.e. where we

>>>talk about
memory size in Kilo-bytes
still).

>>In use cases
and requirements document,
there are no requirements
for

>>protocol
performance. I guess
OS/IP/TCP/TLS code size
supersedes needs

>>for JSON or
XML.

>>Same for
timing: TCP/TLS connection
setup will take more than
the PAWS

>>message
exchange, I think. This
may be of importance when
using satcom

>>Because PAWS
runs between master and
database, over core
network,

>>performance is
not our primary concern.
But as always, it is good
to keep

>>an eye on
efficiency.

>>>> We
had a discussion on XML
vs. JSON. I prefer the one
with most

messages.

>>>> On
vCard and JSON: what is
the status of "A

>>>> On
valid times: can we use
same format as
certificates? They have

>>>>similar
simple requirements: valid
notBefore&  notAfter.

>>>> paws
mailing list

>>> paws
mailing list

list

paws mailing list

[email-masked]

--

-vince

paws mailing list

[email-masked]

paws mailing list

[email-masked]

--

-vince

paws mailing list

[email-masked]

paws mailing list

[email-masked]

paws mailing list

[email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 24 Aug 2012 13:42:51 -0400

Okay:

So, I implement a database, and I implement XML
You implement a device, and you implement JSON

You query my database (let's not get into how you do that query without deciding XML vs JSON) and discover I implement XML only

What do you do?

Brian

On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" <[email-masked]<mailto:[email-masked]>> wrote:

There are two ways to achieve interoperability when you have an option.
There are many existence proofs of the third way that I mentioned below.
802.11 + WiFi provide many options and a means for devices to share information about what options each supports, without requiring that any device implement every option.  It works.

That said, I think (A) is the best choice, (B) is not as nice for me, and (C) is more work than either of the other two.

Brian

Ben

I agree with Brian.

-Raj

Brian <as individual>

Hi Ben,

Sounds good to me.

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 19:08:31 +0000

WiFi world builds on mandating the implementation (and certification) of a base spec, and a set of optional features. If an optional feature is not supported by one of the peers, they can still talk, but not use that feature. That is basically option B) from Brain's list.

I'd like to suggest that we recognize that option A) and B) are valid options, while option C) is invalid, and we should stop debating it.
I'd also like to add the obvious option D) to the list, which is that both the master devices and DBs support one and the same encoding ;)

Option A) seems to be like a good compromise, and would cut discussions short, with the only caveat that if there is no strong technical argument for supporting and specifying two different encodings, then the iesg may send the document back to the wg to pick one of the two specified. As Robert mentioned in his email, this has happened in the past, so it is likely it would happen again. And frankly, I do not see a strong argument in favor of two different encodings.

Is there anyone who has a technical argument against supporting only one encoding, being that either xml or json?

Most people speak in favor of JSON, because it is compact and more efficient. I went through this thread and I saw 2 objections against picking JSON. One said that JSON requires native Java, which is wrong, the other objection gave no real reason. So I am wondering if there is really any valid technical reason against using JSON only?

-          Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Rosen, Brian
Sent: Friday, August 24, 2012 10:43 AM
To: Benjamin A. Rolfe
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Okay:

What do you do?

Brian

Brian

Ben

This BTW is a classic argument in IETF terms .. but the argument "let the market decide" only holds so much validity.  You actually have to choose SOMETHING to create a baseline of interoperability.

I agree with Brian.

-Raj

Brian <as individual>

Hi Ben,

Sounds good to me.

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

paws mailing list

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 24 Aug 2012 15:48:22 -0400

The problem we face with JSON only is the LoST/xCard/... issue.  As long as there is no objection to creating JSON encodings of existing standards in order to use JSON, and no one uses the fact that these encodings don't exist as a reason to roll our own equivalents, I am okay with JSON only.

Brian

On Aug 24, 2012, at 3:08 PM, [email-masked]<mailto:[email-masked]> wrote:

WiFi world builds on mandating the implementation (and certification) of a base spec, and a set of optional features. If an optional feature is not supported by one of the peers, they can still talk, but not use that feature. That is basically option B) from Brain’s list.

I’d like to suggest that we recognize that option A) and B) are valid options, while option C) is invalid, and we should stop debating it.
I’d also like to add the obvious option D) to the list, which is that both the master devices and DBs support one and the same encoding ;)

-          Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Friday, August 24, 2012 10:43 AM
To: Benjamin A. Rolfe
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Okay:

What do you do?

Brian

Brian

Ben

I agree with Brian.

-Raj

Brian <as individual>

Hi Ben,

Sounds good to me.

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

paws mailing list

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 19:51:17 +0000

+1 to Brian's view on using JSON only.

From: "<ext Rosen>", "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 24, 2012 2:48 PM
To: Gabor Bajko <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Brian

-          Gabor

Okay:

What do you do?

Brian

Brian

Ben

I agree with Brian.

-Raj

Brian <as individual>

Hi Ben,

Sounds good to me.

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

paws mailing list

---

From: Peter McCann <[email-masked]>
Date: Fri, 24 Aug 2012 21:11:37 +0000

I think you are mis-representing Brian's point of view.  I share his
concern about re-inventing encodings for LoST/xCard.

-Pete

[email-masked] wrote:
> Date: Friday, August 24, 2012 2:48 PM To: Gabor Bajko 
> <[email-masked]> Cc: "[email-masked]" <[email-masked]> Subject: Re:
> [paws] XML schema versus JSON, vCard & iCal
> 
> 
> The problem we face with JSON only is the LoST/xCard/... issue.  As 
> long as there is no objection to creating JSON encodings of existing 
> standards in order to use JSON, and no one uses the fact that these 
> encodings don't exist as a reason to roll our own equivalents, I am 
> okay with JSON only.
> 
> Brian
> 
> On Aug 24, 2012, at 3:08 PM, [email-masked] wrote:
> 
> 
> 	WiFi world builds on mandating the implementation (and
> certification) of a base spec, and a set of optional features. If an 
> optional feature is not supported by one of the peers, they can still 
> talk, but not use that feature. That is basically option B) from 
> Brain's list.
> 
> 	I'd like to suggest that we recognize that option A) and B) are valid 
> options, while option C) is invalid, and we should stop debating it.
> 	I'd also like to add the obvious option D) to the list, which is that 
> both the master devices and DBs support one and the same encoding ;)
> 
> 	Option A) seems to be like a good compromise, and would cut 
> discussions short, with the only caveat that if there is no strong 
> technical argument for supporting and specifying two different 
> encodings, then the iesg may send the document back to the wg to pick 
> one of the two specified. As Robert mentioned in his email, this has 
> happened in the past, so it is likely it would happen again. And 
> frankly, I do not see a strong argument in favor of two different encodings.
> 
> 	Is there anyone who has a technical argument against supporting only 
> one encoding, being that either xml or json?
> 
> 	Most people speak in favor of JSON, because it is compact and more 
> efficient. I went through this thread and I saw 2 objections against 
> picking JSON. One said that JSON requires native Java, which is wrong, 
> the other objection gave no real reason. So I am wondering if there is 
> really any valid technical reason against using JSON only?
> 
> 	-          Gabor
> 
> 
> 	You query my database (let's not get into how you do that query 
> without deciding XML vs JSON) and discover I implement XML only
> 
> 	What do you do?
> 
> 	Brian
> 
> 	On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe"
> <[email-masked]> wrote:
> 
> 
> 
> 
> below. 	802.11 + WiFi provide many options and a means for devices to
> share information about what options each supports, without requiring 
> that any device implement every option.  It works.
> 
> 	That said, I think (A) is the best choice, (B) is not as nice for me, 
> and (C) is more work than either of the other two.
> 
> 
> 
> 
> 	The other is that both ends implement one specific choice ("MUST
> implement") and both can optionally implement the other choice.  Only 
> if both ends implement the other choice would that be available.
> 
> 	I don't care, but choice C) Both databases and devices have a choice 
> of what to implement doesn't work for me (or Richard).
> 
> 	Brian
> 
> 	Apparently I was unclear.  I certainly an capable of being wrong as I 
> interoperability.   If you have two, let the device implementer figure
> out which is best for their particular device requirements and trade- 
> offs.  This is *preferable* from my perspective.
> 
> make those useful you need to provide  a protocol by which devices can 
> discover what options the database supports.  If you have such a 
> 	If on the other hand the device can "just know" that the database has 
> two forms available, it won't need to dynamically figure it out.
> 	This BTW is a classic argument in IETF terms .. but the argument "let 
> the market decide" only holds so much validity.  You actually have to 
> choose SOMETHING to create a baseline of interoperability.
> 
> 	IMHO XML MUST anything else defined SHOULD, but MUST on XML and JSON 
> could work as well. It just leads to a level of complexity in 
> implementations.
> 
> 	End of argument you now can go back to your regularly schedule 
> programming. J
> 
> 
> 	From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]
> 	From: "<ext Rosen>", "[email-masked]"
> <[email-masked]> 	Date: Thursday, August 23, 2012 2:43 PM 	To:
> Don Joslyn <[email-masked]> 	Cc: "[email-masked]"
> <[email-masked]> 	Subject: Re: [paws] XML schema versus JSON, vCard & iCal
> 
> 	One of my favorite IETF expressions is "There are no protocol 
> police".  We apply that in lots of ways, but one of them is that if 
> you don't implement what the document says, you may not get 
> interoperability with other implementations.  On the other hand, the 
> whole point of a protocol document like ours is that two independent 
> implementations who both follow the document will interwork.  If that 
> 	By your argument, we should stop working, and the product managers 
> will figure it out using proprietary protocols.  The market will decide.
> 
> 	So, I feel strongly that if one end is "either", the other end must 
> be "both".  It's also acceptable to say both ends implement one choice 
> and the other is optional at both ends.  Here, I think it's server 
> does both and client does either.
> 
> 	Hi Ben, 	That was my original suggestion, and I still think it makes
> the most sense. 	Thanks for supporting the proposal. 	Don
> 
> 	That makes the most sense for both DB and device vendors.
> Markets will probably drive DB vendors to do both. Device vendors will 
> do what fits the market segment they're after. Why over-constrain (or 
> 	From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]> ] On 
> Behalf Of [email-masked] <mailto:[email-masked]>
> 	To: [email-masked] <mailto:[email-masked]>
> encoding. 	To prevent endless discussions on this topic I'd suggest we
> move forward with supporting both in the DB and either one in the master
> device. 	Any objections?
> 
> 	Gabor
> 
> 
> 	From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]> ] On 
> Behalf Of ext Das, Subir
> 	Cc: [email-masked] <mailto:[email-masked]> ; Manikkoth Sajeev
> 	We have a half a dozen or more TVDB radio vendors that use/prefer 
> JSON and we will vote for JSON if we had to pick one.
> 	From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] <mailto:[mailto:[email-masked]]>
> On Behalf Of Don Joslyn
> 	Cc: [email-masked] <mailto:[email-masked]> ; Manikkoth Sajeev
> 	From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]> ] On 
> Behalf Of Vincent Chen
> 	Cc: [email-masked] <mailto:[email-masked]> ; Manikkoth Sajeev
> 	*	One of our goals is to strive to lower the cost and
> complexity for device manufacturers. This lowers the barrier for 
> building a robust ecosystem.
> 
> 	[DJ - The "cost" and complexity of using XML has not been an issue 
> for the half dozen TVBD vendors that have already used XML. Maybe we 
> need to better define "cost"?]
> 
> 	*	To reduce complexity and cost for device makers, supporting
> 1 encoding is better than both, as Brian points out. WiFi access 
> points that "just work" anywhere in the world serves as a good model.
> 
> 	[DJ - I proposed that the databases support both XML and JSON, 
> devices only need to support one to talk to the database. Our current 
> database supports XML and JSON, but if I'm forced to pick only one, 
> then I will vote for XML because it's the one that we currently use on 
> all embedded devices.]
> 
> maps) 		*	Simple-to-use libraries exist for all major
> languages/platforms 		*	Don't need a tool chain to work with the data,
> as is typically needed for XML.
> 
> 	*	At the end of the day, it's the data model that matters,
> rather than the encoding. We (Google) are actually neutral on XML vs 
> JSON, as long as we're clear on what device makers want. It would be 
> good to get feedback from device makers (especially of embedded
> devices) regarding experiences supporting XML vs JSON.
> 
> 
> 
> 	On Fri, Aug 17, 2012 at 6:06 PM, Weixinpeng <[email-masked]
> <mailto:[email-masked]> > wrote: 	Considering of the design of
> database discovery protocol, the LoST protocol may be used and LoST is 
> based on XML, so I think XML may be preferred.
> 
> 	--Xinpeng Wei
> 
> 	From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]> ] On 
> Behalf Of Rosen, Brian
> 
> 	Sent: Friday, August 17, 2012 9:26 PM 	To: Manikkoth Sajeev;
> [email-masked] <mailto:[email-masked]> ; 
> [email-masked] <mailto:[email-masked]> ; [email-masked] 
> <mailto:[email-masked]>
> 
> 	Cc: [email-masked] <mailto:[email-masked]>
> 	I don't really care whether we use json or xml as a matter of 
> protocol design or implementation, but I am a big fan of reusing 
> standards rather than defining new ones, and I would not want to see 
> the choice of json mean we then decide to roll our own versus using 
> existing standards based on the idea there is no json representation 
> of an existing standard.  So, if choosing json means folks feel free 
> to ignore existing xml based standards such as xCard and LoST, then I 
> 	From: Manikkoth Sajeev <[email-masked] <mailto:[email-masked]> >
> 	Reply-To: Manikkoth Sajeev <[email-masked] 
> <mailto:[email-masked]> >
> 	To: "[email-masked] <mailto:[email-masked]> "
> <[email-masked] <mailto:[email-masked]> >, "Rosen, Brian"
> <[email-masked] <mailto:[email-masked]> >, 
> "[email-masked] <mailto:[email-masked]> " <[email-masked] 
> <mailto:[email-masked]> >, "[email-masked] 
> <mailto:[email-masked]> " <[email-masked] 
> <mailto:[email-masked]> >
> 	Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] 
> <mailto:[email-masked]> >
> optioncan also work. JSON I think will necessitate implementation to 
> 	Sajeev Manikkoth 	Mobile: +918792292002 <tel:%2B918792292002> 	Email:
> [email-masked] <mailto:[email-masked]>
> <http://www.linkedin.com/in/mksajeev>
> 
> 
> 	From: "[email-masked] <mailto:[email-masked]> "
> <[email-masked] <mailto:[email-masked]> > 	To:
> [email-masked] <mailto:[email-masked]> ; 
> [email-masked] <mailto:[email-masked]> ; [email-masked]
> <mailto:[email-masked]> 	Cc: [email-masked]
> <mailto:[email-masked]> 	Sent: Friday, 17 August 2012, 4:55 	Subject: Re:
> [paws] XML schema versus JSON, vCard & iCal
> 
> 
> 	We have not heard any objections for using JSON encoding instead of
> XML. 	Therefore, let's go for JSON, and close this thread.
> 
> 	- Gabor
> 
> 	From: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]> ] On 
> Behalf Of ext Rosen, Brian
> 	Cc: [email-masked] <mailto:[email-masked]> '
> 	I'd prefer an ISO time stamp rather than a time in seconds since 
> epoch.  It's very easy to parse, and its simpler to use and debug.
> Don't care a whole lot about that
> 
> 	Brian <as individual>
> 
> 
> 
> 	-----Original Message----- 	From:     Vincent Chen
> [mailto:[email-masked] <mailto:[email-masked]> ] 	Sent:    Monday,
> August 13, 2012 06:04 PM Eastern Standard Time 	To:    Peter Stanforth
> <mailto:[email-masked]> 	Subject:    Re: [paws] XML schema versus JSON,
> vCard & iCal
> 
> 	XML vs JSON
> 
> JSON-handling libraries exist for numerous languages (see of 
> http://json.org/ <http://json.org/> ) and seem to be reasonably light 
> weight.
> 
> 	Timestamps
> 
> 	As for timestamp specifications, should we consider just using 
> seconds since the UNIX Epoch (1970-01-01T00:00:00Z)? This would 
> eliminate the need for datetime-string parsing on devices, assuming 
> devices already have native libraries that provide time in this format.
> Is that a valid assumption? Of course, this is less human-readable....
> 
> 
> 	On Mon, Aug 13, 2012 at 6:49 AM, Peter Stanforth 
> <[email-masked] <mailto:[email-masked]> > wrote:
> 
> 
> sensor 	    days even an IP stack was a challenge,so I would defer to
> the device guys 	    on that one.
> 
> 	    <[email-masked] <mailto:[email-masked]> > wrote:
> 
> message 	    >size and compromising utility and security in search of
> efficiency of 	    >implementation on small devices is a poor trade off.
>  I am not advocating 	    >being wasteful of resources, but I don't
> think we should seriously 	    >consider the overhead of XML or json to
> be significant. 	    > 	    >Assuming a json library can be loaded on a
> small device is reasonable. 	    > 	    >Brian (as individual) 	    > 	 
>   > 	    > 	    > -----Original Message----- 	    >From:  Peter
> Stanforth [mailto:[email-masked]
> <mailto:[email-masked]> ] 	    >Sent:  Saturday, August 11,
> 2012 07:13 AM Eastern Standard Time 	    >To:    Teco Boot; Benjamin
> A.Rolfe 	    >Cc:    [email-masked] <mailto:[email-masked]> 	    >Subject:
>      Re: [paws] XML schema versus JSON, vCard & iCal 	    > 	    >Not
> all masters run over the core network. 	    >Some of the Use cases have
> a master talking to another OTA 	    >We should not assume that all
> Masters are attached to utility power so we 	    >should be sympathetic
> to processing energy use also. 	    > 	    >On SatAug/11/12 Sat Aug 11,
> 5:30 AM, "Teco Boot" <teco@inf- net.nl <mailto:[email-masked]> > wrote:
> 	    > 	    >> 	    >>Op 10 aug. 2012, om 18:10 heeft Benjamin A. Rolfe
> het volgende 	    >>geschreven: 	    >> 	    >>> Compactness of messages
> is important, but it is also important (to me 	    >>>at least) to be
> realizable in an implementation with limited resources, 	    >>>such as
> embedded devices in what are now popularly called "M2M" 	   
> >>>applications.  A lot of these devices could use IP all the end to
> end, 	    >>>but may have a very compact, simple stack and applications
> (i.e.  no 	    >>>browser).  Is JSON typically implemented when there is
> no browser? 	    >>>Would it be hard to do in a resource constrained
> device (i.e. where we 	    >>>talk about memory size in Kilo-bytes
> still). 	    >> 	    >>In use cases and requirements document, there are
> no requirements for 	    >>protocol performance. I guess OS/IP/TCP/TLS
> code size supersedes needs 	    >>for JSON or XML. 	    >> 	    >>Same
> for timing: TCP/TLS connection setup will take more than the PAWS 	   
> 	    >>links. 	    >> 	    >>Because PAWS runs between master and
> database, over core network, 	    >>performance is not our primary
> concern. But as always, it is good to keep 	    >>an eye on efficiency.
> 	    >> 	    >>Teco 	    >> 	    >>> Thanks 	    >>> Ben 	    >>> 	   
> >>> 	    >>>> We had a discussion on XML vs. JSON. I prefer the one 
> >>> with
> most 	    >>>>compact messages. 	    >>>> 	    >>>> On vCard and JSON:
> what is the status of "A JavaScript Object Notation 	    >>>>(JSON)
> Representation for vCard"? 	    >>>>
> <http://tools.ietf.org/html/draft-bhat-vcarddav-json-00> 	    >>>> 	   
> <http://tools.ietf.org/html/rfc3280#section-4.1.2.5> 	    >>>> 	    >>>>
> Teco 	    >>>> _______________________________________________ 	    >>>>
> paws mailing list 	    >>>> [email-masked] <mailto:[email-masked]> 	   
> <https://www.ietf.org/mailman/listinfo/paws> 	    >>>> 	    >>> 	    >>>
> _______________________________________________ 	    >>> paws mailing
> list 	    >>> [email-masked] <mailto:[email-masked]> 	    >>>
> <https://www.ietf.org/mailman/listinfo/paws> 	    >> 	   
> >>_______________________________________________ 	    >>paws mailing
> list 	    >>[email-masked] <mailto:[email-masked]> 	   
> <https://www.ietf.org/mailman/listinfo/paws> 	    > 	   
> >_______________________________________________ 	    >paws mailing list
> 	    >[email-masked] <mailto:[email-masked]> 	   
> 	    _______________________________________________ 	    paws mailing

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 21:49:41 +0000

My understanding is different. How I interpret the text is that if we choose JSON only, we shall not say later on that we are not going to make use LoST, or xCard, or other protocols just because they are not encoded using JSON encoding.

We could either specify a JSON encoding (convert xml) for those protocols, or some suggested in the F2F that we could embed xml into JSON. However, this latter to me means that we have to support then both JSON and XML. 

- Gabor

-----Original Message-----
From: ext Peter McCann [mailto:[email-masked]] 
Sent: Friday, August 24, 2012 2:12 PM
To: Patil Basavaraj (Nokia-CIC/Dallas); [email-masked]; Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: [email-masked]
Subject: RE: [paws] XML schema versus JSON, vCard & iCal

I think you are mis-representing Brian's point of view.  I share his concern about re-inventing encodings for LoST/xCard.

-Pete

[email-masked] wrote:
> Of ext Rosen, Brian
> Of Benjamin A. Rolfe

---

From: <[email-masked]>
Date: Fri, 24 Aug 2012 22:41:56 +0000

Pete, 

We have not made a decision on whether we will use LoST in the context of
database discovery at this time. It is an option no doubt. I am more
focused on the actual query/response protocol w.r.t the encoding
discussion. 
Database discovery can be a separate aspect from the actual
device-2-database protocol and hence the aspect of JSON in the context of
LoST should not even arise.

My view is that having a single mandatory encoding scheme (in this case
JSON) for the device-2-database protocol would ensure interoperability.

-Raj

---

From: Manikkoth Sajeev <[email-masked]>
Date: Fri, 24 Aug 2012 20:13:58 -0700 (PDT)

Hi,
 
I would still support XML. JSON libraries are available for all languages. But interfacing and linking such libraries are problematic on embedded devices most of the time. And if an implementation vouch for multiple such non native language libraries then developers life is hell...

Best Regards,
 
Sajeev Manikkoth

________________________________
 From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked] 
Cc: [email-masked] 
Sent: Saturday, 25 August 2012, 0:38
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

  

  
  
-          Gabor 

From:[email-masked] [mailto:[email-masked]] On Behalf Of ext Rosen, Brian
Sent: Friday, August 24, 2012 10:43 AM
To: Benjamin A. Rolfe
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal   
  
Okay: 

   
What do you do?  
   
Brian  
   
On Aug 24, 2012, at 1:38 PM, "Benjamin A. Rolfe" <[email-masked]> wrote:  

 

   

   
Brian  
   
On Aug 24, 2012, at 12:57 PM, Benjamin A. Rolfe <[email-masked]> wrote:  

It is my *opinion* at the  moment that if you provide options, to make those useful you need to provide  a protocol by which devices can discover what options the database supports.  If you have such a mechanism and all devices use it (a  bootstrap protocol),
 everything else could be options.  This requires additional functions in both database and device implementations. 
If on the other hand the device can "just know" that the database has two forms available, it won't need to dynamically figure it out. The device implementer has options and simplicity, so I like it. 

Since I am focused on the TVWS devices that need access to the database, and not a database implementer, shifting burden onto the database implementer (not me) to reduce the burden on the device implementer (me) is preferred from my perspective.  The database
 implementer may have another perspective.  Should I point out that there will be a lot more devices than databases?  That might sound like an argument, though, so I won't....:-j

Ben

   

   
   
End of argument you now can go back to your regularly schedule programming. J 

From:[email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, August 23, 2012 5:44 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal   

I agree with Brian.  
    
-Raj  

    

    
    
Brian <as individual>  

   

Hi Ben,  

  
Sounds good to me.  

   
Gabor  

   

   

   

   
--Xinpeng Wei  

Cc: [email-masked]

    

Brian <as individual>   
    
To: "[email-masked]" <[email-masked]>, "Rosen, Brian" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    
Hi,   

Best Regards,   
Sajeev Manikkoth
Mobile: +918792292002
Email: [email-masked]

- Gabor

-----Original Message-----

json is okay with me.  

Brian <as individual>

-----Original Message-----

XML vs JSON

Between XML and JSON, JSON messages are more compact and easier to process (parsing, synthesis). As clarification, JSON does not require JavaScript or a Browser. It is a text-based representation of data that is language independent, yet well-matched to all
 major languages. JSON-handling libraries exist for numerous languages (see of http://json.org/) and seem to be reasonably light weight.

Timestamps

As for timestamp specifications, should we consider just using seconds since the UNIX Epoch (1970-01-01T00:00:00Z)? This would eliminate the need for datetime-string parsing on devices, assuming devices already have native libraries that provide time in this
 format. Is that a valid assumption? Of course, this is less human-readable....

    

    

-- 
-vince

    
-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Fri, 24 Aug 2012 20:36:00 -0700

Sajeev,

It's been a while since I've worked with embedded devices. I'm surprised
that the same concern does not apply to XML. Do you not need libraries to
work with XML?

On Fri, Aug 24, 2012 at 8:13 PM, Manikkoth Sajeev <[email-masked]> wrote:

> Hi,
>
> I would still support XML. JSON libraries are available for all languages.
> But interfacing and linking such libraries are problematic on embedded
> devices most of the time. And if an implementation vouch for multiple such
> non native language libraries then developers life is hell...
>
> *Best Regards,*
> **
> *Sajeev Manikkoth
> *
>
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Sent:* Saturday, 25 August 2012, 0:38
>
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
>
>  WiFi world builds on mandating the implementation (and certification) of
> a base spec, and a set of optional features. If an optional feature is not
> supported by one of the peers, they can still talk, but not use that
> feature. That is basically option B) from Brain’s list.
>
> I’d like to suggest that we recognize that option A) and B) are valid
> I’d also like to add the obvious option D) to the list, which is that both
> the master devices and DBs support one and the same encoding ;)
>
> Option A) seems to be like a good compromise, and would cut discussions
> short, with the only caveat that if there is no strong technical argument
> for supporting and specifying two different encodings, then the iesg may
> send the document back to the wg to pick one of the two specified. As
> Robert mentioned in his email, this has happened in the past, so it is
> likely it would happen again. And frankly, I do not see a strong argument
> in favor of two different encodings.
>
> picking JSON. One said that JSON requires native Java, which is wrong, the
> other objection gave no real reason. So I am wondering if there is really
> any valid technical reason against using JSON only?
>
> -          Gabor
>
>
> Of *ext Rosen, Brian
> *Sent:* Friday, August 24, 2012 10:43 AM
> *To:* Benjamin A. Rolfe
> *Cc:* [email-masked]
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
>
> Okay:
>
>  You query my database (let's not get into how you do that query without
> deciding XML vs JSON) and discover I implement XML only
>
>  What do you do?
>
>  Brian
>
> information about what options each supports, without requiring that any
> device implement every option.  It works.
>
> That said, I think (A) is the best choice, (B) is not as nice for me, and
> (C) is more work than either of the other two.
>
>
>
> implement") and both can optionally implement the other choice.  Only if
> both ends implement the other choice would that be available.
>
>  I don't care, but choice C) Both databases and devices have a choice of
> what to implement doesn't work for me (or Richard).
>
>  Brian
>
> You do not need to choose only one form to achieve interoperability.   If
> you have two, let the device implementer figure out which is best for their
> particular device requirements and trade-offs.  This is *preferable* from
> my perspective.
>
> database need some means for figuring out which are available. It can't use
> it if it doesn't no about it. This is an observations, not an argument
> ;-).
>
> It is my *opinion* at the  moment that if you provide options, to make
> those useful you need to provide  a protocol by which devices can discover
> what options the database supports.  If you have such a mechanism and all
> devices use it (a  bootstrap protocol), everything else could be options.
> This requires additional functions in both database and device
> implementations.
> If on the other hand the device can "just know" that the database has two
> forms available, it won't need to dynamically figure it out. The device
> implementer has options and simplicity, so I like it.
>
> Since I am focused on the TVWS devices that need access to the database,
> and not a database implementer, shifting burden onto the database
> implementer (not me) to reduce the burden on the device implementer (me) is
> preferred from my perspective.  The database implementer may have another
> perspective.  Should I point out that there will be a lot more devices than
> databases?  That might sound like an argument, though, so I won't....:-j
>
> Ben
>
>
>  This BTW is a classic argument in IETF terms .. but the argument “let
> the market decide” only holds so much validity.  You actually have to
>   *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of [email-masked]
> *Sent:* Thursday, August 23, 2012 5:44 PM
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
>
>
>   I agree with Brian.
>   *From: *"<ext Rosen>", "[email-masked]" <
> [email-masked]>
> *Date: *Thursday, August 23, 2012 2:43 PM
> *To: *Don Joslyn <[email-masked]>
> *Subject: *Re: [paws] XML schema versus JSON, vCard & iCal
>
>   One of my favorite IETF expressions is "There are no protocol police".
>  We apply that in lots of ways, but one of them is that if you don't
> implement what the document says, you may not get interoperability with
> other implementations.  On the other hand, the whole point of a protocol
> document like ours is that two independent implementations who both follow
> the document will interwork.  If that wasn't true, why do you need a
> standard?
>
>   *From:* [email-masked] [mailto:paws- <paws->[email-masked]] *On
> Behalf Of *Benjamin A. Rolfe
> *Sent:* Thursday, August 23, 2012 3:05 PM
> *To:* [email-masked]
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
>
>   *From:* [email-masked] [mailto:[email-masked]<[email-masked]>
> ] *On Behalf Of [email-masked]
> *Sent:* Tuesday, August 21, 2012 12:42 AM
> *To:* [email-masked]
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
>
>  To prevent endless discussions on this topic I’d suggest we move forward
>   *From:* [email-masked] [mailto:[email-masked]<[email-masked]>
> ] *On Behalf Of *ext Das, Subir
> *Sent:* Monday, August 20, 2012 2:50 PM
> *To:* Don Joslyn; Vincent Chen; Weixinpeng
> *Cc:* [email-masked]; Manikkoth Sajeev
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
>
> Of *Don Joslyn
> *Sent:* Monday, August 20, 2012 4:54 PM
> *To:* Vincent Chen; Weixinpeng
> *Cc:* [email-masked]; Manikkoth Sajeev
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
>
>   *From:* [email-masked] [mailto:[email-masked]<[email-masked]>
> ] *On Behalf Of *Vincent Chen
> *Sent:* Monday, August 20, 2012 2:56 PM
> *To:* Weixinpeng
> *Cc:* [email-masked]; Manikkoth Sajeev
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
>
>
>  [DJ - The “cost” and complexity of using XML has not been an issue for
> the half dozen TVBD vendors that have already used XML. Maybe we need to
> better define “cost”?]
>
>    - To reduce complexity and cost for device makers, supporting 1
> supports XML and JSON, but if I’m forced to pick only one, then I will vote
> for XML because it’s the one that we currently use on all embedded devices.]
>
>    - There's a trend for APIs on the web towards JSON (Twitter,
>  [DJ – I can’t argue against these listed pros for JSON, especially when
> you’re dealing with a lot of data (like Twitter, FourSquare, Facebook and
> Google does). But I’m assuming that PAWS messages will not be exchanged
> is more efficient, can’t argue with that.]
>
> amount of data that needs to be exchanged between device and database is
> not that much or exchanged that often.]
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
>
> *Subject: *Re: [paws] XML schema versus JSON, vCard & iCal
>
>    Hi,
>
> Future implementations may prefer *XML as it is generic, omni present,
> easy to understand and validate.* For compactness may be a  *binary xml
> option*can also work. JSON I think will necessitate implementation to be
> native Java and may not be as friendly with other implementation languages.
>
>    *Best Regards,*
>   *Sajeev Manikkoth
> Mobile: +918792292002
> Email: [email-masked]
> http://www.linkedin.com/in/mksajeev*
>
> *Subject:* Re: [paws] XML schema versus JSON, vCard & iCal
>
> ext Rosen, Brian
> end,

-- 
-vince

---

From: Cuiyang <[email-masked]>
Date: Sat, 25 Aug 2012 03:37:59 +0000

Hi,

I prefer to both.
But if I have to choose from interoperability and “a little” compactness of codes, I will vote for XML.

Best regards,
Yang
==================
Yang Cui,  Ph.D.
Huawei Technologies
[email-masked]

发件人: [email-masked] [mailto:[email-masked]] 代表 Manikkoth Sajeev
发送时间: 2012年8月25日 11:14
收件人: [email-masked]; [email-masked]; [email-masked]
抄送: [email-masked]
主题: Re: [paws] XML schema versus JSON, vCard & iCal

Hi,

Best Regards,

Sajeev Manikkoth

-          Gabor

Okay:

What do you do?

Brian

Brian

Ben

Brian is right .. sorry but the rest of you are wrong. ☺

End of argument you now can go back to your regularly schedule programming. ☺

I agree with Brian.

-Raj

Brian <as individual>

Hi Ben,

Sounds good to me.

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

paws mailing list

---

From: Manikkoth Sajeev <[email-masked]>
Date: Fri, 24 Aug 2012 22:54:11 -0700 (PDT)

Hi,
 
XML being generic and widely used in all languages the required libraries and the code is most of the time already there in the device is the advantage. 

Best Regards,
 
Sajeev Manikkoth

________________________________
 From: Vincent Chen <[email-masked]>
To: Manikkoth Sajeev <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Saturday, 25 August 2012, 9:06
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Sajeev,

It's been a while since I've worked with embedded devices. I'm surprised that the same concern does not apply to XML. Do you not need libraries to work with XML?

Hi,

-- 
-vince

---

From: "Das, Subir" <[email-masked]>
Date: Sun, 26 Aug 2012 01:30:06 +0000

It would be good if you can provide some specific examples where JSON is problematic but XML is easier.

-Subir

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manikkoth Sajeev
Sent: Friday, August 24, 2012 11:14 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Hi,

Best Regards,

Sajeev Manikkoth

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

-          Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Rosen, Brian
Sent: Friday, August 24, 2012 10:43 AM
To: Benjamin A. Rolfe
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Okay:

What do you do?

Brian

Brian

Ben

I agree with Brian.

-Raj

Brian <as individual>

Hi Ben,

Sounds good to me.

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

paws mailing list

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 26 Aug 2012 10:35:14 +0300

Hi all,

JSON and XML are very similar in terms of supported tools and 
availability of code in languages.

The only question to me that arises is whether you want to re-use 
existing protocol work (such as LoST, vCard, GML, etc.). Do you know the 
answer to this question?

Ciao
Hannes

PS: Embedded devices, M2M, Internet of Things implementation (whatever 
you want to call them) use all sorts of encodings, including XML and 
JSON. In fact the most "heavy" part of the code will not be the XML/JSON 
(which will most likely be uses as a template anyway) but the security 
functionality.

On 08/26/2012 04:30 AM, Das, Subir wrote:
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Manikkoth Sajeev
> *Sent:* Friday, August 24, 2012 11:14 PM
> *To:* [email-masked]; [email-masked]; [email-masked]
> *Cc:* [email-masked]
> I would still support XML. JSON libraries are available for all
> languages. But interfacing and linking such libraries are problematic on
> embedded devices most of the time. And if an implementation vouch for
> multiple such non native language libraries then developers life is hell...
>
> /Best Regards,/
>
> /Sajeev Manikkoth/
>
> *From:*"[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> *To:* [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> a base spec, and a set of optional features. If an optional feature is
> not supported by one of the peers, they can still talk, but not use that
> I’d also like to add the obvious option D) to the list, which is that
> short, with the only caveat that if there is no strong technical
> argument for supporting and specifying two different encodings, then the
> iesg may send the document back to the wg to pick one of the two
> specified. As Robert mentioned in his email, this has happened in the
> past, so it is likely it would happen again. And frankly, I do not see a
> strong argument in favor of two different encodings.
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of *ext Rosen, Brian
> *Cc:* [email-masked] <mailto:[email-masked]>
> You do not need to choose only one form to achieve interoperability.
> If you have two, let the device implementer figure out which is best for
> their particular device requirements and trade-offs.  This is
> *preferable* from my perspective.
>
> database need some means for figuring out which are available. It can't
> use it if it doesn't no about it. This is an observations, not an
> argument ;-).
>
> those useful you need to provide  a protocol by which devices can
> two forms available, it won't need to dynamically figure it out. The
> device implementer has options and simplicity, so I like it.
>
> implementer (not me) to reduce the burden on the device implementer (me)
> is preferred from my perspective.  The database implementer may have
> another perspective.  Should I point out that there will be a lot more
> devices than databases?  That might sound like an argument, though, so I
> won't....:-j
>
> Ben
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of [email-masked]
> <mailto:[email-masked]>
> *To:* [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *From: *"<ext Rosen>", "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *To: *Don Joslyn <[email-masked]
> <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> document like ours is that two independent implementations who both
> follow the document will interwork.  If that wasn't true, why do you
> need a standard?
>
> "both".  It's also acceptable to say both ends implement one choice and
> the other is optional at both ends.  Here, I think it's server does both
> and client does either.
>
> On Aug 23, 2012, at 3:11 PM, Don Joslyn <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
> Hi Ben,
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>]*On Behalf
> Of*Benjamin A. Rolfe
> *Sent:*Thursday, August 23, 2012 3:05 PM
> *To:[email-masked] <mailto:[email-masked]>
> *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal
>
> probably drive DB vendors to do both. Device vendors will do what fits
> the market segment they're after. Why over-constrain (or argue when
> natural selection will take care of it for us?).
> B
>
>
> Sounds good to me.
>
> *From:[email-masked]
> <mailto:[email-masked]>[mailto:[email-masked]]*On Behalf
> [email-masked] <mailto:[email-masked]>
> *Sent:*Tuesday, August 21, 2012 12:42 AM
> *To:[email-masked] <mailto:[email-masked]>
> *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal
>
> *From:[email-masked]
> <mailto:[email-masked]>[mailto:[email-masked]]*On Behalf
> Of*ext Das, Subir
> *Sent:*Monday, August 20, 2012 2:50 PM
> *To:*Don Joslyn; Vincent Chen; Weixinpeng
> *Cc:[email-masked] <mailto:[email-masked]>; Manikkoth Sajeev
> *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal
>
>       o Simple-to-use libraries exist for all major languages/platforms
>       o Don't need a tool chain to work with the data, as is typically
>         needed for XML
>
> *From:[email-masked]
> <mailto:[email-masked]>[mailto:[email-masked]]
> <mailto:[mailto:[email-masked]]>*On Behalf Of*Don Joslyn
> *Sent:*Monday, August 20, 2012 4:54 PM
> *To:*Vincent Chen; Weixinpeng
> *Cc:[email-masked] <mailto:[email-masked]>; Manikkoth Sajeev
> *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal
>
> *From:[email-masked]
> <mailto:[email-masked]>[mailto:[email-masked]]*On Behalf
> Of*Vincent Chen
> *Sent:*Monday, August 20, 2012 2:56 PM
> *To:*Weixinpeng
> *Cc:[email-masked] <mailto:[email-masked]>; Manikkoth Sajeev
> *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal
>
>     encoding is better than both, as Brian points out. WiFi access
> supports XML and JSON, but if I’m forced to pick only one, then I will
> vote for XML because it’s the one that we currently use on all embedded
> devices.]
>
>     FourSquare, Facebook, Google, etc.). One of the major reasons is
>     that developers (client-side) prefer it for its simplicity:
>
>       o Representation closely matches most data models (nested lists
>         and maps)
>       o Simple-to-use libraries exist for all major languages/platforms
>       o Don't need a tool chain to work with the data, as is typically
>         needed for XML.
>
> you’re dealing with a lot of data (like Twitter, FourSquare, Facebook
> and Google does). But I’m assuming that PAWS messages will not be
> exchanged nearly as often as the applications mentioned above. But
> again, I know JSON is more efficient, can’t argue with that.]
>
>     the encoding. We (Google) are actually neutral on XML vs JSON, as
> <mailto:[email-masked]>> wrote:
>
> *From:[email-masked]
> <mailto:[email-masked]>[mailto:[email-masked]
> <mailto:[email-masked]>]*On Behalf Of*Rosen, Brian
>
>
> *Sent:*Friday, August 17, 2012 9:26 PM
>
> *To:*Manikkoth Sajeev;[email-masked]
> <mailto:[email-masked]>;[email-masked]
> <mailto:[email-masked]>;[email-masked]
> *Cc:[email-masked] <mailto:[email-masked]>
> *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal
>
> than defining new ones, and I would not want to see the choice of json
> mean we then decide to roll our own versus using existing standards
> based on the idea there is no json representation of an existing
> standard.  So, if choosing json means folks feel free to ignore existing
> xml based standards such as xCard and LoST, then I would not want to use
> json.
>
> choices.  If you like json because it is smaller, then I believe you
> need a much better reason.  Binary doesn't work for me, at all.  I have
> been involved in big binary vs text wars in protocol design.  Text wins,
> *From:*Manikkoth Sajeev <[email-masked] <mailto:[email-masked]>>
> *Reply-To:*Manikkoth Sajeev <[email-masked] <mailto:[email-masked]>>
> *Date:*Thu, 16 Aug 2012 22:37:38 -0400
> *To:*"[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>, "Rosen, Brian"
> <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *Cc:*"[email-masked] <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>
> *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal
>
> Hi,
>
> implementations may prefer*XML as it is generic, omni present, easy to
> understand and validate.*For compactness may be a *binary xml option*can
> also work. JSON I think will necessitate implementation to be native
> Java and may not be as friendly with other implementation languages.
>
> /Best Regards,/
>
> /Sajeev Manikkoth
> Mobile:+918792292002
> Email:[email-masked] <mailto:[email-masked]>
> http://www.linkedin.com/in/mksajeev/
>
> *From:*"[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
> *To:[email-masked]
> <mailto:[email-masked]>;[email-masked]
> <mailto:[email-masked]>;[email-masked]
> *Cc:[email-masked] <mailto:[email-masked]>
> *Sent:*Friday, 17 August 2012, 4:55
> *Subject:*Re: [paws] XML schema versus JSON, vCard & iCal
>
>
> From:[email-masked]
> <mailto:[email-masked]>[mailto:[email-masked]
> <mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
> Cc: [email-masked] <mailto:[email-masked]>'
> From:     Vincent Chen [mailto:[email-masked] <mailto:[email-masked]>]
> Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe;[email-masked]
> <mailto:[email-masked]>
> JavaScript or a Browser. It is a text-based representation of data that
> is language independent, yet well-matched to all major languages.
> JSON-handling libraries exist for numerous languages (see
> ofhttp://json.org/) and seem to be reasonably light weight.
>
> Timestamps
>
> have native libraries that provide time in this format. Is that a valid
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>      <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Cuiyang <[email-masked]>
Date: Mon, 27 Aug 2012 07:20:21 +0000

Hi, 

> JSON. In fact the most "heavy" part of the code will not be the XML/JSON
JSON's compactness advantage over XML cannot make big difference, then.

> (which will most likely be uses as a template anyway) but the security
Agree!
In the last meeting at Vancouver, many discussions on the PAWS framework are actually on security, typically authentication by certificate and pre-shared secret, crypto-binding of protocols in distinct layers, etc.
Even more need to be discussed yet.

Best Regards,
Yang
==================
 Yang Cui,  Ph.D.
 Huawei Technologies
 [email-masked]

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Hannes Tschofenig
> 发送时间: 2012年8月26日 15:35
> 收件人: Das, Subir
> 抄送: [email-masked]; Manikkoth Sajeev
> implements
> > one or both.
> to
> <[email-masked]
> > <mailto:[email-masked]>> wrote:
> >      >
> >      >>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Mon, 27 Aug 2012 08:50:03 -0700

I have implemented minimalist XML parsers in "C" and run with very
limited resources along with a very thin imitation of an HTTP/TCP/IP
stack, very sharply focused on the specific messages of a particular
application (i.e. do only what you need for the app and nothing
more). In a device that is deeply embedded, has a very specific
purpose, and is not expected to adapt to new purposes after
deployment, won't implement all the functions needed to comply with
the standard, but just enough to inetrop as needed for the specific
purpose.

Many embedded developers find the LCD is still a tool chain for  C.
I found a C-language implementation of JSON after a very a brief
search.  If someone has experience with one of these it'd be great
comfort for some, I'm sure.

Note that the term "embedded" was widely varying meanings, from the
sort of limited purpose, long life, no-touch devices I'm thinking
about to really smart devices with real operating systems, memory,
rechargeable batteries and other such luxuries.  "whitespace device"
is a similarly diverse term, and currently we have PHY standards
published or in development with over the air data rates from many
mega-bits per second to a few hundred kilo-bits per second.  It's
clearly a challenge!

-Ben

Sajeev,

It's been a while since I've worked with embedded devices.
I'm surprised that the same concern does not apply to XML. Do
you not need libraries to work with XML?

On Fri, Aug 24, 2012 at 8:13 PM,
Manikkoth Sajeev <[email-masked]> wrote:

Hi,

I would still
support XML. JSON libraries are available for all
languages. But interfacing and linking such
libraries are problematic on embedded devices most
of the time. And if an implementation vouch for
multiple such non native language libraries then
developers life is hell...

Best Regards,

Sajeev Manikkoth

From:
"[email-masked]"
<[email-masked]>

To:
[email-masked]; [email-masked]

Cc:
[email-masked]

Sent:
Saturday, 25 August 2012, 0:38

Subject:
Re: [paws] XML schema versus JSON, vCard
& iCal

WiFi world builds on
mandating the implementation (and
certification) of a base spec, and a
set of optional features. If an
optional feature is not supported by
one of the peers, they can still talk,
but not use that feature. That is
basically option B) from Brain’s list.

I’d like to suggest
that we recognize that option A) and
B) are valid options, while option C)
is invalid, and we should stop
debating it.

I’d also like to add
the obvious option D) to the list,
which is that both the master devices
and DBs support one and the same
encoding ;)

Option A) seems to
be like a good compromise, and would
cut discussions short, with the only
caveat that if there is no strong
technical argument for supporting and
specifying two different encodings,
then the iesg may send the document
back to the wg to pick one of the two
specified. As Robert mentioned in his
email, this has happened in the past,
so it is likely it would happen again.
And frankly, I do not see a strong
argument in favor of two different
encodings.

Is there anyone who
has a technical argument against
supporting only one encoding, being
that either xml or json?

Most people speak in
favor of JSON, because it is compact
and more efficient. I went through
this thread and I saw 2 objections
against picking JSON. One said that
JSON requires native Java, which is
wrong, the other objection gave no
real reason. So I am wondering if
there is really any valid technical
reason against using JSON only?

-
Gabor

Sent: Friday, August 24,
2012 10:43 AM

To: Benjamin A. Rolfe

Cc: [email-masked]

Subject: Re: [paws] XML
schema versus JSON, vCard &
iCal

Okay:

So, I implement a database, and I
implement XML

You implement a device, and you
implement JSON

You query my database (let's not
get into how you do that query without
deciding XML vs JSON) and discover I
implement XML only

What do you do?

Brian

On Aug 24, 2012, at 1:38 PM,
"Benjamin A. Rolfe" <[email-masked]>
wrote:

There are two ways to achieve
interoperability when you have an
option.

There are many existence proofs
of the third way that I mentioned
below.

802.11 + WiFi provide many options
and a means for devices to share
information about what options
each supports, without requiring
that any device implement every
option.  It works.

That said, I think (A) is the best
choice, (B) is not as nice for me,
and (C) is more work than either
of the other two.

One is that one end
implements both choices and the
other end implements one or
both.

The other is that both ends
implement one specific choice
("MUST implement") and both can
optionally implement the other
choice.  Only if both ends
implement the other choice would
that be available.

So, in this case we could do
one of the following:

A) Databases implement both
XML and JSON, devices implement
either

B) Both Databases and devices
implement one (say XML) and
optionally implement the other
(say JSON)

You are advocating for A,
Richard was suggesting B.

I don't care, but choice C)
Both databases and devices have
a choice of what to implement
doesn't work for me (or
Richard).

Brian

On Aug 24, 2012, at 12:57
PM, Benjamin A. Rolfe <[email-masked]>
wrote:

Apparently I was
unclear.  I certainly an
capable of being wrong as I
practice often, but in this
case it is quite unlikely
:-).

You do not need to choose
only one form to achieve
interoperability.   If you
have two, let the device
implementer figure out which
is best for their particular
device requirements and
trade-offs.  This is
*preferable* from my
perspective.

If you provide more than one
form in the database,
devices using the database
need some means for figuring
out which are available. It
can't use it if it doesn't
no about it. This is an
observations, not an
argument ;-).

It is my *opinion* at the
moment that if you provide
options, to make those
useful you need to provide
a protocol by which devices
can discover what options
the database supports.  If
you have such a mechanism
and all devices use it (a
bootstrap protocol),
everything else could be
options.  This requires
additional functions in both
database and device
implementations.

If on the other hand the
device can "just know" that
the database has two forms
available, it won't need to
dynamically figure it out.
The device implementer has
options and simplicity, so I
like it.

Since I am focused on the
TVWS devices that need
access to the database, and
not a database implementer,
shifting burden onto the
database implementer (not
me) to reduce the burden on
the device implementer (me)
is preferred from my
perspective.  The database
implementer may have another
perspective.  Should I point
out that there will be a lot
more devices than
databases?  That might sound
like an argument, though, so
I won't....:-j

Ben

Brian is
right .. sorry but the
rest of you are wrong.
J

This is
why you have MUST and
SHOULD in RFC 2119.

This BTW
is a classic argument in
IETF terms .. but the
argument “let the market
decide” only holds so much
validity.  You actually
have to choose SOMETHING
to create a baseline of
interoperability.

A
virtually identical
argument  is now playing
out in discussions of
mandatory audio and codec
implementations for WEBRTC
like things.

IMHO XML
MUST anything else defined
SHOULD, but MUST on XML
and JSON could work as
well. It just leads to a
level of complexity in
implementations.

End of
argument you now can go
back to your regularly
schedule programming.
J

From:
[email-masked]

Sent: Thursday,
August 23, 2012 5:44
PM

Cc: [email-masked]

Subject: Re:
[paws] XML schema
versus JSON, vCard
& iCal

I agree with
Brian.

There needs to
be a default mandatory
to implement option in
order to achieve
interoperability.

And this applies
to the device and
database side of the
protocol.

-Raj

From:
"<ext

Date: Thursday,
August 23, 2012 2:43 PM

To: Don Joslyn
<[email-masked]>

Cc: "[email-masked]"
<[email-masked]>

Subject: Re:
[paws] XML schema versus
JSON, vCard & iCal

One of my
favorite IETF
expressions is "There
are no protocol
police".  We apply
that in lots of ways,
but one of them is
that if you don't
implement what the
document says, you may
not get
interoperability with
other implementations.
On the other hand,
the whole point of a
protocol document like
ours is that two
independent
implementations who
both follow the
document will
interwork.  If that
wasn't true, why do
you need a standard?

If you say
"either" to both
ends, then you don't
get
interoperability.

By your
argument, we should
stop working, and
the product managers
will figure it out
using proprietary
protocols.  The
market will decide.

So, I feel
strongly that if one
end is "either", the
other end must be
"both".  It's also
acceptable to say
both ends implement
one choice and the
other is optional at
both ends.  Here, I
think it's server
does both and client
does either.

It's always
possible to build an
implementation of a
server that only
does one: there are
no protocol police.

Brian <as
individual>

On Aug
23, 2012, at
3:11 PM, Don
Joslyn <[email-masked]> wrote:

Hi Ben,

That
was my
original
suggestion,
and I still
think it makes
the most
sense.

Thanks
for supporting
the proposal.

Don

Sent: Thursday,
August 23,
2012 3:05 PM

To: [email-masked]

Subject: Re:
[paws] XML
schema versus
JSON, vCard
& iCal

Someone
suggested that
PAWS define
both, and let
the vendors
decide which
ones to
implement.

That makes the
most sense for
both DB and
device
vendors.
Markets will
probably drive
DB vendors to
do both.
Device vendors
will do what
fits the
market segment
they're after.
Why
over-constrain
(or argue when
natural
selection will
take care of
it for us?).

B

Sounds
good to me.

Sent: Tuesday,
August 21,
2012 12:42 AM

To: [email-masked]

Subject: Re:
[paws] XML
schema versus
JSON, vCard
& iCal

Now I
can’t see
anymore any
willingness to
agree on one
or the other
encoding.

To
prevent
endless
discussions on
this topic I’d
suggest we
move forward
with
supporting
both in the DB
and either one
in the master
device.

Any
objections?

Gabor

Behalf Of ext
Das, Subir

Sent: Monday,
August 20,
2012 2:50 PM

To: Don
Joslyn;
Vincent Chen;
Weixinpeng

Cc: [email-masked];
Manikkoth
Sajeev

Subject: Re:
[paws] XML
schema versus
JSON, vCard
& iCal

We have
a half a dozen
or more TVDB
radio vendors
that
use/prefer
JSON and we
will vote for
JSON if we had
to pick one.

Also I
will copy the
following two
important
points:

Simple-to-use
libraries
exist for all
major
languages/platforms

Don't
need a tool
chain to work
with the data,
as is
typically
needed for XML

Behalf Of Don
Joslyn

Sent: Monday,
August 20,
2012 4:54 PM

To: Vincent
Chen;
Weixinpeng

Cc: [email-masked];
Manikkoth
Sajeev

Subject: Re:
[paws] XML
schema versus
JSON, vCard
& iCal

Please
see my
comments
below…

Thanks,

Don

Behalf Of Vincent
Chen

Sent: Monday,
August 20,
2012 2:56 PM

To: Weixinpeng

Cc: [email-masked];
Manikkoth
Sajeev

Subject: Re:
[paws] XML
schema versus
JSON, vCard
& iCal

One
of our goals
is to strive
to lower the
cost and
complexity for
device
manufacturers.
This lowers
the barrier
for building a
robust
ecosystem.

[DJ -
The “cost” and
complexity of
using XML has
not been an
issue for the
half dozen
TVBD vendors
that have
already used
XML. Maybe we
need to better
define
“cost”?]

To
reduce
complexity and
cost for
device makers,
supporting 1
encoding is
better than
both, as Brian
points out.
WiFi access
points that
"just work"
anywhere in
the world
serves as a
good model.

[DJ - I
proposed that
the databases
support both
XML and JSON,
devices only
need to
support one to
talk to the
database. Our
current
database
supports XML
and JSON, but
if I’m forced
to pick only
one, then I
will vote for
XML because
it’s the one
that we
currently use
on all
embedded
devices.]

There's
a trend for
APIs on the
web towards
JSON (Twitter,
FourSquare,
Facebook,
Google, etc.).
One of the
major reasons
is that
developers
(client-side)
prefer it for
its
simplicity:

Representation
closely
matches most
data models
(nested lists
and maps)

Simple-to-use
libraries
exist for all
major
languages/platforms

Don't
need a tool
chain to work
with the data,
as is
typically
needed for
XML.

Apparently,
the efficiency
gains of JSON
also matter to
the
scalability of
serving
systems.

[DJ – I
can’t argue
against these
listed pros
for JSON,
especially
when you’re
dealing with a
lot of data
(like Twitter,
FourSquare,
Facebook and
Google does).
But I’m
assuming that
PAWS messages
will not be
exchanged
nearly as
often as the
applications
mentioned
above. But
again, I know
JSON is more
efficient,
can’t argue
with that.]

At
the end of the
day, it's the
data model
that matters,
rather than
the encoding.
We (Google)
are actually
neutral on XML
vs JSON, as
long as we're
clear on what
device makers
want. It would
be good to get
feedback from
device makers
(especially of
embedded
devices)
regarding
experiences
supporting XML
vs JSON.

Don,
can you
elaborate on
the types of
devices that
already
support XML?

[DJ -
We currently
support half a
dozen TVDB
radio vendors
(embedded
devices) using
XML, non using
JSON. XML has
not been a
burden, and
the amount of
data that
needs to be
exchanged
between device
and database
is not that
much or
exchanged that
often.]

On Fri,
Aug 17, 2012
at 6:06 PM,
Weixinpeng
<[email-masked]>
wrote:

Considering
of the design
of database
discovery
protocol, the
LoST protocol
may be used
and LoST is
based on XML,
so I think XML
may be
preferred.

--Xinpeng
Wei

Behalf Of Rosen,
Brian

Sent: Friday,
August 17,
2012 9:26 PM

To: Manikkoth

Cc: [email-masked]

Subject: Re:
[paws] XML
schema versus
JSON, vCard
& iCal

I
don't really
care whether
we use json or
xml as a
matter of
protocol
design or
implementation,
but I am a big
fan of reusing
standards
rather than
defining new
ones, and I
would not want
to see the
choice of json
mean we then
decide to roll
our own versus
using existing
standards
based on the
idea there is
no json
representation
of an existing
standard.  So,
if choosing
json means
folks feel
free to ignore
existing xml
based
standards such
as xCard and
LoST, then I
would not want
to use json.

I
would prefer
to not have
"both",
because of
interoperability
complications.
If there is
rough
consensus for
both, then I
would assert
that all
servers have
to implement
both and the
client can
implement
either.

There
are json
validators, so
I don't think
that is a big
deal.

My
experience in
protocol
design on the
Internet is
that decisions
made solely or
even largely
because of
compactness
advantages
rarely are
good choices.
If you like
json because
it is smaller,
then I believe
you need a
much better
reason.
Binary
doesn't work
for me, at
all.  I have
been involved
in big binary
vs text wars
in protocol
design.  Text
wins, binary
loses, in my
opinion.

Brian
<as
individual>

From: Manikkoth

Reply-To: Manikkoth

Date: Thu,
16 Aug 2012
22:37:38 -0400

"Rosen, Brian"
<[email-masked]>,
"[email-masked]"
<[email-masked]>,

Cc: "[email-masked]"
<[email-masked]>

Subject: Re:
[paws] XML
schema versus
JSON, vCard
& iCal

Hi,

Can it not be
both JSON and
XML supported?
I would vote
for that.
Future
implementations
may prefer XML
as it is
generic, omni
present, easy
to understand
and validate. For

compactness
may be a  binary
xml optioncan
also work.
JSON I think
will
necessitate
implementation
to be native
Java and may
not be as
friendly with
other
implementation
languages.

Best
Regards,

Sajeev
Manikkoth

Mobile: +918792292002

Email: [email-masked]

Cc: [email-masked]

Sent: Friday,
17 August
2012, 4:55

Subject: Re:
[paws] XML
schema versus
JSON, vCard
& iCal

We have not
heard any
objections for
using JSON
encoding
instead of
XML.

Therefore,
let's go for
JSON, and
close this
thread.

- Gabor

-----Original
Message-----

On Behalf Of
ext Rosen,
Brian

Sent: Monday,
August 13,
2012 3:14 PM

To: 'Vincent
Chen'; 'Peter
Stanforth'

Cc: [email-masked]'

Subject: Re:
[paws] XML
schema versus
JSON, vCard
& iCal

json is okay
with me.

I'd prefer an
ISO time stamp
rather than a
time in
seconds since
epoch.  It's
very easy to
parse, and its
simpler to use
and debug.
Don't care a
whole lot
about that

Brian <as
individual>

-----Original
Message-----

From:
Vincent Chen

Sent:
Monday, August
13, 2012 06:04
PM Eastern
Standard Time

To:    Peter
Stanforth

Cc:    Rosen,
Brian; Teco
Boot; Benjamin
A.Rolfe; [email-masked]

Subject:
Re: [paws] XML
schema versus
JSON, vCard
& iCal

XML vs JSON

Between XML
and JSON, JSON
messages are
more compact
and easier to
process
(parsing,
synthesis). As
clarification,
JSON does not
require
JavaScript or
a Browser. It
is a
text-based
representation
of data that
is language
independent,
yet
well-matched
to all major
languages.
JSON-handling
libraries
exist for
numerous
languages (see
of http://json.org/)
and seem to be
reasonably
light weight.

Timestamps

As for
timestamp
specifications,
should we
consider just
using seconds
since the UNIX
Epoch
(1970-01-01T00:00:00Z)?
This would
eliminate the
need for
datetime-string
parsing on
devices,
assuming
devices
already have
native
libraries that
provide time
in this
format. Is
that a valid
assumption? Of
course, this
is less
human-readable....

On Mon, Aug
13, 2012 at
6:49 AM, Peter

Whenever
we built
mobile devices
we never dealt
with IETF, in
our sensor

days even
an IP stack
was a
challenge,so I
would defer to
the device
guys

on that
one.

On
MonAug/13/12
Mon Aug 13,
9:30 AM,
"Rosen, Brian"

wrote:

>Our
experience in
the IETF over
many years is
that
economizing
message

>size
and
compromising
utility and
security in
search of
efficiency of

>implementation
on small
devices is a
poor trade
off.  I am not
advocating

>being
wasteful of
resources, but
I don't think
we should
seriously

>consider
the overhead
of XML or json
to be
significant.

>Assuming a
json library
can be loaded
on a small
device is
reasonable.

>Brian
(as
individual)

-----Original
Message-----

>From:
Peter
Stanforth
[mailto:[email-masked]]

>Sent:
Saturday,
August 11,
2012 07:13 AM
Eastern
Standard Time

>To:
Teco Boot;
Benjamin
A.Rolfe

>Subject:
Re: [paws]
XML schema
versus JSON,
vCard &
iCal

>Not
all masters
run over the
core network.

>Some
of the Use
cases have a
master talking
to another OTA

>We
should not
assume that
all Masters
are attached
to utility
power so we

>should
be sympathetic
to processing
energy use
also.

>On
SatAug/11/12
Sat Aug 11,
5:30 AM, "Teco
Boot" <[email-masked]>
wrote:

>>Op
10 aug. 2012,
om 18:10 heeft
Benjamin A.
Rolfe het
volgende

Compactness of
messages is
important, but
it is also
important (to
me

>>>at
least) to be
realizable in
an
implementation
with limited
resources,

>>>such
as embedded
devices in
what are now
popularly
called "M2M"

>>>applications.
A lot of these
devices could
use IP all the
end to end,

>>>but
may have a
very compact,
simple stack
and
applications
(i.e.  no

>>>browser).
Is JSON
typically
implemented
when there is
no browser?

>>>Would
it be hard to
do in a
resource
constrained
device (i.e.
where we

>>>talk
about memory
size in
Kilo-bytes
still).

>>In
use cases and
requirements
document,
there are no
requirements
for

>>protocol
performance. I
guess
OS/IP/TCP/TLS
code size
supersedes
needs

>>for
JSON or XML.

>>Same
for timing:
TCP/TLS
connection
setup will
take more than
the PAWS

>>message
exchange, I
think. This
may be of
importance
when using
satcom

>>Because
PAWS runs
between master
and database,
over core
network,

>>performance
is not our
primary
concern. But
as always, it
is good to
keep

>>an
eye on
efficiency.

Thanks

Ben

We had a
discussion on
XML vs. JSON.
I prefer the
one with most

messages.

On vCard and
JSON: what is
the status of
"A JavaScript
Object
Notation

>>>>(JSON)
Representation
for vCard"?

On valid
times: can we
use same
format as
certificates?
They have

>>>>similar
simple
requirements:
valid
notBefore&
notAfter.

Teco

paws mailing
list

paws mailing
list

mailing list

mailing list

paws
mailing list

[email-masked]

--

-vince

paws mailing
list

[email-masked]

paws mailing
list

[email-masked]

--

-vince

paws mailing list

[email-masked]

paws mailing
list

[email-masked]

paws mailing list

[email-masked]

paws mailing list

[email-masked]

paws mailing list

[email-masked]

paws mailing list

[email-masked]

--

-vince

---

From: Paul Lambert <[email-masked]>
Date: Mon, 27 Aug 2012 18:37:12 -0700

Real protocols use TLVs ...

:)

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Friday, August 24, 2012 8:36 PM
To: Manikkoth Sajeev
Cc: [email-masked]
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

Sajeev,

On Fri, Aug 24, 2012 at 8:13 PM, Manikkoth Sajeev <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Best Regards,

Sajeev Manikkoth

-          Gabor

Okay:

What do you do?

Brian

Brian

Ben

I agree with Brian.

-Raj

Brian <as individual>

Hi Ben,

Sounds good to me.

Gabor

--Xinpeng Wei

Brian <as individual>

Hi,

Best Regards,
Sajeev Manikkoth
Mobile: +918792292002

- Gabor

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Rosen, Brian
Sent: Monday, August 13, 2012 3:14 PM
To: 'Vincent Chen'; 'Peter Stanforth'
Cc: [email-masked]<mailto:[email-masked]>'
Subject: Re: [paws] XML schema versus JSON, vCard & iCal

json is okay with me.

Brian <as individual>

-----Original Message-----
From:     Vincent Chen [mailto:[email-masked]<mailto:[email-masked]>]
Sent:    Monday, August 13, 2012 06:04 PM Eastern Standard Time
To:    Peter Stanforth
Cc:    Rosen, Brian; Teco Boot; Benjamin A.Rolfe; [email-masked]<mailto:[email-masked]>
Subject:    Re: [paws] XML schema versus JSON, vCard & iCal

XML vs JSON

Timestamps

--
-vince

--
-vince

paws mailing list

paws mailing list

--
-vince