Subject: [Sedate] About namespaces in timestamp extensions

From: Ujjwal Sharma <[email-masked]>
Date: Tue, 24 Aug 2021 23:51:52 +0530

Hi John, Shane, Mark and all SEDATE WG friends!

Last time during the SEDATE WG session at IETF 111, we had a detailed
discussion about the various syntactic details of the proposed extension
format. John raised some concerns about the potential privacy issues of
being less strict about the information that could be encoded in these
extension tags.

Currently, the draft is written in a way which is very permissive: any
reasonable org could get their own official namespace through the
included IANA process and developers could get their own custom
extensions going via the `x` private namespace. On the other hand, this
decouples the entire discussion about the keys and their values from the
base syntax itself, which has its own set of merits.

The solution on the other end of the spectrum would be to come down to a
small set of keys we all agree make sense and specify these keys and the
valid set of their values within the RFC itself, making the process of
adding additional keys (intentionally) long and difficult.

What do folks think about this? John, am I wording something
incorrectly? Anyone else who has a strong opinion one way or the other?
For the ECMAScript Temporal Champions, the exact syntax doesn't matter
as much as long as both timezones and calendars are allowed.

Ujjwal

-- 
Ujjwal "Ryzokuken" Sharma (he/him)

Compilers Hacker, Node.js Core Collaborator and Speaker

---

From: John C Klensin <[email-masked]>
Date: Tue, 24 Aug 2021 18:00:35 -0400

Shane,

I'm going to ask a question I've asked several times before
about other issues.  While I understand that most of the
development is being done in ECMA, I hope and assume that the
ultimate goal is to move the specification into ISO for
incorporation into ISO 8601, either as a new Part or as an
addition to one of the existing parts.  Because that is the
_only_ way to eliminate the possibility of the a future version
of 8601 evolving in a way that is incompatible with this
extension, if that is not the case, could someone please explain
why not.

Now, if that is the goal, why not incorporate the two keywords
that we know will be needed into the IETF specification and then
work with ECMA and ISO TC 154 to handle additional keywords via
a Registration Authority or Maintenance Agency.  The would have
at least two advantages over doing this as an IANA registry
under IETF supervision:  It would assure coordination with a
future standard rather than requiring a joint effort into the
indefinite future.  And it would place responsibility onto an
ISO TC has is far more sensitive to national and international
conventions than the IETF has seemed able to handle in recent
years.  FWIW, I'm not certain whether, if we were doing BCP 47
for the first time today, we would consider the way that is set
up optimal.

regards,
   john

--On Tuesday, August 24, 2021 16:05 -0500 Shane Carr
<[email-masked]> wrote:

> I feel that having an extension registry similar to the one
> used in BCP-47 would be more future-proof.  But, either
> solution is acceptable for solving the short-term needs of
> ECMA-262.
> 
> If IETF were to decide to bless only the two keys (time zones
> and calendars), implementations still need to reference
> another standard in order to validate whether the time zone or
> calendar ID is valid.
> 
> 
> On Tue, Aug 24, 2021 at 1:22 PM Ujjwal Sharma
> <[email-masked]> wrote:
> 
>> Last time during the SEDATE WG session at IETF 111, we had a
>> detailed discussion about the various syntactic details of
>> the proposed extension format. John raised some concerns
>> about the potential privacy issues of being less strict about
>> the information that could be encoded in these extension tags.
>> 
>> Currently, the draft is written in a way which is very
>> permissive: any reasonable org could get their own official
>> namespace through the included IANA process and developers
>> could get their own custom extensions going via the `x`
>> private namespace. On the other hand, this decouples the
>> entire discussion about the keys and their values from the
>> The solution on the other end of the spectrum would be to
>> come down to a small set of keys we all agree make sense and
>> specify these keys and the valid set of their values within
>> the RFC itself, making the process of adding additional keys
>> (intentionally) long and difficult.
>> 
>> incorrectly? Anyone else who has a strong opinion one way or
>> the other? For the ECMAScript Temporal Champions, the exact
>> syntax doesn't matter as much as long as both timezones and
>> calendars are allowed.
>> 
>> Ujjwal
>> 
>> --

