- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Tue, 12 Nov 2013 18:20:39 +0900
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: IETF Discussion <ietf@ietf.org>, www-tag@w3.org, es-discuss <es-discuss@mozilla.org>
On 2013/11/12 16:09, Anne van Kesteren wrote: > To be clear, this is a Last Call comment on > http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-07 The JSON Data > Interchange Format (draft-ietf-json-rfc4627bis-07). > > On Tue, Nov 12, 2013 at 3:01 PM, Anne van Kesteren<annevk@annevk.nl> wrote: >> To improve JSON interoperability the IETF should not define a more >> restricted version of JSON than defined by Ecma-404. >> >> Parsers exist that can parse "42" today and parsers that cannot parse >> "42" today can be meaningfully upgraded to do so too. This would not >> break those parsers, unless they depend on parsing 42 as an error, >> which is a far more unlikely scenario than parsing it as 42 given >> precedence. >> >> (Worth pondering about: what to do about a leading BOM, which >> XMLHttpRequest and browsers allow, but neither IETF nor Ecma-404 >> allow.) If XMLHttpRequest has reasons to continue allowing it, I'd suggest that: 1) It strongly discurages it, and 2) It defines processing as something roughly like a) If the first few bytes look like a BOM, ignore them b) Process the rest according to rfc4627bis or ECMA-404 (whichever works better if they are not in full alignment). That will make sure that variation is confined as locally as possible. Regards, Martin.
Received on Tuesday, 12 November 2013 09:21:30 UTC