Absolutely no and leave it alone On Fri, May 2, 2025, 2:24 PM <oauth-requ...@ietf.org> wrote:
> Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > oauth-requ...@ietf.org > > You can reach the person managing the list at > oauth-ow...@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > Today's Topics: > > 1. Re: [Last-Call] [OAUTH-WG] > draft-ietf-oauth-selective-disclosure-jwt-18 ietf last call Artart review > (Henry S. Thompson) > 2. Re: [Last-Call] [OAUTH-WG] > draft-ietf-oauth-selective-disclosure-jwt-18 ietf last call Artart review > (Carsten Bormann) > 3. [IANA #1416059] expert review for > draft-ietf-oauth-selective-disclosure-jwt (media-type-structured-suffix) > (David Dong via RT) > 4. Re: [Last-Call] draft-ietf-oauth-selective-disclosure-jwt-18 ietf > last call Artart review > (Brian Campbell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 02 May 2025 15:18:00 +0100 > From: "Henry S. Thompson" <h...@inf.ed.ac.uk> > Subject: [OAUTH-WG] Re: [Last-Call] [OAUTH-WG] > draft-ietf-oauth-selective-disclosure-jwt-18 ietf last call Artart > review > To: Carsten Bormann <c...@tzi.org> > Cc: a...@ietf.org, > draft-ietf-oauth-selective-disclosure-jwt....@ietf.org, > last-c...@ietf.org, oauth@ietf.org > Message-ID: <f5b8qnfhzaf....@lochinver.inf.ed.ac.uk> > Content-Type: text/plain; charset=utf-8 > > Carsten Bormann writes: > > > ... > > > For IETF purposes, JSON text is always UTF-8 encoded, so there is no > > difference. > > I don't agree, based on my reading of 8259. It's clear that a single > U+0076 character can occur in "JSON text", but as such that text is > _not_ a byte sequence > > >> The problem you've encountered arises when one tries to illustrate > >> UTF-8 byte sequences in an unambiuous way in, for example, an IETF > >> RFC. > > > > You can always write the whole thing in hex. > > Not in the kind of spec we're discussing here, I would think. > > > But typically that is really needed only in very few places, and I think > we can assume that readers of this document understand JSON at least a > little bit. > > > Apart from that, you can use JSON’s \u escapes (but then you get > > different JSON text). > > Indeed, that's part of what I was trying to make sure is properly > illustrated. > > >> My recommendation is to follow RFC 8259's lead, and use e.g. "%xC3" > >> for that purpose. > > > > Ah, that notation in RFC 8259 is ABNF (STD68), which is completely > > different from JSON instances, and therefore mixing this up is > > highly confusing. > > I do understand that, but I thought it was less confusing than the > intermediary that, as it happens, node.js offers, namely > > '["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]' > > > You are using ABNF in byte mode here (normally we use ABNF to define > sequences of Unicode scalar values). > > In ABNF byte mode, your array above would be: > > > > my-string = "[" %x22 %s"26bc4LT-ac6q2KI6cBW5es" %x22 ", " %x22 > %s"family_name" %x22 ", " %x22 %s"M" %xc3 %xb6 %s"bius" %x22 "]" > > > > That is about as confusing as you can get, so please don’t do that. > > Agreed. > > > (You can write this JSON text as a JSON-encoded JSON text string data > item while staying in ASCII: > > "[\"26bc4LT-ac6q2KI6cBW5es\", \"family_name\", \"M\u00f6bius\"]" > > ) > > Indeed. I had that in an earlier draft of my review, with the comment > "But this is ugly and not particularly helpful. > > ht > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND > e-mail: h...@inf.ed.ac.uk > URL: https://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is forged > spam] > > > ------------------------------ > > Message: 2 > Date: Fri, 2 May 2025 17:31:27 +0200 > From: Carsten Bormann <c...@tzi.org> > Subject: [OAUTH-WG] Re: [Last-Call] [OAUTH-WG] > draft-ietf-oauth-selective-disclosure-jwt-18 ietf last call Artart > review > To: "Henry S. Thompson" <ht=40inf.ed.ac...@dmarc.ietf.org> > Cc: a...@ietf.org, > draft-ietf-oauth-selective-disclosure-jwt....@ietf.org, > last-c...@ietf.org, oauth@ietf.org > Message-ID: <bfe3b2a5-2514-4f1c-ba6b-93a42a079...@tzi.org> > Content-Type: text/plain; charset=utf-8 > > On 2. May 2025, at 16:18, Henry S. Thompson <ht= > 40inf.ed.ac...@dmarc.ietf.org> wrote: > > > > Carsten Bormann writes: > > > >> ... > > > >> For IETF purposes, JSON text is always UTF-8 encoded, so there is no > >> difference. > > > > I don't agree, based on my reading of 8259. It's clear that a single > > U+0076 character can occur in "JSON text", but as such that text is > > _not_ a byte sequence > > JSON (STD90) is phrased in terms of Unicode code points. > You have to read STD63 to find out how the byte sequences are generated > from those code points (and which code points are valid in the first place). > Most implementers have done that reading in the last 25 years or so... > > I don’t think it is the purpose of this specification to regurgitate UTF-8 > and JSON principles. > > >>> The problem you've encountered arises when one tries to illustrate > >>> UTF-8 byte sequences in an unambiuous way in, for example, an IETF > >>> RFC. > >> > >> You can always write the whole thing in hex. > > > > Not in the kind of spec we're discussing here, I would think. > > (Not following, sorry) > > >> But typically that is really needed only in very few places, and I > think we can assume that readers of this document understand JSON at least > a little bit. > > > >> Apart from that, you can use JSON’s \u escapes (but then you get > >> different JSON text). > > > > Indeed, that's part of what I was trying to make sure is properly > > illustrated. > > Again, I don’t think this is necessary, and a single example in hex might > suffice if there really is appetite for adding this. > > > '["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]' > > Oh no. > > Grüße, Carsten > > > ------------------------------ > > Message: 3 > Date: Fri, 02 May 2025 17:35:25 +0000 > From: "David Dong via RT" <drafts-expert-review-comm...@iana.org> > Subject: [OAUTH-WG] [IANA #1416059] expert review for > draft-ietf-oauth-selective-disclosure-jwt > (media-type-structured-suffix) > Cc: dar...@tavis.ca, oauth@ietf.org > Message-ID: <rt-5.0.3-2629436-1746207325-1689.1416059-...@icann.org> > Content-Type: text/plain; charset="utf-8" > > Dear Alexey Melnikov, Darrel Miller (cc: oauth WG), > > Following up on this; as the designated experts for the Structured Syntax > Suffixes registry, can you review the proposed registration in > draft-ietf-oauth-selective-disclosure-jwt-17 for us? Please see: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ > > The due date assigned was April 16th. > > If this is OK, when the IESG approves the document for publication, we'll > make the registration at: > > https://www.iana.org/assignments/media-type-structured-suffix/ > > Unless you ask us to wait for the other reviewer, we’ll act on the first > response we receive. > > With thanks, > > David Dong > IANA Services Sr. Specialist > > > On Fri Apr 25 01:43:19 2025, david.dong wrote: > > Dear Alexey Melnikov, Darrel Miller (cc: oauth WG), > > > > Following up on this; as the designated experts for the Structured > > Syntax Suffixes registry, can you review the proposed registration in > > draft-ietf-oauth-selective-disclosure-jwt-17 for us? Please see: > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-selective- > > disclosure-jwt/ > > > > The due date assigned was April 16th. > > > > If this is OK, when the IESG approves the document for publication, > > we'll make the registration at: > > > > https://www.iana.org/assignments/media-type-structured-suffix/ > > > > Unless you ask us to wait for the other reviewer, we’ll act on the > > first response we receive. > > > > With thanks, > > > > David Dong > > IANA Services Sr. Specialist > > > > > > On Wed Apr 09 19:33:15 2025, david.dong wrote: > > > Dear Alexey Melnikov, Darrel Miller (cc: oauth WG), > > > > > > Following up on this; as the designated experts for the Structured > > > Syntax Suffixes registry, can you review the proposed registration in > > > draft-ietf-oauth-selective-disclosure-jwt-17 for us? Please see: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-selective- > > > disclosure-jwt/ > > > > > > The due date is April 16th. > > > > > > If this is OK, when the IESG approves the document for publication, > > > we'll make the registration at: > > > > > > https://www.iana.org/assignments/media-type-structured-suffix/ > > > > > > Unless you ask us to wait for the other reviewer, we’ll act on the > > > first response we receive. > > > > > > With thanks, > > > > > > David Dong > > > IANA Services Sr. Specialist > > > > > > On Tue Apr 08 12:13:03 2025, bcampb...@pingidentity.com wrote: > > > > Thanks David, > > > > > > > > Just to try and connect the dots on the various pieces here - this > > > > is > > > > the > > > > same Structured Syntax Suffixes request as the last item in [media- > > > > types] > > > > draft-ietf-oauth-selective-disclosure-jwt media types and > > > > structured > > > > syntax > > > > suffix and registration review request > > > > <https://mailarchive.ietf.org/arch/msg/media- > > > > types/IzAcggxgUUlH64bzgk0WN6yB16U/>. > > > > > > > > > > > > On Wed, Apr 2, 2025 at 2:16 PM David Dong via RT < > > > > drafts-expert-review-comm...@iana.org> wrote: > > > > > > > > > Dear Alexey Melnikov, Darrel Miller (cc: oauth WG), > > > > > > > > > > As the designated experts for the Structured Syntax Suffixes > > > > > registry, can > > > > > you review the proposed registration in > > > > > draft-ietf-oauth-selective-disclosure-jwt-17 for us? Please see: > > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-oauth-selective- > > > > > disclosure-jwt/ > > > > > > > > > > The due date is April 16th. > > > > > > > > > > If this is OK, when the IESG approves the document for > > > > > publication, > > > > > we'll > > > > > make the registration at: > > > > > > > > > > https://www.iana.org/assignments/media-type-structured-suffix/ > > > > > > > > > > Unless you ask us to wait for the other reviewer, we’ll act on > > > > > the > > > > > first > > > > > response we receive. > > > > > > > > > > With thanks, > > > > > > > > > > David Dong > > > > > IANA Services Sr. Specialist > > > > > > > > > > _______________________________________________ > > > > > OAuth mailing list -- oauth@ietf.org > > > > > To unsubscribe send an email to oauth-le...@ietf.org > > > > > > > > ------------------------------ > > Message: 4 > Date: Fri, 2 May 2025 12:23:32 -0600 > From: Brian Campbell <bcampb...@pingidentity.com> > Subject: [OAUTH-WG] Re: [Last-Call] > draft-ietf-oauth-selective-disclosure-jwt-18 ietf last call Artart > review > To: Carsten Bormann <c...@tzi.org> > Cc: "Henry S. Thompson" <ht=40inf.ed.ac...@dmarc.ietf.org>, > a...@ietf.org, > draft-ietf-oauth-selective-disclosure-jwt....@ietf.org, > last-c...@ietf.org, oauth@ietf.org > Message-ID: > <CA+k3eCRZFMdr04R9rAqmh9M5upnjN=AhycBPYEkk288Uy4c= > h...@mail.gmail.com> > Content-Type: multipart/alternative; > boundary="000000000000fb913c06342b406d" > > Thank you for the review Henry. And thank you for the engagement on it > Carsten. > > I do appreciate the desire to be precise with language and that it can be > difficult to do so, particularly with respect to various encodings. > Nonetheless, there have been a nontrivial number of implementations already > that have not misunderstood what's required. I would be very reluctant to > make a lot of changes based on a hypothetical misunderstanding. The content > of this thread (to me anyway, who honestly didn't understand large parts of > it), shows the ample opportunities for confusion that come in this area and > I'd like to avoid the risk of introducing new confusion into the document. > That being said, if there are bits of text that are outright wrong or > misleading, those should be corrected. > > On Fri, May 2, 2025 at 9:34 AM Carsten Bormann <c...@tzi.org> wrote: > > > On 2. May 2025, at 16:18, Henry S. Thompson <ht= > > 40inf.ed.ac...@dmarc.ietf.org> wrote: > > > > > > Carsten Bormann writes: > > > > > >> ... > > > > > >> For IETF purposes, JSON text is always UTF-8 encoded, so there is no > > >> difference. > > > > > > I don't agree, based on my reading of 8259. It's clear that a single > > > U+0076 character can occur in "JSON text", but as such that text is > > > _not_ a byte sequence > > > > JSON (STD90) is phrased in terms of Unicode code points. > > You have to read STD63 to find out how the byte sequences are generated > > from those code points (and which code points are valid in the first > place). > > Most implementers have done that reading in the last 25 years or so... > > > > I don’t think it is the purpose of this specification to regurgitate > UTF-8 > > and JSON principles. > > > > >>> The problem you've encountered arises when one tries to illustrate > > >>> UTF-8 byte sequences in an unambiuous way in, for example, an IETF > > >>> RFC. > > >> > > >> You can always write the whole thing in hex. > > > > > > Not in the kind of spec we're discussing here, I would think. > > > > (Not following, sorry) > > > > >> But typically that is really needed only in very few places, and I > > think we can assume that readers of this document understand JSON at > least > > a little bit. > > > > > >> Apart from that, you can use JSON’s \u escapes (but then you get > > >> different JSON text). > > > > > > Indeed, that's part of what I was trying to make sure is properly > > > illustrated. > > > > Again, I don’t think this is necessary, and a single example in hex might > > suffice if there really is appetite for adding this. > > > > > '["_26bc4LT-ac6q2KI6cBW5es", "family_name", "Möbius"]' > > > > Oh no. > > > > Grüße, Carsten > > > > > > -- > _CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from your > computer. Thank you._ > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 4286 bytes > Desc: not available > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > > > ------------------------------ > > End of OAuth Digest, Vol 199, Issue 3 > ************************************* >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org