Skip to main content

JSCalendar: A JSON Representation of Calendar Data
draft-ietf-calext-jscalendar-32

Revision differences

Document history

Date Rev. By Action
2021-07-14
32 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-06-09
32 (System) RFC Editor state changed to AUTH48 from IESG
2021-06-01
32 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-05-28
32 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-05-28
32 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-calext-jscalendar-32. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-calext-jscalendar-32. If any part of this review is inaccurate, please let us know.

IANA understands that the actions in the IANA considerations section of this document have been completed. First, in the application namespace on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

we've added the following entry:

Name: jscalendar+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the JSCalendar Properties registry. An initial version of the registry was created in advance of approval of this draft on the JSCalendar registry page located at:

https://www.iana.org/assignments/jscalendar/

The registration procedure for the new registry is Expert Review as defined in RFC 8126.

Upon approval of this draft, the reference for the registry and for all initial items in the registry will be changed from:

[RFC-ietf-calext-jscalendar-32]

to:

[ RFC-to-be ]

IANA has compared Section 8.2.6 of the current draft with the existing registrations on the JSCalendar registry page located at:

https://www.iana.org/assignments/jscalendar/

and found that there are no changes to be made to the existing registrations other than the revisions to the references.

Third, a new registry is to be created called the JSCalendar Types registry. An initial version of the registry was created in advance of approval of this draft on the JSCalendar registry page located at:

https://www.iana.org/assignments/jscalendar/

The registration procedure for the new registry is Expert Review as defined in RFC 8126.

Upon approval of this draft, the reference for the registry and for all initial items in the registry will be changed from:

[RFC-ietf-calext-jscalendar-32]

to:

[ RFC-to-be ]

IANA has compared Section 8.3.2 of the current draft with the existing registrations on the JSCalendar registry page located at:

https://www.iana.org/assignments/jscalendar/

and found that there are no changes to be made to the existing registrations other than the revisions to the references.

Fourth, a set of related new registries are to be created on the JSCalendar registry page located at:

https://www.iana.org/assignments/jscalendar/

The set of related new registries are:

JSCalendar Enum Values
JSCalendar Enum Values for action (Context: Alert)
JSCalendar Enum Values for display (Context: Link)
JSCalendar Enum Values for freeBusyStatus (Context: JSEvent, JSTask)
JSCalendar Enum Values for kind (Context: Participant)
JSCalendar Enum Values for participationStatus (Context: Participant)
JSCalendar Enum Values for privacy (Context: JSEvent, JSTask)
JSCalendar Enum Values for progress (Context: JSTask, Participant)
JSCalendar Enum Values for relation (Context: Relation)
JSCalendar Enum Values for relativeTo (Context: OffsetTrigger, Location)
JSCalendar Enum Values for roles (Context: Participant)
JSCalendar Enum Values for scheduleAgent (Context: Participant)
JSCalendar Enum Values for status (Context: JSEvent)

Each of these new registries is to be managed via Expert Review as defined in RFC 8126.

An initial version of each of these registries was created in advance of approval of this draft on the JSCalendar registry page.

Upon approval of this draft, the references for each of these registries and for all initial items in each of the registries will be changed from:

[RFC-ietf-calext-jscalendar-32]

to:

[ RFC-to-be ]

IANA has compared Section 8.4.3 of the current draft with the existing registrations on the JSCalendar registry page located at:

https://www.iana.org/assignments/jscalendar/

and found that there are no changes to be made to the existing registrations other than the revisions to the references.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2021-05-18
32 (System) RFC Editor state changed to IESG from AUTH48
2021-05-18
32 Amy Vezza
The following Last Call announcement was sent out (ends 2021-06-01):

From: The IESG
To: IETF-Announce
CC: Daniel Migault , calext-chairs@ietf.org, calsify@ietf.org, daniel.migaultf@ericsson.com, …
The following Last Call announcement was sent out (ends 2021-06-01):

From: The IESG
To: IETF-Announce
CC: Daniel Migault , calext-chairs@ietf.org, calsify@ietf.org, daniel.migaultf@ericsson.com, draft-ietf-calext-jscalendar@ietf.org, francesca.palombini@ericsson.com
Reply-To: last-call@ietf.org
Sender:
Subject: SECOND Last Call:  (JSCalendar: A JSON representation of calendar data) to Proposed Standard


The IESG has received a request from the Calendaring Extensions WG (calext)
to consider the following document: - 'JSCalendar: A JSON representation of
calendar data'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

This second last call is specifically on the following diff:

https://www.rfc-editor.org/authors/rfc8984-ad2-diff.html

And on the following technical additions to the document:

* "features" in section 4.2.6
* "recurrenceIdTimeZone" in section 4.3.2
* "sentBy" in section 4.4.5. and 4.4.6
* "requestStatus" in 4.4.7
* as a consequence, updates to the IANA registries in 8.2.6 and 8.4.3.

The document was with the RFC Editor since November 2020. However, last minute implementation attempts found some edge cases of incompatibility between jscalendar and icalendar data models, which resulted in wg discussion and the changes above. The additions were discussed extensively at IETF 110 and confirmed during a following interim.

Abstract


  This specification defines a data model and JSON representation of
  calendar data that can be used for storage and data exchange in a
  calendaring and scheduling environment.  It aims to be an alternative
  and, over time, successor to the widely deployed iCalendar data
  format, and to be unambiguous, extendable, and simple to process.  In
  contrast to the jCal format, which is also JSON-based, JSCalendar is
  not a direct mapping from iCalendar, but defines the data model
  independently and expands semantics where appropriate.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/



No IPR declarations have been submitted directly on this I-D.




2021-05-18
32 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-05-18
32 Francesca Palombini Last call announcement was changed
2021-05-18
32 Amy Vezza Last call was requested
2021-05-18
32 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-05-18
32 Amy Vezza IESG state changed to Last Call Requested from RFC Ed Queue
2021-05-18
32 Amy Vezza Last call announcement was changed
2021-05-18
32 Amy Vezza Last call announcement was generated
2021-05-18
32 Amy Vezza Shepherding AD changed to Francesca Palombini
2021-05-12
32 Amy Vezza Last call announcement was generated
2021-04-14
32 Bron Gondwana Added to session: interim-2021-calext-01
2021-04-14
32 Bron Gondwana Added to session: interim-2021-jmap-01
2021-03-01
32 Bron Gondwana Added to session: IETF-110: calext  Wed-1530
2021-02-12
32 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2021-01-19
32 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-12-01
32 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-12-01
32 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-12-01
32 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-11-25
32 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-11-19
32 (System) RFC Editor state changed to EDIT
2020-11-19
32 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-11-19
32 (System) Announcement was received by RFC Editor
2020-11-19
32 (System) IANA Action state changed to In Progress
2020-11-19
32 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-11-19
32 Cindy Morgan IESG has approved the document
2020-11-19
32 Cindy Morgan Closed "Approve" ballot
2020-11-19
32 Cindy Morgan Ballot approval text was generated
2020-11-19
32 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-10-16
32 Phillip Hallam-Baker Request for Telechat review by SECDIR Completed: Ready. Reviewer: Phillip Hallam-Baker. Sent review to list.
2020-10-15
32 Neil Jenkins New version available: draft-ietf-calext-jscalendar-32.txt
2020-10-15
32 (System) New version approved
2020-10-15
32 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Robert Stepanek
2020-10-15
32 Neil Jenkins Uploaded new revision
2020-10-13
31 Benjamin Kaduk
[Ballot comment]
Section 1.4.8

  Where "TimeZoneId" is given as a data type, it means a "String" that
  is either a time zone name …
[Ballot comment]
Section 1.4.8

  Where "TimeZoneId" is given as a data type, it means a "String" that
  is either a time zone name in the IANA Time Zone Database [TZDB] or a
  custom time zone identifier in the "timeZones" property (see
  Section 4.7.2).

(nit?) I'd suggest 'custom time zone identifier defined in the
"timeZones" property'.

Section 4.7.1

  floating time.  This is either a name from the IANA Time Zone
  Database [TZDB] or the id of a custom time zone from the "timeZones"
  property (Section 4.7.2).  If omitted, this MUST be presumed to be

I think we probably want to say "the TimeZoneID of a custom time zone"
here since there seems to only be a colloquial tie between "id" and that
type.

Section 4.7.2

      Maps the TZNAME properties from iCalendar to a JSON set.  The set
      is represented as an object, with the keys being the names
      (excluding any "tznparam" component from iCalendar).  The value
      for each key in the map MUST be true.

I suggest moving the parenthetical to being offset by a comma -- it's a
normative requirement, not an aside.

Section 6.8

It looks like the change in location Id for the virtualLocation entry
was unintentional, since the localizations property contains a patch
object that still references the old Id.  (This would qualify as a
Discuss-level internal inconsistency but I am confident that the right
thing will happen.)

Section 7

  behavior within a known time window.  It's transmission and storage

nit: s/It's/Its/
2020-10-13
31 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-09-30
31 Roman Danyliw [Ballot comment]
Thank you for responding to the SECDIR review (and thank you to Phillip Hallam-Baker for doing it).

Thank you for resolving my COMMENTs.
2020-09-30
31 Roman Danyliw Ballot comment text updated for Roman Danyliw
2020-09-29
31 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-09-29
31 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-09-29
31 Neil Jenkins New version available: draft-ietf-calext-jscalendar-31.txt
2020-09-29
31 (System) New version approved
2020-09-29
31 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Robert Stepanek
2020-09-29
31 Neil Jenkins Uploaded new revision
2020-09-24
30 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-09-24
30 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-09-24
30 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-09-24
30 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-09-24
30 Murray Kucherawy
[Ballot comment]
I'm late on my reviews this week, and my colleagues have been mighty thorough, so I'll be blissfully brief.

