[apps-discuss] Fw: draft-pbryan-zyp-json-pointer: name syntax for non-ASCII

"t.petch" <ietfc@btconnect.com> Thu, 24 November 2011 18:16 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1D21F8B5E for <apps-discuss@ietfa.amsl.com>; Thu, 24 Nov 2011 10:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.329
X-Spam-Level:
X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l4R4CMyyKy0 for <apps-discuss@ietfa.amsl.com>; Thu, 24 Nov 2011 10:16:18 -0800 (PST)
Received: from mail.btconnect.com (c2bthomr14.btconnect.com [213.123.20.132]) by ietfa.amsl.com (Postfix) with ESMTP id 8A09E21F8B53 for <apps-discuss@ietf.org>; Thu, 24 Nov 2011 10:16:16 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2bthomr14.btconnect.com with SMTP id FGY85532; Thu, 24 Nov 2011 18:13:36 +0000 (GMT)
Message-ID: <092801ccaacc$ada7b000$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: "apps-discuss" <apps-discuss@ietf.org>
Date: Thu, 24 Nov 2011 18:15:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4ECE894F.005C, actions=tag
X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.11.24.173314:17:9.535, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, TO_IN_SUBJECT, __ANY_URI, __CP_URI_IN_BODY, BODY_SIZE_5000_5999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr14.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4ECE89EF.01B4, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Subject: [apps-discuss] Fw: draft-pbryan-zyp-json-pointer: name syntax for non-ASCII
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Nov 2011 18:16:19 -0000

 ---- Original Message -----
 From: "Graham Klyne" <GK@ninebynine.org>
 To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
 Cc: "Mark Nottingham" <mnot@mnot.net>et>; "IETF Apps Discuss"
 <apps-discuss@ietf.org>
 Sent: Tuesday, November 22, 2011 12:26 PM

> I spotted this discussion and was reminded that one of the older URI specs had
> some explicit discussion of characters and octets and encoding.  I recall a
line
> that looked something like this:
>
>    URI characters -> URI octets -> URI octets %-encoded to US-ASCII
>
> but I can no longer find it (quickly).  But
http://www.ietf.org/rfc/rfc3986.txt
> sections 1.2 and section 2 (esp. intro) address some of the issues.  The point
> being that character encoding to octets is a separate concern from %-encoding
to
> URI (or IRI) on-the-wire characters.
>

 My bible for this is RFC2130 which gives

 character->coded character set->character encoding scheme->transfer encoding
 syntax

 which Unicode seemed to get spot on, but HTML and URIs ... um

 Tom Petch

<resent - where did apps-discuss@ietf.org go? >
>
> #g
> --
>
> On 22/11/2011 09:09, "Martin J. Dürst" wrote:
> > On 2011/11/22 8:43, Mark Nottingham wrote:
> >> The usual approach to this sort of thing is to define the "canonical" way
to
> >> do it; i.e., json pointers *are* unicode strings; then you can define
> >> encodings into various environments (like URIs).
> >>
> >> In this case, it'd probably be good enough to say that json pointers are
> >> unicode strings,
> >
> > Up to here, this makes a ton of sense.
> >
> >> but that when they need to be in ASCII environments (like URIs) they get
> >> UTF-8'ed and then percent-escaped.
> >
> > This would mean that e.g. in a Java program that for some reason is kept in
> > US-ASCII, I'd have to use %-encoding. This doesn't make sense to me at all.
> >
> > So I'd say that json pointers are escaped according to the conventions of
the
> > substrate that carries them when needed (e.g. pure ASCII, or other kinds of
> > encodings that can't handle the whole Unicode range).
> >
> > Then for json pointers as fragment identifiers, I'd mention that where
> necessary
> > (e.g. for URIs), the convention for converting from IRIs to URIs (see RFC
> 3987)
> > applies.
> >
> > By the way, I don't see a need to escape "/" at all in a fragment
identifier.
> > "/" is plain and simply allowed in fragment identifiers. Please see
> > http://tools.ietf.org/html/rfc3986#section-3.5. Of course, it's not
forbidden
> to
> > escape "/", so software that is interpreting a fragment identifier has to
make
> > sure it does the right thing.
> >
> > Regards, Martin.
> >
> >
> >> Cheers,
> >>
> >>
> >> On 22/11/2011, at 8:51 AM, Paul C. Bryan wrote:
> >>
> >>> Okay, so I'll write-up separate sections for JSON string values and URI
> >>> fragment identifiers. Any objections?
> >>>
> >>> Paul
> >>>
> >>> On Tue, 2011-11-22 at 07:55 +1100, Mark Nottingham wrote:
> >>>> +1 to Julian here -- there's no reason why non-ASCII chars need to be
> >>>> percent-encoded when they occur inside a JSON document, only when they're
> in
> >>>> a URI (or similar context).
> >>>>
> >>>> Cheers,
> >>>>
> >>>>
> >>>> On 22/11/2011, at 7:12 AM, Julian Reschke wrote:
> >>>>
> >>>>> On 2011-11-21 21:09, Paul C. Bryan wrote:
> >>>>>> The intent is to allow a JSON Pointer to be expressed as a JSON string
> >>>>>> value as well as a URI fragment identifier. The latter is the most
> >>>>>> significant driver for URI percent-encoding.
> >>>>>> ...
> >>>>>
> >>>>> Well, you could use it as fragment identifier (or otherwise URI
component)
> >>>>> by UTF-8-percent-escaping.
> >>>>>
> >>>>> The question is whether that use case requires them to be all ASCII
every
> >>>>> else, such as in a JSON patch document.
> >>>>>
> >>>>> Best regards, Julian
> >>>>> _______________________________________________
> >>>>> apps-discuss mailing list
> >>>>>
> >>>> apps-discuss@ietf.org
> >>>>
> >>>>>
> >>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>
> >>>>
> >>>> --
> >>>> Mark Nottingham
> >>>> http://www.mnot.net/
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> apps-discuss mailing list
> >>> apps-discuss@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>
> >> --
> >> Mark Nottingham http://www.mnot.net/
> >>
> >>
> >>
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>