---

From: Ujjwal Sharma <[email-masked]>
Date: Wed, 25 Aug 2021 13:11:38 +0530

Hi John!

On 25/08/2021 03.30, John C Klensin wrote:
> addition to one of the existing parts.
> ...

The "development is being done in ECMA" only to the extent that
ECMAScript aims to be one of the first implementations of this out
there. We made the initial design decisions there but I think now and
moving forwards, all such deliberation should be done here, in the
SEDATE WG, and ECMA is just one of the many stakeholders here.

About collaboration with ISO, that's absolutely something we're working
towards, and discussions around setting up a more formal liason
relationship are already happening.

> a Registration Authority or Maintenance Agency.  

Are you proposing here that the IETF draft should limit itself to those
two keys, removing the part about the IANA registry and a superset
format (most likely ISO) would then include support for more generalized
extensions?

What do others think about this? (cc @Ronald)

I personally feel that this is an acceptable compromise which doesn't
affect Temporal and still leaves the door open to more extensions in the
future. Also, it seems quite similar to the status quo where RFC 3339 is
a stricter subset of ISO 8601.

One question would be: how would this affect the syntax? Since the
timezone is included without a key, it should remain unaffected, but if
we move the "calendar" key out of the Unicode namespace, would it become
"ca" instead of "u-ca"? @John what do you think?

Ujjwal

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 25 Aug 2021 16:33:59 +0200

> What do others think about this? (cc @Ronald)

Since you asked:

I would feel more comfortable if there were an extension point that was under IETF/IANA control.  (Independent of what policy for exercising this extension point — permissive or frugal — we finally arrive at.)

Grüße, Carsten

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 26 Aug 2021 09:25:54 +0900

Hello Shane, John, others,

> that we know will be needed into the IETF specification and then

Yes, it's always a good idea to have actual usage examples for extension 
points, and to start populating the registry.

> years.

There are many different organizations that serve as Registration 
Authority or Maintenance Agency. There would be some "paperwork" needed, 
but I have no doubts that IANA would could do so without problems.

Regards,   Martin.

> FWIW, I'm not certain whether, if we were doing BCP 47

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: John C Klensin <[email-masked]>
Date: Wed, 25 Aug 2021 20:45:09 -0400

--On Thursday, August 26, 2021 09:25 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

>> _only_ way to eliminate the possibility of the a future
>> version of 8601 evolving in a way that is incompatible with
>> this extension, if that is not the case, could someone please
>> explain why not.
>> 
> Yes, it's always a good idea to have actual usage examples for
> extension points, and to start populating the registry.
> 
> 
>> work with ECMA and ISO TC 154 to handle additional keywords
>> via a Registration Authority or Maintenance Agency.  The
>> would have at least two advantages over doing this as an IANA
>> registry under IETF supervision:  It would assure
>> coordination with a future standard rather than requiring a
>> joint effort into the indefinite future.  And it would place
>> responsibility onto an ISO TC has is far more sensitive to
>> national and international conventions than the IETF has
>> seemed able to handle in recent years.
> 
> There are many different organizations that serve as
> Registration Authority or Maintenance Agency. There would be
> some "paperwork" needed, but I have no doubts that IANA would
> could do so without problems.

Indeed, having IANA be the RA or MA would solve the problem I'm
concerned about.  My concern is only about having the RA/MA
function decoupled from change control of the base standard.

   john

---

From: Shane Carr <[email-masked]>
Date: Tue, 24 Aug 2021 16:05:55 -0500

I feel that having an extension registry similar to the one used in BCP-47
would be more future-proof.  But, either solution is acceptable for solving
the short-term needs of ECMA-262.

If IETF were to decide to bless only the two keys (time zones and
calendars), implementations still need to reference another standard in
order to validate whether the time zone or calendar ID is valid.