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

Reply via email to