Ira,
While not being at certain that the strategy in
draft-ietf-core-problem-details-05 is the right one, but being
far less certain that it is not _and_ as someone who have never
been completely sold on RFC 5646, let me address what I think is
your key point. For better or worse, the basic structure of
5646, and references to it and the code tables as BCP 46, is in
very heavy use, not only in a assortment of IETF specs but
elsewhere. There is also an extension mechanism built into that
spec and the other side of "long time since 2009", is that there
have been no demonstrations (or, AFAIK, even strong arguments)
that mechanism is unworkable or insufficient.
I have trouble imagining any issues turning up that would
require or justify a revision to 5646 that would not be forward
compatible from the existing spec. I can imagine a different
explanation of the extension mechanism, standards-track specs
for new extensions or even a consolidated description of them,
and so on. It is every easier for me to imagine an updated or
replacement document that would get rid of the <privateuse> use
of "x-" (following the conclusions of RFC 6648 which probably
should have updated 5646 too), but that mechanism does not
appear to be at issue with the current I-D.
So, are eventual revisions to 5656 likely? I agree with you
that they are, or at least that we should assume that they are.
Are those revisions likely to be sufficiently incompatible with
the use/reference in draft-ietf-core-problem-details-05 (or -06)
to require revision of the final RFC version of that document?
I think that is thoroughly unlikely.
Even if it were more likely, I think it would be more likely to
affect tag 38 or annotations with CBOR tags than this document.
So, at least for my benefit and maybe that of others, could you
explain your concern about BCP 47 revisions and their impact a
bit more precisely?
I have just noticed one problem with how all of this is
expressed in the I-D and don't know whether it is related to
your concern or not. Part of Section 2 says "Language tag and
writing direction information for unadorned text strings are
intended to be obtained from context;...". Even though that
sentence goes on to talk about the use of "base-lang" and
"base-rtl" and Appendix A is referenced in the previous sentence
and elsewhere in that Section, it feels like handwaving,
especially given a long history of problems caused by either
inferring language from short strings or assuming anything not
explicitly identified as English and/or ASCII. So a question
for Carsten and the WG (and maybe you, Ira, and others): is
there any good reason to not require at least the language tag
rather than asking people to guess ("from context")?
thanks,
john
--On Thursday, June 23, 2022 17:08 -0400 Ira McDonald
<blueroofmusic@xxxxxxxxx> wrote:
> Hi Carsten,
>
> I take your point about copying from a given RFC.
>
> But the history of IETF Language Tags is RFC 1766 (1995), RFC
> 3066 (2001), RFC 4646 (2006), and RFC 5646 (2009). It's a
> long time since 2009 and, as Martin noted, there have been a
> variety of proposals for updating language tags in the past 13
> years, so it's reasonably likely that there will be a newer
> version at some point. And since language tags are now quite
> structured, the chance of not needing syntax changes is fairly
> low. This draft RFC from CORE wouldn't catch up quickly,
> presumably.
>
> Cheers,
> - Ira
>
>
>
> *Ira McDonald (Musician / Software Architect)*
>
> *Chair - SAE Trust Anchors and Authentication TF*
> *Co-Chair - TCG Trusted Mobility Solutions WG*
>
> *Co-Chair - TCG Metadata Access Protocol SG*
>
>
>
>
>
>
>
>
> *Chair - Linux Foundation Open Printing WGSecretary -
> IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG
> Internet Printing Protocol WGIETF Designated Expert - IPP &
> Printer MIBBlue Roof Music / High North
> Inchttp://sites.google.com/site/blueroofmusic
> <http://sites.google.com/site/blueroofmusic>http://sites.googl
> e.com/site/highnorthinc
> <http://sites.google.com/site/highnorthinc>mailto:
> blueroofmusic@xxxxxxxxx <blueroofmusic@xxxxxxxxx>(permanent)
> PO Box 221 Grand Marais, MI 49839 906-494-2434*
>
>
> On Thu, Jun 23, 2022 at 2:34 PM Carsten Bormann <cabo@xxxxxxx>
> wrote:
>
>> On 2022-06-23, at 13:13, Ira McDonald
>> <blueroofmusic@xxxxxxxxx> wrote:
>> >
>> > Hi Carsten,
>> >
>> > OK - you need to get this CORE document published quickly.
>>
>> Thank you.
>>
>> > But I still think that detailed CDDL would be a long-term
>> > mistake, for
>> the reason
>> > that Martin cited - i.e., copying/transforming grammars
>> > among RFCs is
>> fragile.
>>
>> Well, the RFC is immutable, so the act of making a copy
>> cannot by itself be fragile.
>>
>> What got us to now propose blunting that grammar is the
>> strong impression that there may be less consensus about the
>> grammar defined by RFC 5646 than we thought. So it seems the
>> grammar in RFC 5646 is fragile, not the act of copying it
>> out...
>>
>> https://github.com/core-wg/core-problem-details/pull/40/commi
>> ts/bbe72e2
>>
>> (I'm making a point about copying here as I believe copying
>> out snippets of CDDL from RFCs and other specifications will
>> be a significant part of CDDL 2.0.)
>>
>> Grüße, Carsten
>>
>>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
