You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Draft draft-ietf-sedate-datetime-extended from SEDATE WG defines extensions to the timestamp format defined in RFC3339 for representing additional information including a time zone. It also proposes some further keys (identified as experimental) associated to the time information that can be interpreted by consumers of such time information. This can be a powerful artifact when associated to the time scheduler. Moreover, it adds the possibility of declaring the time (and the applicable calendar) in a human friendly manner. Finally. it addresses the problem of inconsistency on the time zone expression.
So I think it would be good to leverage on those capabilities for creating a more powerful scheduling mechanism. This would imply to associate the timing attributes in draft-ma-opsawg-schedule-yang (i.e., “period-start”, “time-zone-identifier”, “period-end”, etc) to the ones in draft-ietf-sedate-datetime-extended.
The text was updated successfully, but these errors were encountered:
I thought that the key clarification in sedate spec is covered in draft-ietf-netmod-rfc6991-bis (see for example time-with-zone-offset). If not, I think it is better to fix this in rfc6991-bis so that this can be leveraged by all modules, including the schedule model. No?
But the extensions defined in draft-ietf-sedate-datetime-extended are not (and will not) in RFC 6991. If those extensions are valuable maybe should be considered here.
define time-zone (already have now), critical-flag, suffix-key and values as parameters inside scheduling groupings, not desirable due to interoperability
Draft draft-ietf-sedate-datetime-extended from SEDATE WG defines extensions to the timestamp format defined in RFC3339 for representing additional information including a time zone. It also proposes some further keys (identified as experimental) associated to the time information that can be interpreted by consumers of such time information. This can be a powerful artifact when associated to the time scheduler. Moreover, it adds the possibility of declaring the time (and the applicable calendar) in a human friendly manner. Finally. it addresses the problem of inconsistency on the time zone expression.
So I think it would be good to leverage on those capabilities for creating a more powerful scheduling mechanism. This would imply to associate the timing attributes in draft-ma-opsawg-schedule-yang (i.e., “period-start”, “time-zone-identifier”, “period-end”, etc) to the ones in draft-ietf-sedate-datetime-extended.
The text was updated successfully, but these errors were encountered: