[art] Re: [Last-Call] Re: [SPICE] Re: Re: draft-ietf-spice-glue-id-04 ietf last call Artart review

[John C Klensin <[e-mail]>]

Rohan,

I think your comment illustrates where I (and probably Patrik)
disagree with your messages on this subject.  But first, I believe
that, by now, the IETF should be carefully examining every new
identifier system that is intended for worldwide use to determine
whether the characters used by writing systems developed outside
western Europe are needed or whether it is appropriate to stick with
ASCII (or even a restricted subset of ASCII).  Up to that point, I
think all three of us probably agree.  Borrowing a bit from a
non-IETF discussions earlier today, if the decision going to remain
"ASCII only" I even believe the I-D should be required to include an
explanation of that decision and that it is time for the IESG to
start forcing "Internationalization Considerations" on all
identifier-defining documents even if all those sections say is "We
decided to stick with ASCII because anything else is too much
trouble".

However, I think that what Patrik and I are saying in different ways
is that, if you start by specifying syntax, rather than having the WG
understand the issues involved, including the decisions that need to
be made, and having at least preliminary draft text to deal with
them, you just specify syntax, you invite a world of pain and hurt.
That is especially important since there may be interactions between
substantive choices and optimal choices of encoding systems (and
hence syntax).   Even if you say "just do what RFC 3987 IRIs do",
that raises other issues, starting with whether that is really the
best spec to cite for (if I understand the intent of the SPICE work
correctly) in the definition of a URN namespace.  So I am suggesting
that the order of events/ consideration should be:

(1) Decide whether non-ASCII identifiers are going to be allowed.  If
not, preferentially explain why and incorporate the explanation in
the document.  If so...
(2) Sort through the issues associated with such identifiers,
starting with the ones raised by the comparison problem Patrik
mentioned in his latest note but then moving on to other restrictions
(and options) about strings, characters (or code points) to be
allowed, and so on.  The documents I mentioned are a good starting
point to help identify issues and provide some choices.  There has
extensive work in W3C that might provide next-step suggestions or
even a different starting point.   Only when those issues, and the
decisions they imply, are agreed upon and documented in a least
preliminary form,...
(3) Consider options for syntax and, as needed, encoding rules.

While I share Patrik's very strong preference that you not go off and
try to invent something new -- there is enough confusion in this
space already and every new option just adds to the confusion and
increased complexity -- there are multiple options at each of those
steps and more than one might be plausible.  If one starts with
syntax, it will tend to preclude decisions that might have been the
right one.

And, unfortunately, Patrik and I both have scars from attempts to do
this in other ways, including "syntax first, rules and semantics
later" approaches.  So do many others around the IETF.   Let's not
make that mistake again.

   john




--On Thursday, February 12, 2026 17:30 +0100 Rohan Mahy
<[e-mail]> wrote:

> Hi Patrik,
> I am aware that there is plenty more work to be done if we wish to
> go down this path, but without a concrete BNF example, very few
> people were going to understand the flexibility and complexity of
> choosing this path. If we decide we want to do this, I am happy to
> help with the rest. thanks,
> -rohan
> 
> On Thu, 12 Feb 2026, 16:43 Patrik Fältström, <[e-mail]>
> wrote:
> 
>> I have now looked at the change in the BNF, and as John I would
>> say that "that is not good enough". For a change like that to be a
>> solution, arguments are needed why that solves all issues with
>> "equality" between two strings. This regarding comparison, display
>> and sorting.
>> 
>> In short and different words than what John wrote, two unicode
>> strings behave completely different than two ascii strings.
>> 
>> See for example this blog post of mine from July 31, 2008: <
>> https://paftech.se/notes/683/>
>> 
>> My suggestion is because of this to first decide whether these
>> identifiers REALLY need to handle wider charset than ASCII. If
>> that is the case, then look at the various already in the IETF
>> (and elsewhere) created solutions to the very complicated problem
>> that John refer to. Choose one of them, and do not invent
>> something yourself.
>> 
>> And, explain in plain text what "the same" or "equality" means
>> (and not) for two identifiers that might have different content in
>> the form of zeroes and ones, but should be treated as equal for
>> example when being displayed (for phishing situations for example).
>> 
>> Patrik
>> 
>> On 12 Feb 2026, at 16:19, John C Klensin wrote:
>> 
>> > These issues have been (IMO minimally) addressed in RFC 9839,
>> > more
>> extensively (especially for identifiers) in the PRECIS documents
>> (Cf.
>> > at least RFCs 8264-8266), and, as Patrik points out, for domain
>> > names in
>> the IDNA2008 documents (starting with RFCs 5890-5894 and updates
>> to them). Or, if you don't like IETF specs, at least look at
>>  Unicode UAX #31.
>> > 
>> > It may be that none of those exactly meet your needs but,
>> > especially if
>> they don't, experience suggests that you need more specification
>> than "just allow the code points in encoded form" and/or fairly
>> extensive treatment of the issue in the document's Security
>> > Considerations.
>> > 
>> > Procedurally, if any of these changes are to be made, it is
>> > entirely
>> inappropriate to introduce them into the document and approve them
>> as part of, or after, this Last Call -- the document needs to go
>> back to the WG for discussion (and understanding) of the issues
>> and tradeoffs involved with the motivation for the documents
>> mentioned above as one starting point.
>>