To assuage some of …
[Ballot comment]
I'm late on my reviews this week, and my colleagues have been mighty thorough, so I'll be blissfully brief.

To assuage some of the IESG's concerns about iCalendar and jCal, could we maybe include one of those Implementation Status sections?

Nice job on the IANA section here.

[For the IESG] How common is it to have a working group be the point of contact for a new registry?  What do we normally do if such a working group were to close?  I scanned RFC 8126 (rather quickly, I admit) and didn't see any guidance in there about this.

In Section 4.1.4, there's "SHOULD ensure that this is a globally unique identifier".  Why might an implementation choose not to do so (which SHOULD allows)?

All of the SHOULDs in 4.5.2 have me asking the same sort of thing: When would one not do this?  One way out here is to just drop the SHOULDs and say something like:

CURRENT:

The Relation object SHOULD set the "parent" relation type.

NEW:

The Relation object sets the "parent" relation type.
2020-09-24
30 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-09-23
30 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-09-23
30 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-09-23
30 Warren Kumari
[Ballot comment]
Thank you for writing this document -- as someone who has written (horrible!) code to try and generate and parse iCalendar data, this …
[Ballot comment]
Thank you for writing this document -- as someone who has written (horrible!) code to try and generate and parse iCalendar data, this seem like a very useful effort.
Like Eric I'm concerned about the https://xkcd.com/927/  effect, but I also feel that this standard might be more usable than the existing one(s). I suspect that it is much too early to think about Obsoleting jCal (although I must admit I've never run into jCal, so I have no idea if it is actually being used).

I think that it would be useful to have some more discussions around why / when PatchObjects should be used - they seem to add significant complexity to the design, and I'm really not convinced that the complexity outweighs the benefit; I'm guessing that I'm simply not fully understanding their utility. More examples would probably help...

Thanks again!
W
2020-09-23
30 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-09-23
30 Robert Wilton
[Ballot comment]
Hi,

Thank you for this document.  I appreciate the effort to fix iCalendar and jCal, but also support Ben's questions regarding how this …
[Ballot comment]
Hi,

Thank you for this document.  I appreciate the effort to fix iCalendar and jCal, but also support Ben's questions regarding how this document relates to the iCalendar and jCal documents.  It seems that at least obsoleting jCal might be a good idea.

Ben's detailed review also seemed to throw up quite a lot of comments/clarifications, hence I have a slight concern about how robust the jsCalendar specification is.  The shepherd write up also doesn't seem to note what level of review has been received on this document.  The document states that it aims to fix the bugs in iCalendar because they cannot be fixed without breaking existing implementations.  I trust that the authors and WG are confident that history is not about to repeat itself ...

Regards,
Rob
2020-09-23
30 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-09-22
30 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-09-22
30 Benjamin Kaduk
[Ballot discuss]
Thanks for this document; it's generally in good shape even though I do want
to discuss a few specific points.

(1) I'm a …
[Ballot discuss]
Thanks for this document; it's generally in good shape even though I do want
to discuss a few specific points.

(1) I'm a bit confused by the indication that we can use linkIds to link to
a vCard representation of a participant or location -- if I understand
correctly that representation would occupy the "description" property of
the linked object, but the "description" is (at least for locations)
supposed to be "human-readable", which is perhaps only debatably an apt
description of a vCard object.

(2) Given the language in Section 1.4.7 about needing to denote on a
per-object basis when Ids have semantic meaning outside of the object in
which they are defined, I think we need a stronger/clearer statement in
Section 4.2.5 that the location Ids have global semantics within a
calendar, Section 4.4.5 that participant Ids have global semantics,
within a calendar, etc.  (My preference would be to reverse the sense of
the language in §1.4.7 rather than add language to each instance of Ids
with global semantics; see COMMENT.)

(3) We may want to discuss the scheduleSequence semantics/usability in the
face of a user/"participant" that has multiple clients.  It seems to me
that there is not much preventing the different clients from sending
(different) responses that use the same sequence number, and I'm also
not sure whether the client is supposed to keep local state on what
sequence number to use next or just to increment any value received from
the server.

(4) I strongly recommend that all the examples not reuse UUIDs for different
things (e.g., I see "2a358cee-6489-4f14-a57f-c104db4dc2f1" as all of:
simple event, location (FRA Airport), location (Math lab room 1),
location (Big Auditorium), and virtualLocation (ChatMe).  The Section
6.9 example at least rises to Discuss-level (IIUC) as inconsistent with
the protocol requirements, since the location id is used for two
different locations in sibling events.

(5) Additionally, the Section 6.3 example seems malformed, since the
"entries" array contains as its second element a key/value pair, not a
(jstask) object.  (Erik noted this as a Comment-level point, it seems,
so this is more a note to myself to confirm that it's fixed than
informing you of the issue.)

(6) Can we briefly discuss the use of the "/" character in time zone
identifiers in §4.7.2?  Specifically, this text:

  o  It MUST start with the "/" character (ASCII decimal 47; also see
      Sections 3.2.19 of [RFC5545] and 3.6. of [RFC7808] for discussion
      of the forward slash character in time zone identifiers).

(a) I see no discussion of the forward slash character in section 3.6 of RFC
7808
.

(b) Also, Section 3.2.19 of RFC 5545 seems to basically be saying "there
might one day be one (or more!) global registry for time zones, but we
don't know of one and can't point you to it" ... is this really the
semantics we want to continue to enshrine?
2020-09-22
30 Benjamin Kaduk
[Ballot comment]
If this is "successor to iCalendar", is an Obsoletes: relationship
appropriate?

What is the status of jCal (RFC 7265) now that …
[Ballot comment]
If this is "successor to iCalendar", is an Obsoletes: relationship
appropriate?

What is the status of jCal (RFC 7265) now that this work is published?
Should jCal be moved to Historic?

There's a lot of stuff in the section-by-section comments (including
many nits, which hopefully are not too distracting from the substantive
ones); I do want to specifically call out my notes on the media-type
registration's interoperability considerations as noteworthy.  I'd also
request some extra attention be paid to the examples; I have a few
comments (as well as the discuss point) but am not exactly a JSON expert
and there may be other potential issues lurking.

It is perhaps unfortunate that no internationalization directorate
review was requested.

Section 1

  o  The data model should be compatible with the iCalendar data format
      [RFC5545] [RFC7986] and extensions, but the specification should
      add new attributes where the iCalendar format currently lacks
      expressivity, and drop seldom-used, obsolete, or redundant

Should this perhaps be downgraded to "generally compatible", since we go
on to discuss specific areas of incompatibility?

Section 1.3

If we're going to use JMAP as justification for (e.g.) the "A[B]"
notation, should we mention our underlying inspiration as stemming from
JMAP, somewhere?  (I have similar sentiments to the gen-art reviewer,
and apparently did not pay close enough attention to the change when it
happened in JMAP, which was possibly introduced as a result of my
comments on draft-ietf-jmap-core-14...)

Section 1.4.3

  This is a string in [RFC3339] "date-time" format, with the further
  restrictions that any letters MUST be in uppercase, the time

Just to check: this means that in general we expect implementations to
reject as malformed strings that use lowercase 't' or 'z'?

  component MUST be included and the time offset MUST be the character
  "Z".  [...]

(nit) AFAICT including the time component is already required just by
using the "date-time" construction, since the "full-time" part is not
optional.

Section 1.4.4

  A time zone may have a period of discontinuity, for example a change
  from standard time to daylight-savings time.  When converting local
  date-times that fall in the discontinuity to UTC, the offset before
  the transition is used.

Does this mean that there are certain instants in time that are
un-representable in this format in that timezone?  (Presumably UTC could
still be used to represent that absolute time if needed, though that
seems slightly at odds with the general goal of being able to use local
time for local events.)

Section 1.4.5

If we are not going to require that (e.g.) the specified seconds value
is not more than 60, we may want to put in some security considerations
about handling such nominally out-of-range values.

      duration    = "P" (dur-cal [dur-time] / dur-cal / dur-time)

The middle "dur-cal" seems redundant to me.

  1.  Add any week or day components of the duration to the date.

A week is always 7 days, even if a day is not always 24 hours, right?

Section 1.4.7

  Unless otherwise specified, Ids are arbitrary and only have meaning
  within the object where they are being used.  Ids need not be unique

