Re: [dispatch] [Sedate] WG Review: Serialising Extended Data About Times and Events (sedate)

[[e-mail]]

I should have discussed ISO 8601 in my original response - my apologies for not
having done so. My (lame) excuse is that I have no good suggestions as to how to
handle it.

First, I take John's point that less is better, and having three specifications
with overlapping goals that are syntactically and semantically inconsistent
would be a really bad outcome.

That said, I'm very concerned by the fact that the revised ISO 8601
specifications are not freely available, and the cost to obtain them is nothing
short of outrageous: 336 CHF ($371 at today's exchange rate). These are also
hugely complex highly technical specifications, IMO incapable of being
summarized in any useful way. This means that anyone wishing to participate in
significant technical discussion involving them is going to need to purchase
copies. This represents a very significant burden to anyone wishing to
participate in the discussion without a corporate sponser willing to bear the
cost.

To be blunt, if the IETF decides that a review of ISO 8601 is required, either
as part of revising RFC 3339 or as part of developing the details of the
informative suffix, and is truly sincere about trying to lower the barriers to
participation in its technical discussions, some sort of arrangement needs to be
made with the ISO to make these documents available to WG participants at
reduced or no cost.

I also note that the current draft contains this requirement for specifications
defining additional suffix information:

*  The specification of valid keys MUST be available over the
   Internet and at no cost.

*  The specification MUST be in the public domain or available via a
   royalty-free license acceptable to the IETF and specified in the
   RFC.

*  The specification MUST be versioned, and each version of the
   specification MUST be numbered, dated, and stable.

These requirements would seem to make incorporation by reference of additional
information specified in ISO 8601-2 very difficult.

On the technical side of things, and ignoring for the moment the possibility of
ISO-8601 inspired changes in RFC 3339 - the only information suffix information
actually defined by the current draft is the ability to specify a time zone
rule:

   time-zone-char = ALPHA / "." / "_"
   time-zone-part = time-zone-char *13(time-zone-char / DIGIT / "-" / "+") ; but not "." or ".."
   time-zone-id   = time-zone-part *("/" time-zone-part)
   time-zone      = "[" time-zone-id "]"

(I note in passing that this ABNF appears to omit the possibility of there being
a tzidprefix as part of the time-zone-id.)

And as it happens, time zone rule specification is, AFAICT, addressed nowhere
in ISO 8601. So the question becomes one of whether ISO 8601 - part 2 in
particular - specifies anything that makes sense to put in the information
suffix.

And the answer to that is some things clearly qualify, some clearly do not,
and others... hard to say.

For example, since we're still describing an instant in time, things
like durations and sets of dates pretty clearly don't fit. Seasons, OTOH,
do fit.

But what about precision? (I don't think the way ISO 8601-2 specifies precision
is going to be particularly useful, but let's ignore that for now.) On the one
hand, this is about specifying an instant in time. On the other hand, things are
rarely that precise. And there's also the not-insignificant fact that precision
is really data, not metadata, so does it belong in the information suffix?

One takeaway here is that the specification needs to be a lot more precise
about what can go in the informative suffix and what can't. It seems to
me that an obvious dividing line is nothing in the suffix can move
the instant in time around, but beyond that things get a little sticky.

Beyond that, it seems clear that any review of ISO 8601-2 is going to get close
to, and may actually cross over into defining additional suffix information.
(Which, FWIW, I think would be a good thing - I think specifications defining
registries are almost always improved by specifying at least one initial entry
in the registry.) But this may be more work that the WG is prepared to do.

				Ned

> FWIW, I completely agree with Ned, especially wrt the issues of
> the confusion and potential interoperability issues associated
> with creating inconsistent standards and terminology.   To
> further complicate things, RFC 3339 is based on on the 1988
> version (or perhaps, given an additional reference that is not
> cited, the 2000 one) of ISO 9601.   There is now a 2019 version
> of ISO 8601, with the scope of the 1988 version extended and
> split into two parts, the second specifically concerned with
> extensions.  Any charter that proposes to tinker with RFC 3339,
> potentially even including incorporating it by reference as Ned
> suggests should have, as its first charter item, a careful
> review of the current version of ISO 8601-1 and 8601-2 to
> understand if, or how, they might affect the rest of the effort.
> Failure to do so could lead us to three inconsistent ways of
> doing things, not just two (which is one too many).

>    john


> --On Tuesday, June 1, 2021 09:43 -0700 [e-mail]
> wrote:

> > I have to object to a working being chartered with this remit.
> >
> > The main problem is that the charter specifies that a variant
> > of RFC 3339 is to be embedded in this new specification, with
> > no consideration given to the alternate approach of
> > incorporating either RFC 3339 or an RFC 3339bis by reference.
> >
> > This really isn't the time or place to get into all of the
> > reasons why incorporation by reference is a much better way to
> > do this, so I'll simply note that even if you ignore the
> > confusion this can cause, having text in two places that
> > describes the same thing has proved to be a maintenance
> > nightmare on many previous occasions.
> >
> > At an absolute minimum the choice of reference versus
> > embedding should be left to the working group, rather than
> > being effectively chosen by the charter, and this needs to be
> > made very clear from the outset.
> >
> > The charter also says that:
> >
> >>     It is anticipated that this document would be a companion
> >>     to RFC3339 rather than a replacement, embedding an
> >>     unaltered RFC3339 instant along with the contextual data.
> >
> > Except the current draft cited as a "good basis" for this work
> > doesn't actually do this. Rather, it preemptively extends RFC
> > 3339 in not one but two ways:
> >
> > (1) Years are extended to six digits
> > (2) Local offsets are extended to allow seconds and fractions
> > of seconds.
> >
> > Given the ability of the metadata (what the draft calls the
> > "informative suffix") to specify complex time zone rules, I
> > question the need for (2), but again, this is neither the time
> > nor the place to get into these sorts of details. The point is
> > that this isn't "an unaltered RFC3339", and if this work were
> > to end up specifying this new format but not updating RFC
> > 3339, we will then have have two incompatible formats for
> > basic timestamps.
> >
> > Another problem is that the current draft makes a number of
> > unnecessary changes to the RFC 3339 ABNF, e.g., full-time
> > becomes time-full, full-date becomes date-full, date-fullyear
> > becomes date-year, etc. Even granting that the new names are
> > in some sense "better", the problem is that other
> > specifications can and do reference specific rules in
> > specifications like RFC 3339, and when you change the the rule
> > names, you complicate the update process for all of these RFCs.
> >
> > Finally, I concur with Carsten Bormann's point about noting
> > that this is exclusively a *text* format for date time values.
> > Simply inserting the word "text" in a couple of places would
> > sufficient. And FWIW, I don't think extending the current
> > charter to cover binary formats is a good idea. If such a
> > thing is to be done, it should be accomplished via a recharter.
> >
> > 				Ned
> >
> >
> >> Hi all,
> >
> >> (CC dispatch for information)
> >
> >> The charter for the Sedate working group has passed the first
> >> phase and is now in external review. Additionally, the sedate
> >> mailing list has been created. Do go over there and subscribe
> >> if you are interested.
> >
> >> Now is the time to let the IESG know of any comment you might
> >> have on the charter text.
> >
> >> I am also looking for volunteers to chair the wg. It is ok to
> >> volunteer someone you think would be a good fit. I hope that,
> >> given the interest in this work, we will not have problems
> >> finding chairs, but as a reminder: please do consider
> >> volunteering if you support this work, as with no chairs
> >> there will be no working group.
> >
> >> Please reply to this thread (dropping the dispatch mailing
> >> list), or send an email to the IESG ([e-mail]), or
> >> directly to me with any comments on the charter, or
> >> volunteering as chair.
> >
> >> Thanks,
> >> Francesca
> >
> >> On 01/06/2021, 16:0䨳㸀㸀 ࠀ