Re: [Sedate] AD review of draft-ietf-sedate-datetime-extended-07

[Justin Grant <[e-mail]>]

HI Francesca - Thanks so much for this thorough review. I'll respond to
each of your concerns below. All changes discussed below are included in my
latest commit here
https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull/35/commits/89fdda3179b0711c8c268ca69278a5f23e3c446f,
although some of the error-handling improvements were already pending in
one of my earlier commits on the same PR here:
https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended/pull/35
.

> 1. This sort of information does not belong in the abstract, but rather
in a change log.

Removed.

> 2. Please expand TAI

Done.

> 3. There should be some text about error handling.

Added. Take a look at the latest commit and let me know what you think.

> 4. I think there should be more text about what it means to "treat a
string as erroneous" (be it reject the timestamp etc). In practice I think
the document needs more text (even just guidelines or recommendations)
about error handling.

Added.

> > Acting on the inconsistency may involve rejecting the timestamp, or
resolving the inconsistency via additional information such as user input
and/or programmed behavior.

> I would prefer a stronger wording than "may involve", but it is probably
just phrasing.

I clarified the text somewhat in the latest commit, but there is an
intentional difference between error handling for "critical" tags (where
error handling is required) vs. non-critical tags (where error handling is
optional for the application). The former gets a "MUST" in the latest text,
while the latter has a "MAY". There are many valid use cases (including
backwards compatibility with existing applications like Java that have been
using a subset of the IXDTF format for many years) where applications don't
know or care about conflicts in suffix tags. The "MAY" case is helpful for
supporting those applications, while still allowing senders to enforce
error handling via the critical flag if they wish.

Let us know if you're worried about this distinction.

> 5. The document is missing expert guidelines (beyond "the expert is
instructed to ascertain that a basic specification does exist")

This was the only part of your feedback that's not yet addressed in my PR
linked above, because I'm not familiar enough with IANA's registry process
to know what text to write. We'll discuss this at tomorrow's SEDATE meeting
and one of us (probably me) will make a follow-up commit with the new text
after the meeting.

> 6. What is the stability of the [CLDR-CALENDAR] reference? I am concerned
about registering an IANA parameter, u-ca, and have as a reference for
allowed values a github link.

Like #5 above, I'm not familiar enough with the processes for IANA
registries to know the best way to address these concerns. We can discuss
this also at tomorrow's meeting.

Unicode CLDR doesn't use any non-GitHub locations as the source of truth
for their data, although @Ujjwal Sharma <[e-mail]> may have
more information about this.

Note that there are less than 20 valid u-ca calendar IDs and the last one
was added in 2016. How have other RFCs solved this problem of registering a
small number of infrequently-added (and never removed, per CLDR policy) IDs?

> I believe the [CLDR] reference should point to the stable version at the
time of publishing (v-42 right now). The references [TR35] and
[CLDR-CALENDAR] are pointers to github, which are not stable references.

Re: locking the reference at v42, that would be
https://github.com/unicode-org/cldr/blob/release-42/common/bcp47/calendar.xml.
Would it be sufficient to just reference that link?  Or is a GitHub link
problematic, regardless of whether it's floating or version-locked?

Also, if we posted a version-specific link, how would that handle the case
where CLDR adds a new calendar ID in the future? I believe that the intent
of listing u-ca in the RFC was essentially to delegate to CLDR the
authority to add new IDs, but would posting a version-specific link prevent
that?  Or should the RFC text specifically encourage readers to find the
latest version, while also linking to a stable, version-specific link? My
apologies for not knowing the appropriate process for cases like this.

> Additionally I am missing where exactly to look in [TR35] to find the
relevant information.

Looking at the reference to [TR35], I'm not sure why that reference is
valuable in the RFC. @Carsten Bormann <[e-mail]> @Ujjwal Sharma
<[e-mail]> would you be OK to just remove that reference?  The
[CLDR-CALENDAR] link seems self-explanatory enough without dragging in the
complexity of [TR35], but I might be missing something important.

Thanks again,
Justin


On Tue, Mar 21, 2023 at 8:17 AM Francesca Palombini <francesca.palombini=
[e-mail]> wrote:

> Thank you for the work on this document.
>
>
>
> I have several comments, some minor and some which I'd like to see solved
> before the document is progressed to IETF Last Call, specifically 3. and 4.
> about error handling and 6. about references.
>
>
>
> Thanks,
>
> Francesca
>
>
>
> 1. -----
>
>
>
> Abstract:
>
> > The present version (-07) reflects the WGLC comments. In particular,
> information has been added to the Security Considerations section.
>
>
>
> This sort of information does not belong in the abstract, but rather in a
> change log. I expect the authors meant that this should be removed before
> publication, am I right?
>
>
>
> 2. -----
>
>
>
> Section 1.1:
>
> > The use of timescales different from UTC, such as TAI.
>
>
>
> Please expand TAI (see
> https://www.rfc-editor.org/materials/abbrev.expansion.txt for list of
> abbreviations that do not need to be expanded).
>
>
>
> 3. -----
>
>
>
> Section 3.1:
>
> > I'd rather place a MUST NOT for this case, first. This definitely needs
> to be expanded into some general text about error handling.--- cabo
>
>
>
> Some leftover comments from Carsten - with whom I agree. There should be
> some text about error handling.
>
>
>
> 4. -----
>
>
>
> Section 3.3:
>
> > each have an internal inconsistency or an unrecognized suffix key/value
> that are marked as critical, so a recipient MUST treat the IXDTF string as
> erroneous.
>
>
>
> I think there should be more text about what it means to "treat a string
> as erroneous" (be it reject the timestamp etc). In practice I think the
> document needs more text (even just guidelines or recommendations) about
> error handling.
>
>
>
> Reading further, I see that section 3.4 has some text about that:
>
>
>
> > Acting on the inconsistency may involve rejecting the timestamp, or
> resolving the inconsistency via additional information such as user input
> and/or programmed behavior.
>
>
>
> I would prefer a stronger wording than "may involve", but it is probably
> just phrasing.
>
>
>
> 5. -----
>
>
>
> Section 6:
>
> > The registration policy [RFC8126] is "Specification Required" for
> permanent entries, and "Expert Review" for provisional ones.
>
>
>
> The document is missing expert guidelines (beyond "the expert is
> instructed to ascertain that a basic specification does exist"), see RFC
> 8126:
>
>
>
>    The required documentation and review criteria, giving clear guidance
>
>    to the designated expert, should be provided when defining the
>
>    registry.  **It is particularly important to lay out what should be
>
>    considered when performing an evaluation and reasons for rejecting a
>
>    request.**  It is also a good idea to include, when possible, a sense
>
>    of whether many registrations are expected over time, or if the
>
>    registry is expected to be updated infrequently or in exceptional
>
>    circumstances only.
>
>
>
> 6. -----
>
>
>
> References
>
>
>
> What is the stability of the [CLDR-CALENDAR] reference? I am concerned
> about registering an IANA parameter, u-ca, and have as a reference for
> allowed values a github link. I believe the [CLDR] reference should point
> to the stable version at the time of publishing (v-42 right now). The
> references [TR35] and [CLDR-CALENDAR] are pointers to github, which are not
> stable references. Additionally I am missing where exactly to look in
> [TR35] to find the relevant information.
>
>
>
> I also would like to argue that the reference for allowed values of an
> IANA registered parameter should be normative, not informative.
> --
> Sedate mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sedate
>