Letting the Id be non-unique across objects seems to be a substantial
divergence from JMAP and the discussion in the document doesn't help me
understand the motivation for that divergence.  (If we said something
along the lines of "JSCalendar's uid is more analogous to the JMAP Id
than the JSCalendar Id is", that would have helped.) What goes wrong if
we try to use the RFC 8620 semantics ("[t]he id of a record is immutable
and assigned by the server.  The id MUST be unique among all records of
the *same type* within the *same account*")?  Or is "the object where
they are being used" intended to refer to the type of the object and not
the specific object itself?  (The guidance from
https://tools.ietf.org/html/rfc8620#section-1.2 on defensive allocation
strategies might be apropos as well.)

I would also appreciate some indication of whether the Id is always
server-assigned, in this section.

Personally, I would rewrite this whole paragraph along the lines of:

% In many places in JSCalendar a JSON map is used where the map keys are
% of type Id and the map values are all the same type of object.  This
% construction has similar semantics to a list of objects, with the
% advantage that it allows for the set of objects in question to be
% named (by the corresponding map key); this, in turn, allows for more
% concise patch objects and, when applicable, for the objects in
% question to be referenced from other calendar objects.  In some cases
% there is no need for references from external objects, so the Ids in
% question only have defined semantics within the specific object in
% which they appear; these cases are noted when they occur.  In all
% cases, however, Ids are server-assigned and immutable. 

but I recognize that sometimes my editorial ideas are strange, and you
are free to ignore my suggestion entirely -- I won't mind.

Section 1.4.8

The first three items in this list seem semantically equivalent to those
in RFC 8620 for the JMAP PatchObject; would it make sense to reuse the
text verbatim?  (Similarly for the "value associated with each pointer"
text.)

  A PatchObject does not define its own "@type" property.  A "@type"
  property in a patch MUST be handled as any other patched property
  value.

A forward reference for "@type" might be in order (at least, in the
absence of a reference to JMAP as inspiration in the introductory
material).

Section 1.4.9

  By default, time zones in JSCalendar are identified by their names in
  the IANA Time Zone Database [TZDB], and the zone rules of the
  respective zone records apply.

  Implementations MAY embed the definitions of custom time zones in the
  "timeZones" property (see Section 4.7.2).

The wording about "by default" leaves me wondering if the custom time
zones are allowed to override IANA TZDB time zones.

Section 1.4.10

      Keys in the set MUST be one of the following values, or specified
      in the property definition where the Relation object is used, or a
      value registered in the IANA JSCalendar Enum Registry, or a
      vendor-specific value:

(side note) I'd consider reiterating that "vendor-specific values"
require the domain-name-plus-colon prefix, to clarify that there is an
actual restriction in the "MUST".  (Similar language appears elsewhere
in the document, too.)  Also, in other places where we have a similar
requirement (e.g., §4.2.5) we specify the handling for an unrecognized
value, which might be worth doing here as well.

    The value for each key in the set MUST be true.

We have similar language in §4.2.5 describing locationTypes, where we
refer to it as a "map" rather than a "set"; it might be good to use
consistent terminology.

Section 3

  A JSCalendar object is a JSON object, which MUST be valid I-JSON (a
  stricter subset of JSON), as specified in [RFC8259].  Property names
  and values are case-sensitive.

(editorial) The location of "as specified in" binds to I-JSON but the
reference is just for JSON.

Section 3.2

  Considering this, the definition of equivalence and normalization is
  left to client and server implementations and to be negotiated by a
  calendar exchange protocol or defined elsewhere.

Did we consider providing well-written specifications for a few "common
options" that a consuming protocol could select from by reference,
saving applications from needing to duplicate work in each application?

Section 4.1.4

Perhaps it's obvious, but it seems like we're relying on the client to
supply an honest value for the product ID, and the server has no way of
verifying or validating that submission.

  The vendor of the implementation SHOULD ensure that this is a
  globally unique identifier, using some technique such as an FPI
  value, as defined in [ISO.9070.1991].  It MUST only use characters of
  an iCalendar TEXT data value (see Section 3.3.11 of [RFC5545]).

[Hmm, normatively referencing iCalendar for allowed characters makes it
hard to obsolete iCalendar as well...inlining the definition in this
document would make it more of a "standalone" document, if that's
desired.]

  For example, it is not to be used to further the understanding of
  non-standard properties, a practice that is knows to cause long-term
  interoperability problems.

nit: s/knows/known/

Section 4.1.5

I think someone else asked about whether a patch that only updates
"updated" without setting "created" is to be considered invalid; it
might be worth reiterating that here.

Section 4.2.5

  A map of location ids to Location objects, representing locations
  associated with the object.

A brief survey of similar usage in this document suggests that we
generally prefer "[map|set] of  ids to  objects", but
there's at least one case where we just talk about "map of ids to
objects"; it would be good to make a pass to ensure consistency.

Section 4.2.6

      This may be a telephone number (represented using the "tel:"
      scheme, e.g., "tel:+1-555-555-555") for a teleconference, a web
      address for online chat, or any custom URI.

nit: one more '5' for a valid country-code 1 phone number.

Section 4.2.10

I don't think I understand why the "http" scheme is used in the example
categories; these feel in some sense more like URI than URL specifically.

Section 4.3.2

  A JSTask recurs by applying the recurrence rules to the "start" date-
  time, if defined, otherwise it recurs by the "due" date-time, if
  defined.  If the task defines neither a "start" nor "due" date-time,
  it MUST NOT define a "recurrenceRules" property.

I think that Phill's secdir review comment about addressing time zones
and daylight savings could be addressed by calling out more explicitly
here that the "start"/"due" times here have an associated time zone, and
that when converting the recurring events into other time zones the time
zone transitions in both the "to" and "from" time zones (if any) need to
be taken into account.

      The calendar system in which this recurrence rule operates, in
      lowercase.  This MUST be either a CLDR-registered calendar system
      name [CLDR], or a vendor-specific value.

I trust that CLDR guarantees that calendar-system names will not be
registered that differ only in case.

  o  bySetPosition: "Int[]" (optional)

      The occurrences within the recurrence interval to include in the
      final results.  Negative values offset from the end of the list of
      occurrences.  The array MUST have at least one entry if included.
      This is the BYSETPOS part from iCalendar.

(side note) huh, a literal reading of the RFC 5545 ABNF seems to limit
the potential indices here to (+/-) 1 to 366, which seems inadvertent.
I'm glad to see that we don't repeat that here!

Section 4.3.2.1

  2.  Each date-time candidate is compared against all of the byX
      properties of the rule except bySetPosition.  If any property in
      the rule does not match the date-time, it is eliminated.  Each

nit: I'd suggest clarifyint that the "it" that is eliminated is the
date-time, not the property in the rule.

      3.  If any valid date produced after applying the skip is already
          a candidate, eliminate the duplicate.  (For example after
          adjusting, 30th February and 31st February would both become
          the same "real" date, so one is eliminated as a duplicate.)

(nit) I can't decide if this should be "one" or "at least one".  I guess
this could have some interaction with step (5) below ("eliminate any
date-times that have already been produced by previous iterations of the
algorithm").

Section 4.3.4

  If the patch object defines the "excluded" property value to be true,
  then the recurring calendar object does not occur at the recurrence
  id date-time (like an EXDATE from iCalendar).  Such a patch object
  MUST NOT patch any other property.

I'd consider specifying which object the "excluded" property value would
be defined in, as opposed to the current state which is a little vague
(it could be anywhere).

  A pointer in the PatchObject MUST be ignored if it starts with one of
  the following prefixes:
  [...]

I'm not sure I understand why prodId is included in this list.  It seems
to preclude indicating that a different product was used to put in an
override than was used to create the initial recurrence.

Also, just to check: it's intentional to allow for
"excludedRecurrenceRules" and "excluded" to be patch-able?

If there is a vendor-specific or future-defined property that should get
similar treatment, how would that fact be communicated to implementors?

Section 4.3.5

  Defines if this object is an overridden, excluded instance of a
  recurring JSCalendar object (see Section 4.3.4).  If this property
  value is true, this calendar object instance MUST be removed from the
  occurrence expansion.  The absence of this property or its default
  value false indicates that this instance MUST be included in the
  occurrence expansion.

nit: I think commas around and an added word for "or the presence of its
default value false" are in order, as the current text seems to parse to
"the absence of its default value false".

Section 4.4.3

  This property MUST NOT affect the information sent to scheduled
  participants; it is only interpreted when the object is shared as
  part of a shared calendar.

(Where is "shared calendar" defined?)

  o  "private": The details of the object are hidden; only the basic
      time and metadata is shared.  The following properties MAY be
      shared, any other properties MUST NOT be shared:

I guess the idea is that if we want to add/remove things from this list
we'll just register a new enum value?

Section 4.4.4

  Represents methods by which participants may submit their RSVP
  response to the organizer of the calendar object.  The keys in the

Given that we don't seem to define a direct analogue for the iCalendar
RSVP parameter (at least, not that mentions that name), it seems that we
are falling back on the "native english" (er, French?) meaning of the
term, in which case it's perhaps debatable about whether "RSVP response"
adds anything over just "response".

  o  "web": Opening this URI in a web browser will provide the user
      with a page where they can submit a reply to the organizer.

Are we in a position where we could mandate the "https" scheme here?

Section 4.4.5

What kind of internal consistency checks do we expect implementations to
do with respect to (e.g.) delegatedTo/delegatedFrom,
memberOf/kind(group), etc.?  What should one do if an inconsistency is
found?

Why do we need both scheduleSequence and scheduleUpdated?

  o  language: "String" (optional)

      The language tag as defined in [RFC5646] that best describes the
      participant's preferred language, if known.

nit: RFC 5646 is BCP 47, and referencing the BCP form is probably
preferred for future compatibility.  (I can't tell on a quick inspection
if the RFC is in fact the preferred reference over an IANA registry, but
trust that you have it right.)

      This can be used to determine whether the participant has sent a
      new RSVP following significant changes to the calendar object, and
      to determine if future responses are responding to a current or
      older view of the data.

[Another case where "RSVP" might be out of place.]

  o  scheduleStatus: "String[]" (optional)

      A list of status codes, as defined in Section 3.8.8.3 of
      [RFC5545], returned from the processing of the most recent
      scheduling message sent to this participant.

[Just noting another place with hard 5545 dependency.]

      Servers MUST only add or change this property when they send a
      scheduling message to the participant.  Clients SHOULD NOT change

Send, but not receive?

Section 4.5.2

      *  offset: "SignedDuration" (mandatory).

        Defines the offset at which to trigger the alert relative to
        the time property defined in the "relativeTo" property of the
        alert.  Negative durations signify alerts before the time
        property, positive durations signify alerts after.

Thank you for specifying this explicitly!

      An "AbsoluteTrigger" object has the following properties:
      [...]
      *  when: "UTCDateTime" (mandatory).

Why can absolute triggers not be in local time even when event start/end
times can be in local time?  (Can alerts be part of recurrence rules?)

      For a recurring calendar object, the "acknowledged" property of
      the parent object MUST be updated, unless the alert is already
      overridden in the "recurrenceOverrides" property.

I'm not 100% sure I understand what the parent/child relationship being
referred to is, here.  My current guess is that there's a main
"recurrence rule" object that's treated as the parent for a given object
(in this case, alert) instance, but that may change as I keep reading...

Also, does this *only* apply to recurring objects, or to any object with
a parent?

Section 4.6.1

Are there ever cases where the burden of carrying around a lot of
localizations in-band with the calendar/objects becomes burdonsome, and
it would be convenient to make localizations remote resources thare are
only retrieved on clients that need them?  (E.g., if a given object is
localized into many different locales.)

  object is set to the language tag.  All pointers for patches MUST end
  with one of the following suffixes; any patch that does not follow
  this MUST be ignored unless otherwise specified in a future RFC:

Any RFC at all (including Independent Stream), or specifically an RFC
that updates this one?

Section 4.7.2

  o  It MUST be a valid "paramtext" value as specified in Section 3.1.
      of [RFC5545].

[another 5545 dependency]

  o  At least one other property in the same JSCalendar object MUST
      reference a time zone using this identifier (i.e., orphaned time
      zones are not allowed).

Will maintaining this invariant become burdensome if a calendar needs to
be "subsetted" (e.g., when redistributing "private" events)?

  A TimeZone object maps a VTIMEZONE component from iCalendar [RFC5545]
  and the semantics are as defined there.  A valid time zone MUST

[more 5545 dependence]

  o  validUntil: "UTCDateTime" (optional)

      The TZUNTIL property from iCalendar specified in [RFC7808].

[technically not 5545, but in the same category]

  o  aliases: "String[Boolean]" (optional)

      Maps the TZID-ALIAS-OF properties from iCalendar specified in
      [RFC7808] to a JSON set of aliases.  The set is represented as an
      object, with the keys being the aliases.  The value for each key
      in the set MUST be true.

Is the "alias" property (er, in the natural-language sense of
"property") intended to be transitive, or is there a single primary
timezone that others are aliases of?  (In either case we may want some
more specifics, including error handling.)

  o  offsetTo: "String" (mandatory)
      [...]
  o  offsetFrom: "String" (mandatory)

nit: these are not sorted alphabetically (and are in the opposite order
as RFC 5545); is there a reason not to swap them?

  o  recurrenceOverrides: "LocalDateTime[PatchObject]" (optional)

      Maps the RDATE properties from iCalendar.  The set is represented
      as an object, with the keys being the recurrence dates.  The patch
      object MUST be empty.

I suggest "MUST be the empty JSON object ({})" to distinguish from JSON
null (my initial interpretation), which would not have the desired
semantics.

  o  names: "String[Boolean]" (optional)

      Maps the TZNAME properties from iCalendar to a JSON set.  The set
      is represented as an object, with the keys being the names.  The
      value for each key in the set MUST be true.

I wish there was a more precise definition of "TZNAME properties"
available.  Are these supposed to be the "tznparam" or "text" (or both!)
portions of the RFC 5545 "tzname" construction?

Section 5.1.2

Should we say something about the conceptual "end" of the JSEvent being
at "start" + "duration", or is that too banal?  (We do reference the
"end" in a couple other places.)

Section 5.3

  JSGroup supports the following common JSCalendar properties
  (Section 4):

nit: any chance we could get this list sorted in the order the
properties appear in Section 4?

Section 6.1

(I assume that the January 2018 timestamps reflect approximately when
the example was first written.  It doesn't seem as interesting to have
the examples be "current" to time of publishing as it sometimes does for
other documents that go by.)
It is perhaps surprising to have "updated" and "start" be the same time,
though?

Section 6.10

        "uri": "https://chatme.example.com?id=1234567"

(My sense is that best practices for meeting URLs like this is to
include some amount of randomness in the URL to make it unpredictable.
See also https://www.w3.org/2001/tag/doc/capability-urls/ and
draft-gont-numeric-ids-sec-considerations.)

    "replyTo": {
      "imip": "mailto:6489-4f14-a57f-c1@schedule.example.com"
    },

The local component of the email address is a substring of the UUID that
is this meeting's location id (which itself is reused in several other
places in this document, as previously noted), which is not necessarily
problematic but is perhaps unusual.  I'm more concerned that this is
also the imip "sendTo" for Tom Tool, who is not an owner/chair/etc. of
the meeting, just a regular attendee.  While not forbidden by the spec,
this seems like a highly non-representative example.  I'd suggest making
Tom's "sendTo" be just "tom@foobar.example.com" to match Zoe's.

      "...": ""

Is this empty string actually valid as a participant object?

Section 7

I note that there is not much discussion of internationalization
considerations, and arguably there should be.  This is specifically
relevant for security when it comes to "confusables" in Unicode, though
perhaps the scope for attacks is limited in terms of which JSCalendar
elements are presented to the user.

  Such systems must be careful to authenticate all data they receive to
  prevent them from being subverted.

Authorization checks may also be appropriate in these scenarios,
separately from authentication.

Section 7.3

  Several JSCalendar properties contain URIs as values, and processing
  these properties requires extra care.  Section 7 of [RFC3986]
  discusses security risks related to URIs.

It's generally my preference to specifically call out that there are
inherent considerations with fetching remote resources referenced by
URIs, in addition to referencing RFC 3986's security considerations as
you already do.

Section 7.4

  book contact).  Misclassifications are always possible however, and
  providing a feedback mechanism for users to quickly correct this is
  advised.

Based on real-world experience, I think it's important for the feedback
mechanism to not require sending any traffic to the originator of the
(spam) calendar event/object).
Also, nit: comma before "however" (as well as after).

