Ah, thanks for the context; will change it back. On 18/12/2012, at 4:17 AM, Paul C. Bryan <pbryan@xxxxxxxx> wrote: > Incidentally, early (draft-pbryan-json-patch-*) drafts were aligned with JSON; later feedback when adopted by the IETF APPSAWG changed it to binary (starting in draft-ietf-appsawg-json-patch-00). The grounds for this was a consensus that the JSON draft was wrong to have made it 8bit for UTF-8. > > Paul > > On Mon, 2012-12-17 at 14:25 +1100, Mark Nottingham wrote: >> Both fixed in SVN; thanks for the review. >> >> >> On 16/12/2012, at 6:32 PM, Roni Even < >> ron.even.tlv@xxxxxxxxx >> > wrote: >> >> > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < >> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >> >. >> > >> > >> > >> > Please resolve these comments along with any other Last Call comments you may receive. >> > >> > >> > Document: draft-ietf-appsawg-json-patch-08 >> > Reviewer: Roni Even >> > Review Date:2012–12–16 >> > IETF LC End Date: 2012–12–25 >> > IESG Telechat date: 2013-1-10 >> > >> > Summary: This draft is almost ready for publication. >> > >> > >> > Major issues: >> > >> > Minor issues: >> > 1. The document has as the intended status “Informational” while the last call says that the intended status is proposed standard? >> > >> > >> > Nits/editorial comments: >> > >> > • In the IANA section the “Encoding considerations: binary”. I noticed that RFC 4627 has a broader description: >> > “Encoding considerations: 8bit if UTF-8; binary if UTF-16 or UTF-32 >> > JSON may be represented using UTF-8, UTF-16, or UTF-32. When JSON is written in UTF-8, JSON is 8bit compatible. When JSON is written in UTF-16 or UTF-32, the binary content-transfer-encoding must be used.” >> > >> > >> > >> >> -- >> Mark Nottingham >> http://www.mnot.net/ >> >> >> >> >> > -- Mark Nottingham http://www.mnot.net/