Draft: draft-ietf-sedate-datetime-extended

Commentary: Section 3.3 is not yet updated ( but will clearly change a lot ) ( As discussed at IETF 114 ) 
 cc 
 Hi - what are the next steps on this PR ? 
 - Is there any update on this PR ? 
 There is n't yet , but vacation time has officially ended in Europe ... RSN . 
 Looks great ! Thanks for bringing all these edits together . I left one minor comment in case you 'd want to make that change , but also OK to merge if you do n't think it 's needed .
It updates RFC3339 in the specific interpretation of the local offset
"Z", which is no longer understood to "imply that UTC is the
preferred reference point for the specified time"; see update.
RFC3339 states that an offset given as "Z" or "+00:00" implies that
"UTC is the preferred reference point for the specified time".  The
offset "-00:00" is provided as a way to express that "the time in UTC
is known, but the offset to local time is unknown".
This convention mirrors a similar convention for date/time
information in email headers, described in RFC5322 and introduced
earlier in RFC2822.  The latter convention is in actual use, while
the former always was handicapped by the fact that ISO8601 does not
actually allow "-00:00".
Implementations that needed to express the semantics of "-00:00"
therefore tended to use "Z" as a "neutral" offset instead.
This specification updates RFC3339, aligning it with the actual
practice of interpreting the local offset "Z": this is no longer
understood to "imply that UTC is the preferred reference point for
the specified time".
Note that the semantics of the local offset "+00:00" is not updated;
this retains the implication that UTC is the preferred reference
point for the specified time.
Note also that the fact that ISO8601 does not allow "-00:00" as a
local offset reduces the level of interoperability that can be
achieved in using this feature; the present specification however
does not formally deprecate this syntax.  For the intents and
purposes of the present specification, the local offset "Z" can be
used in its place.
However,
all have an internal inconsistency or an unrecognized suffix key/
value, so a recipient MUST treat the IXDTF string as erroneous.
In contrast to this elective use of a suffix tag,
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.
An RFC 3339 timestamp can contain a "time-offset" value that
indicates the offset between local time and UTC (see RFC3339, noting
that update of the present specification updates RFC3339).
The information given in such a "time-offset" value can be
inconsistent with the information provided in a time zone suffix for
an IXDTF timestamp.
For example, a calendar application could store an IXDTF string
representing a far-future meeting in a particular time zone.  If that
time zone's definition is subsequently changed to abolish Daylight
Saving Time, IXDTF strings that were originally consistent may now be
inconsistent.
In case of inconsistent "time-offset" and time zone suffix, if the
critical flag is used on the time zone suffix, an application MUST
act on the inconsistency.  If the critical flag is not used, it MAY
act on the inconsistency.  Acting on the inconsistency may involve
rejecting the timestamp, or resolving the inconsistency via
additional information such as user input and/or programmed behavior.
As per RFC3339 as updated by update, IXDTF timestamps may also forego
indicating local time information in their RFC3339 part.  The IXDTF
timestamps in example-consistent (which represent the same instant in
time as the strings in example-inconsistent) are not inconsistent
because they do not assert any particular local time nor local offset
in their RFC3339 part.  Instead, applications that receive these
strings can base their local offset and local time calculations on
the time zone suffix given, i.e., using the Europe/London time zone
rules.