Section 7.5

  when updating it to avoid unexpected duplication of events.  When the
  UID changes, consumers of the data may not remove the previous
  version of the event if it has a different UID.  This can lead to a

nit: "when the UID changes" seems redundant with "if it has a different
UID".

Section 8

[Just noting that I did not do a particularly thorough cross-referencing
of the various initial registry contents against the document body and
within the related registries.]

Section 8.1

  Interoperability considerations:  This media type provides an
      alternative to iCalendar, jCal and proprietary JSON-based
      calendaring data formats.

This feels like a general statement about the calendaring ecosystem and
not considerations for interoperability specifically within JSCalendar.
I would have expected things more along the lines of "different
applications may use different criteria for determining equivalence of
objects" or "while JSCalendar is designed to avoid ambiguities as much
as possible, when converting objects from other calendar formats to/from
JSCalendar it is possible that differing representations for the same
logical data might arise, or ambiguities in interpretation".

  Fragment identifier considerations:  N/A

I trust it is an explicit decision by the WG to not specify a fragment
identifier structure (e.g., JSON pointer).

Section 8.2

  delay.  It is designed to encourage vendors to document and register
  new properties they add for use cases not covered by the original
  standard, leading to increased interoperability.

nit: maybe s/standard/specification/?

Section 8.2.5

  o  Property Name: The name of the property.  The property name MUST
      NOT already be registered for any of the object types listed in
      the "Property Context" field of this registration.  Other object
      types MAY already have registered a different property with the
      same name.

Is this MAY too strong?  It seems like it would invite confusion if the
same name was used with different semantics in different contexts (so
guidance that this is only expected when the semantics are anlogous
might be appropriate).

Section 10.2

Perhaps "[MIME]" is no longer the best reference tag for the media-types
registry (which is now uncoupled from MIME)?

Since the RFC 4122 UUID construction is RECOMMENDED, that probably makes
it normative.

RFC 5546 needs to be normative since we defer to it for iTIP METHODs.
Likewise RFC 6047 for iMIP, RFC 7529 for several things, and RFC 7808
for several things.
2020-09-22
30 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-09-22
30 Roman Danyliw
[Ballot comment]
Thank you for responding to the SECDIR review (and thank you to Phillip Hallam-Baker for doing it).

** Section 1.
The data model …
[Ballot comment]
Thank you for responding to the SECDIR review (and thank you to Phillip Hallam-Baker for doing it).

** Section 1.
The data model should be compatible with the iCalendar data format
      [RFC5545] [RFC7986] and extensions, but the specification should
      add new attributes where the iCalendar format currently lacks
      expressivity, and drop seldom-used, obsolete, or redundant
      properties.  This means translation with no loss of semantics
      should be easy with most common iCalendar files.

Some of these goals seem to conflict.  If JSCalender drops support for things in the iCalender format how can it be compatible?  Is it possible to easily enumerate what JSCalender no longer supports that iCalendar did?

** Section 1.4.4.  What is the “associated property” from which the time zone should come?

** Section 1.4.4.  Per “When converting local date-times that fall in the discontinuity to UTC, the offset before the transition is used”, would normative language be appropriate here – “… the offset before the transition MUST be used.”?

** Section 4.1.2.  Shouldn’t “uid” be of type “Id” (per Section 1.4.7)?

** Section 4.2.5.  timeZone.  Is there a reason this isn't otype “Time Zones” instead of “String”?

** Section 4.2.6.  uri.  Provide a reference for “URI” (RFC3986)

** Section 4.4.4.  Does “web” method imply that only http and https URIs are acceptable as a value?

** Section 7.  s/man-in-the-middle/on-path/

** Section 7.  I recommend further emphasizing the sensitive nature of this data

OLD
Calendaring and scheduling information is very privacy-sensitive.
  Its transmission must be done carefully to protect it from possible …

NEW
Calendaring and scheduling information is very privacy-sensitive.  It can reveal the social network of a user; location information of this user and those in their social network; identity and credentials information; and the patterns of behavior of the user in both the physical and cyber realm.  Additionally, calendar events and tasks can could influence the physical location of a user or their cyber behavior within a known time window.  It’s transmission and storage must be done carefully to protect it from possible …

** Editorial Nits

-- Section 1.4.3.  Editorial.  Colloquial language. s/is OK/is conformant/

-- Section 1.4.4.  Editorial.  s/see duration semantics below/see duration semantics in Section 1.4.5/

-- Section 1.4.7.  Editorial.  Per “… a UUID is typically a good choice”, I’m not sure this is needed given the more detailed text in Section 4.1.2

-- Section 4.1.4.  Typo. s/knows/known/

-- Section 4.3.  s/compelete/complete/

-- Section 4.4.5.  Typo. s/themself/themselves/

-- Section 6.  Editorial.  Replace any dates in 2018 to be 2020 in the examples (to make the examples be closer to the publish date of this draft).
2020-09-22
30 Roman Danyliw Ballot comment text updated for Roman Danyliw
2020-09-22
30 Roman Danyliw
[Ballot comment]
Thank you for responding to the SECDIR review (and thank you to Phillip Hallam-Baker for doing it).

** Section 1.
The data model …
[Ballot comment]
Thank you for responding to the SECDIR review (and thank you to Phillip Hallam-Baker for doing it).

** Section 1.
The data model should be compatible with the iCalendar data format
      [RFC5545] [RFC7986] and extensions, but the specification should
      add new attributes where the iCalendar format currently lacks
      expressivity, and drop seldom-used, obsolete, or redundant
      properties.  This means translation with no loss of semantics
      should be easy with most common iCalendar files.

Some of these goals seem to conflict.  If JSCalender drops support for things in the iCalender format how can it be compatible?  Is it possible to easily enumerate what JSCalender no longer supports that iCalendar did?

** Section 1.4.4.  What is the “associated property” from which the time zone should come?

** Section 1.4.4.  Per “When converting local date-times that fall in the discontinuity to UTC, the offset before the transition is used”, would normative language be appropriate here – “… the offset before the transition MUST be used.”?

** Section 4.1.2.  Shouldn’t “uid” be of type “Id” (per Section 1.4.7)?

** Section 4.2.5.  timeZone.  Is there a reason this isn't otype “Time Zones” instead of “String”?

** Section 4.2.6.  uri.  Provide a reference for “URI” (RFC3986)

** Section 4.4.4.  Does “web” method imply that only http and https URIs are acceptable as a value?

** Section 7.  s/man-in-the-middle/on-path/

** Section 7.  I recommend further emphasizing the sensitive nature of this data
OLD
Calendaring and scheduling information is very privacy-sensitive.
  Its transmission must be done carefully to protect it from possible …

NEW
Calendaring and scheduling information is very privacy-sensitive.  It can reveal the social network of a user; location information of this user and those in their social network; identity and credentials information; and the patterns of behavior of the user in both the physical and cyber realm.  Additionally, calendar events and tasks can could influence the physical location of a user or their cyber behavior within a known time window.  It’s transmission and storage must be done carefully to protect it from possible …

** Editorial Nits
-- Section 1.4.3.  Editorial.  Colloquial language. s/is OK/is conformant/
-- Section 1.4.4.  Editorial.  s/see duration semantics below/see duration semantics in Section 1.4.5/
-- Section 1.4.7.  Editorial.  Per “… a UUID is typically a good choice”, I’m not sure this is needed given the more detailed text in Section 4.1.2
-- Section 4.1.4.  Typo. s/knows/known/
-- Section 4.3.  s/compelete/complete/
-- Section 4.4.5.  Typo. s/themself/themselves/
-- Section 6.  Editorial.  Replace any dates in 2018 to be 2020 in the examples (to make the examples be closer to the publish date of this draft).
2020-09-22
30 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-09-20
30 Erik Kline
[Ballot comment]
[[ questions ]]

[ section 1.4.5 ]

* Since non-zero fractional seconds is not the same as not having
  any trailing zeros, should …
[Ballot comment]
[[ questions ]]

[ section 1.4.5 ]

* Since non-zero fractional seconds is not the same as not having
  any trailing zeros, should the "to ensure there is only a single
  representation" guidance from UTCDateTime also apply here?

  In other words, is "PT1.300S" acceptable?

[ section 1.4.7 ]

* Should there be a reference to RFC 4122 here?

[ section 3(.0) ]

* Should the I-JSON reference be 7493?

[ section 6.3 ]

* Is this entries array really valid JSON?  I didn't think the map key
  could appear in the array like this (vis. the jstask entry).

[ section 6.9 ]

* Should the "excluded" value be true rather than "true"?


[[ nits ]]

[ section 4.2.6 ]

* It seems unlikely that a virtual event would have a "door access code".
  Perhaps "conference access code" or "meeting access code" or something?
2020-09-20
30 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-09-18
30 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

To be honest, after reading the abstract, https://xkcd.com/927/ sprang to my mind (even after …
[Ballot comment]
Thank you for the work put into this document.

To be honest, after reading the abstract, https://xkcd.com/927/ sprang to my mind (even after being relieved by the explanations of section 1.1)... Let's hope that more tools/applications will use this new standard.

Please find below a couple of non-blocking COMMENTs and blocking DISCUSS points.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.3  --
Is the wording 'type signature' well accepted in the JSON world ? I would have expected something like 'type description' 'type grammar'.

-- Section 1.48 --
As I find the 'patchObject' an interesting concept, I wonder whether it should not also be specified in another document ? (if not yet done of course, then I wonder why it is defined in this document)

-- Section 4.3 --
Just to write that this section about recurrence was well thought ;-)

-- Section 4.2.2 --
"This MUST be one of the following values, a value registered in the IANA JSCalendar Enum Registry, or a vendor-specific value:" I find it slightly confusing as the listed value (free/busy) are also part of the IANA table 5 later in the document. Suggest to use "This MUST be one of the value registered in the IANA JSCalendar Enum Registry (like the two listed below) or a vendor-specific value:"

Same applies also to section 4.4.3 and other places (such as 'roles').
2020-09-18
30 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-09-10
30 Tero Kivinen Request for Telechat review by SECDIR is assigned to Phillip Hallam-Baker
2020-09-10
30 Tero Kivinen Request for Telechat review by SECDIR is assigned to Phillip Hallam-Baker
2020-09-08
30 Amy Vezza Placed on agenda for telechat - 2020-09-24
2020-09-06
30 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2020-09-06
30 Barry Leiba Ballot has been issued
2020-09-06
30 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2020-09-06
30 Barry Leiba Created "Approve" ballot
2020-09-06
30 Robert Stepanek New version available: draft-ietf-calext-jscalendar-30.txt
2020-09-06
30 (System) New version accepted (logged-in submitter: Robert Stepanek)
2020-09-06
30 Robert Stepanek Uploaded new revision
2020-08-18
29 Neil Jenkins New version available: draft-ietf-calext-jscalendar-29.txt
2020-08-18
29 (System) New version approved
2020-08-18
29 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Robert Stepanek
2020-08-18
29 Neil Jenkins Uploaded new revision
2020-07-26
28 Neil Jenkins New version available: draft-ietf-calext-jscalendar-28.txt
2020-07-26
28 (System) New version approved
2020-07-26
28 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Robert Stepanek
2020-07-26
28 Neil Jenkins Uploaded new revision
2020-06-14
27 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-06-14
27 Neil Jenkins New version available: draft-ietf-calext-jscalendar-27.txt
2020-06-14
27 (System) New version approved
2020-06-14
27 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Robert Stepanek
2020-06-14
27 Neil Jenkins Uploaded new revision
2020-04-24
26 Cindy Morgan IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for AD Go-Ahead::Point Raised - writeup needed
2020-03-16
26 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2020-03-13
26 Barry Leiba Ballot writeup was changed
2020-03-13
26 Barry Leiba IESG state changed to Waiting for AD Go-Ahead::Point Raised - writeup needed from Waiting for Writeup
2020-03-10
26 Phillip Hallam-Baker Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Phillip Hallam-Baker. Sent review to list.
2020-03-09
26 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2020-03-09
26 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-calext-jscalendar-25. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-calext-jscalendar-25. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the application Media Types registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a single, new media type will be registered as follows:

Name: jscalendar+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA Question --> IANA understands that the next three actions create the JSCalendar Properties, Types and Enum Values registries. Should these three new registries be grouped together on a new registry page on the IANA Registry matrix located at:

https://www.iana.org/protocols

or should it be added to an existing registry page at http://www.iana.org/protocols?

Second, a new registry is to be created called the JSCalendar Properties registry. The new registry will be at a location to be determined later (see IANA question above). The registry will be managed via the following registration rules:

Intended Use:
Common - Specification Required
Reserved - Expert Review
Obsolete - Expert Review

Each registration in the new registry will have the following fields:

Property Name
Property Type
Property Context
Intended Use
Change Controller
Reference

There are substantial initial contents for the new registry and IANA will use [ RFC-to-be ] Section 8.2.6 of the current draft as authoritative guidance for populating the new registry. All of the entries will be marked as having:

Intended use: Common

In addition, all of the entries in the new registry will have a reference that adds [ RFC-to-be ] to the reference provided by [ RFC-to-be ] Section 8.2.6.

Third, a new registry is to be created called the JSCalendar Types registry. The new registry will be at a location to be determined later (see IANA question above). The registry will be managed via the following registration rules:

Intended Use:
Common - Specification Required
Reserved - Expert Review
Obsolete - Expert Review

Each registration in the new registry will have the following fields:

Type Name
Intended Use
Change Controller
Reference

There are substantial initial contents for the new registry and IANA will use [ RFC-to-be ] Section 8.3.2 of the current draft as authoritative guidance for populating the new registry. All of the entries will be marked as having:

Intended use: Common

In addition, all of the entries in the new registry will have a reference that adds [ RFC-to-be ] to the reference provided by [ RFC-to-be ] Section 8.3.2.

Fourth, a series of subregistries of the JSCalendar Property registry are to be created. Each new registry has a name of the form:

Enum Values for {property-name} (Context: {context})

where

{property-name} is the name(s) of the property or properties where these values may be used. This MUST be registered in the JSCalendar Properties registry created in action two above.

{context} is the list of allowed object types where the property or properties may appear, as registered in the JSCalendar Properties registry created in action two above. This disambiguates where there may be two distinct properties with the same name in different contexts.

The registration rules for the new sub-registries is the same as the rules for the associated JSCalendar Properties registry.

The following subregistries of the JSCalendar Properties registry are created upon approval of this document:

Enum Values for action (Context: Alert)

+------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+------------+------------------------------+----------------+
| display | [ RFC-to-be ] Section 4.5.2 | IETF |
| email | [ RFC-to-be ] Section 4.5.2 | IETF |
+------------+------------------------------+----------------+

Enum Values for display (Context: Link)

+------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+------------+------------------------------+----------------+
| badge | [ RFC-to-be ] Section 4.2.7 | IETF |
| graphic | [ RFC-to-be ] Section 4.2.7 | IETF |
| fullsize | [ RFC-to-be ] Section 4.2.7 | IETF |
| thumbnail | [ RFC-to-be ] Section 4.2.7 | IETF |
+------------+------------------------------+----------------+

Enum Values for freeBusyStatus (Context: JSEvent, JSTask)

+------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+------------+------------------------------+----------------+
| free | [ RFC-to-be ] Section 4.4.2 | IETF |
| busy | [ RFC-to-be ] Section 4.4.2 | IETF |
+------------+------------------------------+----------------+

Enum Values for kind (Context: Participant)

+------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+------------+------------------------------+----------------+
| individual | [ RFC-to-be ] Section 4.4.5 | IETF |
| group | [ RFC-to-be ] Section 4.4.5 | IETF |
| resource | [ RFC-to-be ] Section 4.4.5 | IETF |
| location | [ RFC-to-be ] Section 4.4.5 | IETF |
+------------+------------------------------+----------------+

Enum Values for participationStatus (Context: Participant)

+--------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+--------------+------------------------------+----------------+
| needs-action | [ RFC-to-be ] Section 4.4.5 | IETF |
| accepted | [ RFC-to-be ] Section 4.4.5 | IETF |
| declined | [ RFC-to-be ] Section 4.4.5 | IETF |
| tenative | [ RFC-to-be ] Section 4.4.5 | IETF |
| delegated | [ RFC-to-be ] Section 4.4.5 | IETF |
+--------------+------------------------------+----------------+

Enum Values for privacy (Context: JSEvent, JSTask)

+------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+------------+------------------------------+----------------+
| public | [ RFC-to-be ] Section 4.4.3 | IETF |
| private | [ RFC-to-be ] Section 4.4.3 | IETF |
| secret | [ RFC-to-be ] Section 4.4.3 | IETF |
+------------+------------------------------+----------------+

Enum Values for progress (Context: JSTask, Participant)

+--------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+--------------+------------------------------+----------------+
| needs-action | [ RFC-to-be ] Section 5.2.4 | IETF |
| in-process | [ RFC-to-be ] Section 5.2.4 | IETF |
| completed | [ RFC-to-be ] Section 5.2.4 | IETF |
| failed | [ RFC-to-be ] Section 5.2.4 | IETF |
| cancelled | [ RFC-to-be ] Section 5.2.4 | IETF |
+--------------+------------------------------+----------------+

Enum Values for relation (Context: Relation)

+------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+------------+------------------------------+----------------+
| first | [ RFC-to-be ] Section 1.4.10 | IETF |
| next | [ RFC-to-be ] Section 1.4.10 | IETF |
| child | [ RFC-to-be ] Section 1.4.10 | IETF |
| parent | [ RFC-to-be ] Section 1.4.10 | IETF |
+------------+------------------------------+----------------+

Enum Values for relativeTo (Context: OffsetTrigger, Location)

+------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+------------+------------------------------+----------------+
| start | [ RFC-to-be ] Section 4.5.2 | IETF |
| end | [ RFC-to-be ] Section 4.5.2 | IETF |
+------------+------------------------------+----------------+

Enum Values for roles (Context: Participant)

+---------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+---------------+------------------------------+----------------+
| owner | [ RFC-to-be ] Section 4.4.5 | IETF |
| attendee | [ RFC-to-be ] Section 4.4.5 | IETF |
| optional | [ RFC-to-be ] Section 4.4.5 | IETF |
| informational | [ RFC-to-be ] Section 4.4.5 | IETF |
| chair | [ RFC-to-be ] Section 4.4.5 | IETF |
+---------------+------------------------------+----------------+

Enum Values for scheduleAgent (Context: Participant)

+------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+------------+------------------------------+----------------+
| server | [ RFC-to-be ] Section 4.4.5 | IETF |
| client | [ RFC-to-be ] Section 4.4.5 | IETF |
| none | [ RFC-to-be ] Section 4.4.5 | IETF |
+------------+------------------------------+----------------+

Enum Values for status (Context: JSEvent)

+------------+------------------------------+----------------+
| Enum Value | Reference or Description | Change Control |
+------------+------------------------------+----------------+
| confirmed | [ RFC-to-be ] Section 5.1.3 | IETF |
| cancelled | [ RFC-to-be ] Section 5.1.3 | IETF |
| tentative | [ RFC-to-be ] Section 5.1.3 | IETF |
+------------+------------------------------+----------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-03-09
26 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-03-07
26 Neil Jenkins New version available: draft-ietf-calext-jscalendar-26.txt
2020-03-07
26 (System) New version approved
2020-03-07
26 (System) Request for posting confirmation emailed to previous authors: Neil Jenkins , Robert Stepanek
2020-03-07
26 Neil Jenkins Uploaded new revision
2020-03-03
25 Robert Sparks Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Robert Sparks. Sent review to list.
2020-02-27
25 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2020-02-27
25 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2020-02-26
25 Tero Kivinen Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker
2020-02-26
25 Tero Kivinen Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker
2020-02-24
25 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-02-24
25 Amy Vezza
The following Last Call announcement was sent out (ends 2020-03-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-calext-jscalendar@ietf.org, calsify@ietf.org, calext-chairs@ietf.org, Daniel Migault , …
The following Last Call announcement was sent out (ends 2020-03-09):

From: The IESG
To: IETF-Announce
CC: draft-ietf-calext-jscalendar@ietf.org, calsify@ietf.org, calext-chairs@ietf.org, Daniel Migault , daniel.migaultf@ericsson.com, barryleiba@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (JSCalendar: A JSON representation of calendar data) to Proposed Standard


The IESG has received a request from the Calendaring Extensions WG (calext)
to consider the following document: - 'JSCalendar: A JSON representation of
calendar data'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-03-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines a data model and JSON representation of
  calendar data that can be used for storage and data exchange in a
  calendaring and scheduling environment.  It aims to be an alternative
  and, over time, successor to the widely deployed iCalendar data
  format, and to be unambiguous, extendable, and simple to process.  In
  contrast to the jCal format, which is also JSON-based, JSCalendar is
  not a direct mapping from iCalendar, but defines the data model
  independently and expands semantics where appropriate.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ballot/


No IPR declarations have been submitted directly on this I-D.




2020-02-24
25 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-02-24
25 Amy Vezza Last call announcement was generated
2020-02-23
25 Neil Jenkins New version available: draft-ietf-calext-jscalendar-25.txt
2020-02-23
25 (System) New version approved
2020-02-23
25 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2020-02-23
25 Neil Jenkins Uploaded new revision
2020-02-23
24 Barry Leiba Last call was requested
2020-02-23
24 Barry Leiba Last call announcement was generated
2020-02-23
24 Barry Leiba Ballot approval text was generated
2020-02-23
24 Barry Leiba Ballot writeup was generated
2020-02-23
24 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-02-19
24 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-02-19
24 Neil Jenkins New version available: draft-ietf-calext-jscalendar-24.txt
2020-02-19
24 (System) New version approved
2020-02-19
24 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2020-02-19
24 Neil Jenkins Uploaded new revision
2020-02-18
23 Barry Leiba Notification list changed to Daniel Migault <daniel.migault@ericsson.com> from Daniel Migault <daniel.migaultf@ericsson.com>
2020-02-18
23 Barry Leiba IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2020-02-18
23 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2020-02-18
23 Daniel Migault
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The RFC type is standard track. This is is appropriated track as it defines
format that guarantees interoperability between systems. It is mentioned
in the title header. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

The summary is as follows:

This specification defines a data model and JSON representation of
calendar data that can be used for storage and data exchange in a
calendaring and scheduling environment.  It aims to be an alternative,
and over time successor to, the widely deployed iCalendar data format
and to be unambiguous, extendable and simple to process.  In contrast to
the JSON-based jCal format, it is not a direct mapping from iCalendar
and expands semantics where appropriate.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There were no controversy. Though the draft is defining an important
change for calendar objects. The document did not raise any opposition.
In addition, this document undergo a significant number of reviews, and
lots of discussions happened at the IETF as well as during Calconnect
meetings. Calconnect discussions have been reported by the co-authors as
well as during interim meetings organized during Calconnect sessions.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are a number of implementations.  FastMail, has multiple
implementations that works for beta users. This includes a perl
implementation. The open-source Cyrus IMAP project includes a C
implementation to translate from and to iCalendar. I suspect other
implementations are developped and deployed including

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Daniel Migault is the document shepherd and Barry Leiba is the
responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has reviewed the document. The document had many
reviews, and I am confident the document is ready.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No, we had discussions about having JSON expert to review the document,
but so far have not had this review. Though this is always good to have an
additional review, I do not see this as a blocking point given the number
of reviews.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I do not have specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Robert Stepanek and Neil Jenkins has confirmed on the mailing list
that they are not aware of any IPR. 

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG consensus is strong.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Nits do not raise errors. warning are not of concerns and references are
not missing.

idnits 2.16.02

/tmp/draft-ietf-calext-jscalendar-23.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'Alert' is mentioned on line 2736, but not defined

  == Missing Reference: 'Boolean' is mentioned on line 2952, but not defined

  == Missing Reference: 'Link' is mentioned on line 2863, but not defined

  == Missing Reference: 'PatchObject' is mentioned on line 2927, but not
    defined

  == Missing Reference: 'Location' is mentioned on line 2877, but not defined

  == Missing Reference: 'Participant' is mentioned on line 2899, but not
    defined

  == Missing Reference: 'Relation' is mentioned on line 2936, but not defined

  == Missing Reference: 'String' is mentioned on line 2967, but not defined

  == Missing Reference: 'TimeZone' is mentioned on line 2998, but not defined

  == Missing Reference: 'VirtualLocation' is mentioned on line 3026, but not
    defined


    Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 0 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

We sent th edocument for an IANA review.

(13) Have all references within this document been identified as
either normative or informative?

References are normatives or informational. Some references are referred
as URIs. Maybe the RFC editor will move them to informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

Daniel Migault reviewed the IANA section. We worked with respective AD
and IANA, to understand how to complete the IANA section. I confirm that
registries are appropriately created.

I confirm newly created IANA registries include a detailed specification
of the initial contents for the registry, that allocations procedures
for future registrations are defined

I confirm reasonable name for the new registry has been suggested

The only point raised by IANA was to confirm allowing for 1 sentence
to be enough for "Specification Required". This needs to be confirmed.

"""
  This registry follows the Expert Review process ([RFC8126],
  Section 4.5) unless the "intended use" field is "common", in which
  case registration follows the Specification Required process
  ([RFC8126], Section 4.6).  Preliminary community review for this
  registry is optional but strongly encouraged.
"""



(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

The document asks fro the creation of registries, so there are no expert
review expected upon the media type.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None
2020-02-18
23 Daniel Migault Responsible AD changed to Barry Leiba
2020-02-18
23 Daniel Migault IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2020-02-18
23 Daniel Migault IESG state changed to Publication Requested from I-D Exists
2020-02-18
23 Daniel Migault IESG process started in state Publication Requested
2020-02-18
23 Daniel Migault
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The RFC type is standard track. This is is appropriated track as it defines
format that guarantees interoperability between systems. It is mentioned
in the title header. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

The summary is as follows:

This specification defines a data model and JSON representation of
calendar data that can be used for storage and data exchange in a
calendaring and scheduling environment.  It aims to be an alternative,
and over time successor to, the widely deployed iCalendar data format
and to be unambiguous, extendable and simple to process.  In contrast to
the JSON-based jCal format, it is not a direct mapping from iCalendar
and expands semantics where appropriate.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There were no controversy. Though the draft is defining an important
change for calendar objects. The document did not raise any opposition.
In addition, this document undergo a significant number of reviews, and
lots of discussions happened at the IETF as well as during Calconnect
meetings. Calconnect discussions have been reported by the co-authors as
well as during interim meetings organized during Calconnect sessions.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are a number of implementations.  FastMail, has multiple
implementations that works for beta users. This includes a perl
implementation. The open-source Cyrus IMAP project includes a C
implementation to translate from and to iCalendar. I suspect other
implementations are developped and deployed including

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Daniel Migault is the document shepherd and Barry Leiba is the
responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has reviewed the document. The document had many
reviews, and I am confident the document is ready.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No, we had discussions about having JSON expert to review the document,
but so far have not had this review. Though this is always good to have an
additional review, I do not see this as a blocking point given the number
of reviews.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I do not have specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Robert Stepanek and Neil Jenkins has confirmed on the mailing list
that they are not aware of any IPR. 

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG consensus is strong.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Nits do not raise errors. warning are not of concerns and references are
not missing.

idnits 2.16.02

/tmp/draft-ietf-calext-jscalendar-23.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'Alert' is mentioned on line 2736, but not defined

  == Missing Reference: 'Boolean' is mentioned on line 2952, but not defined

  == Missing Reference: 'Link' is mentioned on line 2863, but not defined

  == Missing Reference: 'PatchObject' is mentioned on line 2927, but not
    defined

  == Missing Reference: 'Location' is mentioned on line 2877, but not defined

  == Missing Reference: 'Participant' is mentioned on line 2899, but not
    defined

  == Missing Reference: 'Relation' is mentioned on line 2936, but not defined

  == Missing Reference: 'String' is mentioned on line 2967, but not defined

  == Missing Reference: 'TimeZone' is mentioned on line 2998, but not defined

  == Missing Reference: 'VirtualLocation' is mentioned on line 3026, but not
    defined


    Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 0 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

We sent th edocument for an IANA review.

(13) Have all references within this document been identified as
either normative or informative?

References are normatives or informational. Some references are referred
as URIs. Maybe the RFC editor will move them to informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

Daniel Migault reviewed the IANA section. We worked with respective AD
and IANA, to understand how to complete the IANA section. I confirm that
registries are appropriately created.

I confirm newly created IANA registries include a detailed specification
of the initial contents for the registry, that allocations procedures
for future registrations are defined

I confirm reasonable name for the new registry has been suggested

The only point raised by IANA was to confirm allowing for 1 sentence
to be enough for "Specification Required". This needs to be confirmed.

"""
  This registry follows the Expert Review process ([RFC8126],
  Section 4.5) unless the "intended use" field is "common", in which
  case registration follows the Specification Required process
  ([RFC8126], Section 4.6).  Preliminary community review for this
  registry is optional but strongly encouraged.
"""



(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

The document asks fro the creation of registries, so there are no expert
review expected upon the media type.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None
2020-02-18
23 Robert Stepanek New version available: draft-ietf-calext-jscalendar-23.txt
2020-02-18
23 (System) New version accepted (logged-in submitter: Robert Stepanek)
2020-02-18
23 Robert Stepanek Uploaded new revision
2020-02-06
22 Daniel Migault
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The RFC type is standard track. This is is apprpriated track as it defines format that guarantees interoperability between systems. It is mentionnedin the title header. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

The summary is as follows:

This specification defines a data model and JSON representation of
calendar data that can be used for storage and data exchange in a
calendaring and scheduling environment.  It aims to be an alternative,
and over time successor to, the widely deployed iCalendar data format
and to be unambiguous, extendable and simple to process.  In contrast to
the JSON-based jCal format, it is not a direct mapping from iCalendar
and expands semantics where appropriate.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There were no controversy. Though the draft is defining an important
change for calendar objects. The document did not raise any opposition.
In addition, this document undergo a significant number of reviews, and
lots of discussions happened at the IETF as well as during Calconnect
meetings. Calconnect discussions have been reported by the co-authors as
well as during interim meetings organized during Calconnect sessions.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are a number of implementations.  FastMail, has multiple
implementations that works for beta users. This includes a perl
implementation. The open-source Cyrus IMAP project includes a C
implementation to translate from and to iCalendar. I suspect other
implementations are developped and deployed including

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Daniel Migault is the document shepherd and Barry Leiba is the
responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has reviewed the document. The document had many
reviews, and I am confident the document is ready.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No, we had discussions about having JSON expert to review the document,
but so far have not had this review. Though this is always good to have an
additional review, I do not see this as a blocking point given the number
of reviews.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I do not have specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Robert Stepanek and Neil Jenkins has confirmed on the mailing list
that they are not aware of any IPR. 

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG consensus is strong.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Nits do not raise errors. warning are not of concerns.

The following references have been set as normative. They could also be informative.
  [COLORS]  "CSS Color Module", .
  [LINKRELS] "IANA Link Relation Types", .
    [TZDB]    "IANA Time Zone Database", .


idnits 2.16.02

/tmp/draft-ietf-calext-jscalendar-22.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  -- The document date (December 05, 2019) is 63 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Missing Reference: 'Alert' is mentioned on line 2738, but not defined

  == Missing Reference: 'Boolean' is mentioned on line 2954, but not defined

  == Missing Reference: 'Link' is mentioned on line 2865, but not defined

  == Missing Reference: 'PatchObject' is mentioned on line 2929, but not
    defined

  == Missing Reference: 'Location' is mentioned on line 2879, but not defined

  == Missing Reference: 'Participant' is mentioned on line 2901, but not
    defined

  == Missing Reference: 'Relation' is mentioned on line 2938, but not defined

  == Missing Reference: 'String' is mentioned on line 2969, but not defined

  == Missing Reference: 'TimeZone' is mentioned on line 3000, but not defined

  == Missing Reference: 'VirtualLocation' is mentioned on line 3028, but not
    defined

  -- Possible downref: Non-RFC (?) normative reference: ref. 'COLORS'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'LINKRELS'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'TZDB'


    Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

We sent th edocument for an IANA review.

(13) Have all references within this document been identified as
either normative or informative?

References are normatives or informational. Some references are referred
as URIs. Maybe the RFC editor will move them to informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

Daniel Migault reviewed the IANA section. We worked with respective AD
and IANA, to understand how to complete the IANA section. I confirm that
registries are appropriately created.

I confirm newly created IANA registries include a detailed specification
of the initial contents for the registry, that allocations procedures
for future registrations are defined

I confirm reasonable name for the new registry has been suggested

The only point raised by IANA was to confirm allowing for 1 sentence
to be enough for "Specification Required". This needs to be confirmed.

"""
  This registry follows the Expert Review process ([RFC8126],
  Section 4.5) unless the "intended use" field is "common", in which
  case registration follows the Specification Required process
  ([RFC8126], Section 4.6).  Preliminary community review for this
  registry is optional but strongly encouraged.
"""



(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

The document asks fro the creation of registries, so there are no expert
review expected upon the media type.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None
2019-12-04
22 Neil Jenkins New version available: draft-ietf-calext-jscalendar-22.txt
2019-12-04
22 (System) New version approved
2019-12-04
22 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2019-12-04
22 Neil Jenkins Uploaded new revision
2019-11-07
21 Daniel Migault
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The RFC type is standard track. This is is apprpriated track as it defines format that guarantees interoperability between systems. It is mentionnedin the title header. 

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

The summary is as follows:

This specification defines a data model and JSON representation of
calendar data that can be used for storage and data exchange in a
calendaring and scheduling environment.  It aims to be an alternative,
and over time successor to, the widely deployed iCalendar data format
and to be unambiguous, extendable and simple to process.  In contrast to
the JSON-based jCal format, it is not a direct mapping from iCalendar
and expands semantics where appropriate.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

There were no controversy. Though the draft is defining an important
change for calendar objects. The document did not raise any opposition.
In addition, this document undergo a significant number of reviews, and
lots of discussions happened at the IETF as well as during Calconnect
meetings. Calconnect discussions have been reported by the co-authors as
well as during interim meetings organized during Calconnect sessions.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are a number of implementations.  FastMail, has multiple
implementations that works for beta users. This includes a perl
implementation. The open-source Cyrus IMAP project includes a C
implementation to translate from and to iCalendar. I suspect other
implementations are developped and deployed including

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Daniel Migault is the document shepherd and Barry Leiba is the
responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has reviewed the document. The document had many
reviews, and I am confident the document is ready.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No, we had discussions about having JSON expert to review the document,
but so far have not had this review. I still believe that woudl be good.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

I do not have specific concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Neil Jenkins has confirmed on the mailing list that he is not aware of
any IPR. 
check with Robert

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The WG consensus is strong.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Nits do not raise errors. warning are not of concerns.

[1]-[4] are actually references.
other warning are due to notation of array defined in the document.


idnits 2.16.02

/tmp/draft-ietf-calext-jscalendar-21.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (October 28, 2019) is 6 days in the past.  Is this
    intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '1' on line 3616

  -- Looks like a reference, but probably isn't: '2' on line 3618

  -- Looks like a reference, but probably isn't: '3' on line 3621

  -- Looks like a reference, but probably isn't: '4' on line 3623

  == Missing Reference: 'Alert' is mentioned on line 2741, but not defined

  == Missing Reference: 'Boolean' is mentioned on line 3022, but not defined

  == Missing Reference: 'Link' is mentioned on line 2906, but not defined

  == Missing Reference: 'PatchObject' is mentioned on line 2988, but not
    defined

  == Missing Reference: 'Location' is mentioned on line 2922, but not defined

  == Missing Reference: 'Participant' is mentioned on line 2952, but not
    defined

  == Missing Reference: 'Relation' is mentioned on line 3000, but not defined

  == Missing Reference: 'String' is mentioned on line 3042, but not defined

  == Missing Reference: 'TimeZone' is mentioned on line 3084, but not defined

  == Missing Reference: 'VirtualLocation' is mentioned on line 3117, but not
    defined


    Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

IANA review.

(13) Have all references within this document been identified as
either normative or informative?

References are nomatives or informational. Some references are refered
as URIs. Maybe the RFC editor will move them to informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

Daniel Migault reviewed the IANA section. We worked with respective AD
and IANA, to understand how to complete the IANA section. I confirm that
registries are appropriately created.

I confirm newly created IANA registries include a detailed specification
of the initial contents for the registry, that allocations procedures
for future registrations are defined

I confirm reasonable name for the new registry has been suggested

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

The document asks fro the creation of registries, so there are no expert
review expected upon the media type.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None
2019-10-27
21 Neil Jenkins New version available: draft-ietf-calext-jscalendar-21.txt
2019-10-27
21 (System) New version approved
2019-10-27
21 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2019-10-27
21 Neil Jenkins Uploaded new revision
2019-10-15
20 Neil Jenkins New version available: draft-ietf-calext-jscalendar-20.txt
2019-10-15
20 (System) New version approved
2019-10-15
20 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2019-10-15
20 Neil Jenkins Uploaded new revision
2019-10-03
19 Robert Stepanek New version available: draft-ietf-calext-jscalendar-19.txt
2019-10-03
19 (System) New version accepted (logged-in submitter: Robert Stepanek)
2019-10-03
19 Robert Stepanek Uploaded new revision
2019-07-23
18 Neil Jenkins New version available: draft-ietf-calext-jscalendar-18.txt
2019-07-23
18 (System) New version approved
2019-07-23
18 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2019-07-23
18 Neil Jenkins Uploaded new revision
2019-06-29
17 Robert Stepanek New version available: draft-ietf-calext-jscalendar-17.txt
2019-06-29
17 (System) New version approved
2019-06-29
17 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2019-06-29
17 Robert Stepanek Uploaded new revision
2019-06-24
16 Robert Stepanek New version available: draft-ietf-calext-jscalendar-16.txt
2019-06-24
16 (System) New version approved
2019-06-24
16 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2019-06-24
16 Robert Stepanek Uploaded new revision
2019-06-17
15 Robert Stepanek New version available: draft-ietf-calext-jscalendar-15.txt
2019-06-17
15 (System) New version approved
2019-06-17
15 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2019-06-17
15 Robert Stepanek Uploaded new revision
2019-06-06
14 Robert Stepanek New version available: draft-ietf-calext-jscalendar-14.txt
2019-06-06
14 (System) New version approved
2019-06-06
14 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2019-06-06
14 Robert Stepanek Uploaded new revision
2019-05-02
13 Robert Stepanek New version available: draft-ietf-calext-jscalendar-13.txt
2019-05-02
13 (System) New version approved
2019-05-02
13 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2019-05-02
13 Robert Stepanek Uploaded new revision
2019-03-25
12 Bron Gondwana Added to session: IETF-104: calext  Mon-1120
2019-03-05
12 Robert Stepanek New version available: draft-ietf-calext-jscalendar-12.txt
2019-03-05
12 (System) New version approved
2019-03-05
12 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2019-03-05
12 Robert Stepanek Uploaded new revision
2018-12-10
11 Robert Stepanek New version available: draft-ietf-calext-jscalendar-11.txt
2018-12-10
11 (System) New version approved
2018-12-10
11 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-12-10
11 Robert Stepanek Uploaded new revision
2018-11-22
10 Robert Stepanek New version available: draft-ietf-calext-jscalendar-10.txt
2018-11-22
10 (System) New version approved
2018-11-22
10 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-11-22
10 Robert Stepanek Uploaded new revision
2018-11-06
09 Daniel Migault Notification list changed to Daniel Migault <daniel.migaultf@ericsson.com>
2018-11-06
09 Daniel Migault Document shepherd changed to Daniel Migault
2018-11-06
09 Daniel Migault Changed consensus to Yes from Unknown
2018-11-06
09 Daniel Migault Intended Status changed to Proposed Standard from None
2018-11-05
09 Robert Stepanek New version available: draft-ietf-calext-jscalendar-09.txt
2018-11-05
09 (System) New version approved
2018-11-05
09 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-11-05
09 Robert Stepanek Uploaded new revision
2018-10-08
08 Robert Stepanek New version available: draft-ietf-calext-jscalendar-08.txt
2018-10-08
08 (System) New version approved
2018-10-08
08 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-10-08
08 Robert Stepanek Uploaded new revision
2018-09-20
07 Robert Stepanek New version available: draft-ietf-calext-jscalendar-07.txt
2018-09-20
07 (System) New version approved
2018-09-20
07 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-09-20
07 Robert Stepanek Uploaded new revision
2018-08-30
06 Robert Stepanek New version available: draft-ietf-calext-jscalendar-06.txt
2018-08-30
06 (System) New version approved
2018-08-30
06 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-08-30
06 Robert Stepanek Uploaded new revision
2018-08-21
05 Daniel Migault IETF WG state changed to In WG Last Call from WG Document
2018-07-02
05 Robert Stepanek New version available: draft-ietf-calext-jscalendar-05.txt
2018-07-02
05 (System) New version approved
2018-07-02
05 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-07-02
05 Robert Stepanek Uploaded new revision
2018-05-25
04 Robert Stepanek New version available: draft-ietf-calext-jscalendar-04.txt
2018-05-25
04 (System) New version approved
2018-05-25
04 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-05-25
04 Robert Stepanek Uploaded new revision
2018-05-09
03 Robert Stepanek New version available: draft-ietf-calext-jscalendar-03.txt
2018-05-09
03 (System) New version approved
2018-05-09
03 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-05-09
03 Robert Stepanek Uploaded new revision
2018-03-05
02 Robert Stepanek New version available: draft-ietf-calext-jscalendar-02.txt
2018-03-05
02 (System) New version approved
2018-03-05
02 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-03-05
02 Robert Stepanek Uploaded new revision
2018-03-02
01 Robert Stepanek New version available: draft-ietf-calext-jscalendar-01.txt
2018-03-02
01 (System) New version approved
2018-03-02
01 (System) Request for posting confirmation emailed to previous authors: Robert Stepanek , Neil Jenkins
2018-03-02
01 Robert Stepanek Uploaded new revision
2018-01-29
00 Daniel Migault This document now replaces draft-jenkins-jscalendar instead of None
2018-01-29
00 Robert Stepanek New version available: draft-ietf-calext-jscalendar-00.txt
2018-01-29
00 (System) WG -00 approved
2018-01-29
00 Robert Stepanek Set submitter to "Robert Stepanek ", replaces to draft-jenkins-jscalendar and sent approval email to group chairs: calext-chairs@ietf.org
2018-01-29
00 Robert Stepanek Uploaded new revision