Event Publishing Extensions to iCalendar
draft-ietf-calext-eventpub-extensions-19

[Ballot comment]
Thanks very much for the changes in Section 9.1, and I think we're now at the best place we can reasonable be here.  Well done.

Thanks also for the changes to clarify the ABNF, and for handling all the other comments.

Good work on the latest version, which resolves just about everything.  There's one more short round needed on the ABNF, and Murray has just placed a ballot (which we need in order for the document to pass approval), so please address his comments... and then we should be done, at last.

[Ballot discuss]
Thanks very much for the changes in Section 9.1, and I think we're now at the best place we can reasonable be here.  Well done.

Thanks also for the changes to clarify the ABNF.  They're mostly good, and we should be able to clean these last bits up pretty easily:

— Section 6.6 —

The new ABNF doesn’t correctly specify what the old was trying to say.  I think this is correct and concise, but please check it over:

NEW

sdataprop    = "STRUCTURED-DATA" sdataparam ":"
                    sdataval CRLF

      sdataparam    = ; all parameter elements may appear in any order,
                      ; and the order is not significant.
                      (sdataparamtext / sdataparambin / sdataparamuri)
                      *(";" other-param)

      sdataparamtext = ";VALUE=TEXT"
                      ";" fmttypeparam
                      ";" schemaparam

      sdataparambin  = ";VALUE=BINARY"
                      ";ENCODING=BASE64"
                      ";" fmttypeparam
                      ";" schemaparam

      sdataparamuri  = ";VALUE=URI"
                      [";" fmttypeparam]
                      [";" schemaparam]

      sdataval      = ( binary / text /uri )
                      ; value MUST match value type

END


— Section 7.1 —

      participantc = "BEGIN" ":" "PARTICIPANT" CRLF
                    *( partprop / locationc / resourcec )
                    "END" ":" "PARTICIPANT" CRLF

This allows multiple instances of partprop (or none), which is not what you mean.  The “*” isn’t right.  Also, do you really mean to have locationc and resourcec here?  Those are blocks that are peers of participantc within eventc, todoc, journalc, and freebusyc… are they also meant to be nested within participantc?  If so, it would be good to have an example or two that shows that.  In any case, that bit of ABNF still needs some work.

                    (calendaraddress)
                    (created)
                    (description)
                    (dtstamp)
                    (geo)
                    (last-mod)
                    (priority)
                    (seq)
                    (status)
                    (summary)
                    (url)

All of these are meant to be optional, so they should be in square brackets, rather than in parentheses.  The same is true in Sections 7.2 and 7.3.

[Ballot comment]
Section 1.2 says "For example, we may want to record who is participating in a public event", but the Privacy Considerations section doesn't say anything about the fact that this could collect data about people who are interested in the event, even if they don't go (though the location issue is mentioned).  Also, especially since 2020, the public event could be a purely online event, where location data isn't part of the issue.  (Alternatively, if this is meant to address in-person events only, that would be useful to say up front.)

Section 6.2 (and other sections, but I noticed it here): ABNF literal strings are case-insensitive.  That means, for example, that the ABNF here would allow "ACTIVE" for a "partvalue", but would also allow "active", "AcTiVe", etc.  Is that acceptable?  (This probably applies to lots of prior CALEXT documents -- I admittedly didn't check -- so it may not be worth fixing here.)

Section 6.4:

  Property Parameters:  IANA, or non-standard property parameters can
      be specified on this property.

I think that should be "IANA-registered"?  Same issue in Sections 6.5 and 6.6.

Section 7: I believe the ABNF here needs a once-over.

Section 9.2: For the threat described in the first paragraph, are there any possible mitigations to suggest?

Section 10.2: In "without that participants express permission", that should be "participant's".  There's also a period missing at the end of the second last paragraph, though as it reads, it's possible there's even some intended text missing.

Section 11.2: The rules for making registrations into both the existing registries and these new ones are striking.  RFC 8126 doesn't even create a category that is a combination of Expert Review and Standards Action, but that's what this spells out.  And I wonder what would happen if we were to publish a Standards Track RFC (which has IETF consensus) with which the Designated Expert disagreed.  I'm not asking for anything to change here given that consistency with the existing registries is probably desirable, but it does set an unusually high bar for registrations.

[Ballot comment]
Section 1.2 says "For example, we may want to record who is participating in a public event", but the Privacy Considerations section doesn't say anything about the fact that this could collect data about people who are interested in the event, even if they don't go (though the location issue is mentioned).  Also, especially since 2020, the public event could be a purely online event, where location data isn't part of the issue.  (Alternatively, if this is meant to address in-person events only, that would be useful to say up front.)

Section 6.2 (and other sections, but I noticed it here): ABNF literal strings are case-insensitive.  That means, for example, that the ABNF here would allow "ACTIVE" for a "partvalue", but would also allow "active", "AcTiVe", etc.  Is that acceptable?

Section 6.4:

  Property Parameters:  IANA, or non-standard property parameters can
      be specified on this property.

I think that should be "IANA-registered"?  Same issue in Sections 6.5 and 6.6.

Section 7: I don't understand some of the ABNF here.  For "locprop", "resprop", and "partprop", parentheses appear to be used to mean "optional", but the ABNF way to say that is to use square brackets.  Rather, parentheses are meant to denote what it calls a "sequence group".  Can you explain what's going on here?

Section 9.2: For the threat described in the first paragraph, are there any possible mitigations to suggest?

Section 10.2: In "without that participants express permission", that should be "participant's".  There's also a period missing at the end of the second last paragraph, though as it reads, it's possible there's even some intended text missing.

Section 11.2: The rules for making registrations into both the existing registries and these new ones set a really high bar.  In fact RFC 8126 doesn't even create a category that is a combination of Expert Review and Standards Action, but that's what this spells out.  And I wonder what would happen if we were to publish a Standards Track RFC (which has IETF consensus) with which the Designated Expert disagreed.  Is this super high bar necessary?

[Ballot comment]
Thank you for addressing my Discuss points!

The new FlightReservation in §5.4 looks much more plausible; thanks.  I
guess I shouldn't complain that the dates are in 2017...

Section 5.1

While I can't fault the move from param-value to [list of quoted
string], I don't remember what the motivation was for that change.

Section 6.2

  If there is a related ATTENDEE proeprty then all parameters must

nit: s/proeprty/property/

Section 7.2

  For backwards compatibility wuth existing clients and servers when   
  used to schedule events and tasks the ATTENDEE property MUST be used
  to specify the sheduling parameters as defined for that property.     

nit: s/sheduling/scheduling/

  For other, future uses the CALENDAR-ADDRESS property MUST be used to
  specify those parameters.

I trust the responsible AD to ensure that this new requirement has
received the appropriate level of (WG and community) review.

Section 9

Thanks for the updates to the Security Considerations; they're a big
help!  I did make one further suggested improvement in my response
to my previous ballot's email thread.

Appendix B

At least some of the new versions are in 2020, not 2019

[Ballot comment]
Thanks for addressing my DISCUSS. Original comment:

Please respond to the Gen-ART review.

The abstract should mention the update to RFC 7986 and the introduction should explain what is updated.

Section 11:

"This specification does not
  introduce any additional privacy concerns beyond those described in
  [RFC5545]."

This seems untrue given the sentence that follows it, so this should be deleted.

[Ballot discuss]
Section 7.6:

" The format type and schema parameters can be specified on this
      property and are RECOMMENDED for text or inline binary encoded
      content information."

Doesn't this need to be REQUIRED rather than RECOMMENDED in order for it to improve rather than potentially worsen interoperability?

Section 8.1:

"User agents MUST NOT include this information
      without informing the participant."

This seems like it needs to say "without the participant's express permission." (As in https://www.w3.org/TR/geolocation-API).

[Ballot comment]
Please respond to the Gen-ART review.

The abstract should mention the update to RFC 7986 and the introduction should explain what is updated.

Section 11:

"This specification does not
  introduce any additional privacy concerns beyond those described in
  [RFC5545]."

This seems untrue given the sentence that follows it, so this should be deleted.

[Ballot comment]
I apologize - I run out of time to fully review this document, and so I'm balloting "NoObj" in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise or have no cycles" sense of the term.

[Ballot discuss]
Per the Security Considerations section, [RFC3986] and [W3C.REC-html51-20171003] were helpful.

I was hoping to see cautionary text for the potentially danger of handling/parsing arbitrary binaries as allowed by STRUCTURED DATA.  I didn’t see it in downstream references.
I also tried to find the referenced section suggested by “Security considerations relating to the ‘ATTACH’ property, as described in [RFC5545]” but could not.  It’s not the explicit Security Considerations (Section 7 of [RFC5545) or in the definition of Attachment (Section 3.8.1.1 of [RFC5545]).  Do you mean Section 3.1.3, Binary Content?  Could you please make it clear which section you meant.

[Ballot comment]
(1) Sections 5.1. and 5.2 state “New resource types SHOULD be registered in the manner laid down in this specification.”  It would be cleared if you explicitly referenced the relevant IANA section.

(2) Section 6.  Doesn't the sentence “[t]he SOURCE property defined in [RFC7986]  is redefined …” suggests that this document should also officially update RFC7986?

(3) Editorial nits:

Global.  “vcard” and “VCARD” is used interchangeably.  Recommend choosing one and being consistent

Section 2.  Misplaced comma?.  s/JSON,  [RFC8259]/JSON [RFC8259]

Section 3.  Typo.  s/informations/information/

Section 3.1.2. Typo. s/traveller/traveler/

Section 3.1.2.1.  Typo. s/non/none/

Section 7.5.  Typo.  s/sevices/services/

Section 9.2.  Typo.  s/plaaning/planning/

[Ballot discuss]
I want to talk some about the redefinition of SOURCE.  While I agree
that the original definition's applicability is more narrow than it
needs to be, that doesn't seem to be enough to convince me that there's
enough justification to make it so broad as to provide vcard information
about a participant or an event link-back, as opposed to just the
canonical source of updates for a given object/component.  I must
apologize for having essentially not done a search of the WG discussion
archives for this topic, and pointers into the archive could help to
convince me that this redefinition is a stable, interoperable, and
backwards-compatible choice.

The example in Section 5.4:

    STRUCTURED-DATA;FMTTYPE=application/ld+json;
      SCHEMA="https://schema.org/FlightReservation";
      ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy

contains an inline value that doesn't seem to decode to a valid
FlightReservation JSON object.

Perhaps I'm misreading, but the ABNF in Section 7.6 does not seem to
allow for an explicit VALUE=TEXT parameter to be given, and the
description does not list TEXT as the default value type.  (I note that
the listed example does include VALUE=TEXT, causing this to rise to a
Discuss-level internal inconsistency.)

Similarly, the examples in Section 8.1 seem incomplete, since they omit
the REQUIRED dtstamp and uid properties.

[Ballot comment]
Section 3

  The properties defined here can all reference external meta-data
  which may be used by applications to provide enhanced value to users.

This sentence seems to raise my hackles for two reasons: (1) it reads
like marketing copy and not a technical specification, and (2) it calls
to mind analogies to all the privacy-harming technologies that have
become pervasive in HTML mail and the web ecosystem: tracking pixels,
call-home URLs, etc..  While I agree that loading remote content can be
helpful, it is definitely a dual-use technology; I appreciate that the
privacy considerations attempt to cover the risks of remote content.
Perhaps there is additional room to nod to those risks at this point in
the document.

  Using STRUCTURED-LOCATION, information about a number of interesting
  locations can be communicated, for example, address, region, country,
  postal code as well as other informations such as the parking,
  restaurants and the venue.  [...]

nit: "the parking" is incomplete; perhaps "parking availability"?
nit: "restaurants" is also incomplete; perhaps "nearby restaurants"?

                          In social calendaring it is often important
  to identify the active participants in the event, for example a
  school sports team, and the inactive participants, for example the
  parents.

I share the directorate reviewer's confusion as to what "social
calendaring" is.

Section 3.1.1

            In addition, there will be sponsorship information for
  sponsors of the event and perhaps paid sponsorship properties
  essentially advertising local establishments.

I'm not sure how much precedent the IETF has for facilitating
advertising as a specific goal.

Section 3.1.2.1

  A meeting may have 10 attendees non of which are co-located.  The

nit: s/non/none/

  current ATTENDEE property does not allow for the addition of such
  meta-data.  The PARTICIPANT property allows attendees to specify
  their location.

nit: PARTICIPANT is a component, not a property.

Section 4

Please be more concrete about what actually is changing, e.g., the
addition of participantc to eventc/todoc/journalc, as well as the more
obvious incremental addition to the properties' ABNF.
Making the reader cross-reference to RFC 5545 for each ABNF production is
rather unfriendly.

Section 5.2

Is a video remote conferencing facility assumed to also provide audio
functionality?

Section 5.3

nit: "lowest level of ordering" is perhaps ambiguous (though the
subsequent clarification is not); I'd suggest just "as being ordered
last".

  Example uses:  The ORDER may be applied to the PARTICIPANT-TYPE
      property to indicate the relative importance of the participant,
      for example as a sponsor or a performer.  For example, ORDER=1
      could define the principal performer or soloist.

side note: It's not very clear to me that it's going to be possible to
assign a complete ordering to all participants once events start getting
complicated.  There is the option of just leaving a single low-priority
"everybody else" bucket and not worrying too hard, but this feels like
something easy that gets a quick win but will not be a full solution.
(Which, to be clear, is not necessarily bad.)

Section 5.5

While I'm sympathetic to not actually putting a full HTML styled
description in the example, I'd suggest at least putting in the closing
tag.

Section 7.1

nit: is there a reason for active participants to be taking a "role" but
inactive ones taking a "part"?

Section 7.3

It's not clear to me when one would attach an alternative representation
to a STYLED-DESCRIPTION rather than just adding the other representation
as another STYLED-DESCRIPTION in its own right.  Presumably this just
means I'm not an iCalendar expert, but maybe there is something more
subtle going on here.

Section 7.4

Do we want a reference to RFC 7986 again for the LABEL parameter?

      When used in a component the value of this property provides
      information about the event venue or of related services such as
      parking, dining, stations etc..

Does this hold universally for all components (e.g., even PARTICIPANT) or
only some of them?

I don't understand all the discussion about the "Use of the related
parameter", which is presumably just my lack of familiarity with
iCalendar in general.  But it's surprising that we'd have to worry about
timezones and such for events/todos related to a structured *location*.

Section 7.5

    strucewaval  = ( uri / text )

"strucewaval" seems like a typo and does not appear elsewhere in the
document.

Section 8.1

  Conformance:  This component can be specified multiple times in a
      "VEVENT", "VTODO", "VJOURNAL", or "VFREEBUSY" calendar component.

  Description:  This component provides information about a participant
      in an event, task or poll.  [...]

Why do these two lists have different cardinality?

  Privacy Issues:  When a LOCATION is supplied it provides information
      about the location of a participant at a given time or times.
      This may represent an unacceptable privacy risk for some
      participants.  User agents MUST NOT include this information
      without informing the participant.

How is this "informing" supposed to work when the participant is not a
human (e.g., an organizational SPONSOR or a sports team)?

Also, it seems likely that there may be attributes (parameters) other
than location that a given individual may not wish to be disclosed, or
at least disclosed globally.

In the last example:

                    BEGIN: PARTICIPANT
                    SOURCE;FMTTYPE=text/vcard;

this last semicolon should be a colon?

                      http://dir.example.com/vcard/contacts/contact1.vcf
                    PARTICIPANT-TYPE:CONTACT
                    DESCRIPTION:A contact:

The last colon here is superflous?

                    END:PARTICIPANT

Section 8.2

It's not entirely clear to me that we need this much discussion about
schedulable PARTICPANTs -- can't we get most of the way with the
status quo of ATTENDEE properties being schedulable, and just noting
that for such ATTENDEEs, the matching PARTICIPANT may have additional
(e.g., location) information?

Section 9.1

This example seems to illustrate a weakness of STRUCTURED-LOCATION,
namely that it relies upon the human readaing the LABEL parameter to
understand what type of relationship the location has to the event.  It
seems that calendaring software would be able to present a better
interface if there was some structured information available about the
type of location, as well as the freeform string of the label.

Section 9.2

The time gap between DTSTAMP and CREATED is rather large; is that
intended?

It might also be helpful to give some indication of the meeting room
where the event is nominally occurring, so as to make the "At home"
location more clearly a remote location.

Section 10

Potential additional security considerations: the target of the
CALENDAR-ADDRESS URLs may have access control on them, and not all
recipients of the property may be authorized to access the referenced
calendar.  Such access control is properly a matter for the owner of the
calendar in question, but it may still be appropriate to mention it
here.

  Security considerations relating to the "ATTACH" property, as
  described in [RFC5545], are applicable to the "STRUCTURED-DATA"
  property.

I had a quick look in RFC 5545, and neither the labelled Security
Considerations section nor any mention of "ATTACH" (with quotes) seemed
to cover such security considerations.  What am I missing?

  When processing HTML content applications need to be aware of the
  many security and privacy issues as described in the IANA
  considerations section of [W3C.REC-html51-20171003]

nits: this needs at least a comma after "content", and possibly another
comma before "as described".

Section 11

There may be some privacy considerations relating to the ORDER
parameter, as it provides an indication of some entity (the
organizer's?) perception of the relative importance of other
participants.

  The addition of location information to the new participant component
  provides information about the location of participants at a given
  time.

We probably should go a little further and note that this may facilitate
tracking of individuals or malicious actions targeted against them at
the known location/time pair.

[Ballot discuss]
Thanks for the work in this document; I think there’s useful stuff here, and I appreciate what it took to put it together.  One thing at the DISCUSS level:

— Section 10 —
It’s good to refer to RFC 3986 for URI-related security considerations, and all of them do apply here.

Something else that comes to mind that comes along with a set of new URIs is whether they actually point to what they say they do.  I don’t see that there’s any way to verify that they do, and I’m very skeptical about the effectiveness of warning an end user about this sort of thing, for many reasons.  I can see why allowing URIs is convenient and compelling, but I’m very heavily concerned about tracking and other privacy leaks, malicious and deceptive content, and other such problems, especially considering the prevalence of abusive calendar invitations these days.

I’m not sure what the answer is here, but let’s have a discussion about it and see where we can go with it.

Update: We will discuss this in the calext interim meeting, jointly with CalConnect.

[Ballot comment]
— Section 3 —
As with Section 1, you’re going into detail about the properties and component, details that again seem out of place.  Again, I suggest moving those details into the sections that define those items, and promoting Section 3.1 to be Section 3 (so Section 3 becomes the “Use Cases”).


======== Resolved comments below; thanks for addressing them. ========

— Section 1 —
This strikes me as far too much detail for the Introduction.  You give a bit of detail about each component, property, and parameter — details that should simply be left for the definitions that come later.  Even listing them isn’t necessary, because there’s a table of contents.  Having all that in the Introduction puts it out of context: it’s too early in the document for a reader to get the details, and it comes out as rather disorganized, scattered.

I suggest merging the paragraph about the PARTICIPANT component into the second paragraph of Section 2, and then removing everything after that from Section 1 entirely.  The information should instead go into an introductory paragraph in each added element’s definition section.

— Section 2 —

  This is a
  better match for the way [W3C.REC-xml-20081126] and JSON, [RFC8259]
  handles such structures and allows richer definitions.

There’s an extraneous comma after “JSON”, and it should be “handle” to match the plural subject.

— Sections 5.2, 7.1, and 8.1 —
Please see BCP 178 (RFC 6648), and then remove x-name and x-prop.  Thanks.

— Section 5.3 —

      Its value MUST be an integer greater than or equal to 1 that
      quantifies the order with 1 being the first in the ordering.

You quantify cardinal numbers, not ordinal numbers.  I think “specifies” is the word you want here.

      A given value, or the
      absence of a value, MUST NOT be interpreted on its own.

I don’t understand what this means; can you explain?

      This parameter MAY be applied to any property that allows multiple
      instances.

What about properties that don’t allow multiple instances?  This MAY is unnecessary because you already have the equivalent “OPTIONAL” at the beginning if the definition.  I think your intent here is this:

NEW
      This parameter MUST NOT be applied to a property that does not
      allow multiple instances.
END

— Section 6 —

  Purpose:  This property provides a reference to information about a
      component such as a participant possibly as a vcard or optionally
      a plain text typed value.

This sentence needs some punctuation or rephrasing in order to make sense.  Can you try?

— Section 8.1 —

  Description:  This component provides information about an
      participant in an event, task or poll.

Make it “a participant”.

[Ballot comment]
A couple of comments/questions:

1) “In addition the SOURCE property defined in [RFC7986] is redefined to
  allow VALUE=TEXT and broaden its usage.”
As you redefine the SOURCE property, this document should probably update RFC7986.

2) “This section defines updates to the tables defined in [RFC5545] and new tables.”
I wouldn’t think that the table in RFC5545 need to be “updated”. Isn’t the whole purpose of having a registry that you don’t need to update another document in order to extend the table elements? I would recommend to just define the new and updated elements.

3) “These tables may be updated using the same
  approaches laid down in Section 8.2.1 of [RFC5545]”
I find the use of the word “may” here a bit blurry. I would propose simply “are updated”.

4) Why is this document Proposed Standard? The shepherd write-up sounds like the review and deployment of these extension is currently very limited and therefore experimental might be more appropriate…? It’s looks like the change of the SOURCE property needs standards track, however, maybe it would be better to split this up in a separate document then?

5) Can you maybe further elaborate what the use case for the Order Property Parameter is?

6) “When a LABEL parameter is supplied the language of the label must
      match that of the content and of the LANGUAGE parameter if
      present.”
Shouldn’t this be a normative MUST? Or actually probably a SHOULD?

[Ballot comment]
Thanks for the work everyone has put into this document. I liked the section 3.1 'use cases' providing insights on the goal, same for the section about extended examples.

I only have one comment and a couple of nits.

== COMMENT ==


-- Section 4 --

If this syntax replaces completely or partly the one of RFC 5545, then it should be clear in the text (and I have seen that other iCal RFC use the same introduction). What about the other RFC that also update RFC 5545? Is their syntax also impacted?


== NITS ==

-- Section 1  --

Please introduce VCARD before using the word, other words in this section are obvious to the reader.

-- Section 2 --

Missing a '.' at the end of first paragraph.

-- Section 5.4 --

Please use https://example.org rather than https://schema.org or is it a reference, existing URI ?

-- Section 13 --

Last sentence ends with a ','

[Ballot discuss]
Thanks for the work in this document; I think there’s useful stuff here, and I appreciate what it took to put it together.  Two things at the DISCUSS level:

— Sections 5.2, 7.1, and 8.1 —
Please see BCP 178 (RFC 6648), and then remove x-name and x-prop.  Thanks.

— Section 10 —
It’s good to refer to RFC 3986 for URI-related security considerations, and all of them do apply here.

Something else that comes to mind that comes along with a set of new URIs is whether they actually point to what they say they do.  I don’t see that there’s any way to verify that they do, and I’m very skeptical about the effectiveness of warning an end user about this sort of thing, for many reasons.  I can see why allowing URIs is convenient and compelling, but I’m very heavily concerned about tracking and other privacy leaks, malicious and deceptive content, and other such problems, especially considering the prevalence of abusive calendar invitations these days.

I’m not sure what the answer is here, but let’s have a discussion about it and see where we can go with it.

[Ballot comment]
The document organization points below are on the edge of DISCUSS for me, but in the end I thing the document is readable as it is, so I’ve made them COMMENT level.  But PLEASE consider what I’m suggesting, because I think it would really help the flow and understandability.

— Section 1 —
This strikes me as far too much detail for the Introduction.  You give a bit of detail about each component, property, and parameter — details that should simply be left for the definitions that come later.  Even listing them isn’t necessary, because there’s a table of contents.  Having all that in the Introduction puts it out of context: it’s too early in the document for a reader to get the details, and it comes out as rather disorganized, scattered.

I suggest merging the paragraph about the PARTICIPANT component into the second paragraph of Section 2, and then removing everything after that from Section 1 entirely.  The information should instead go into an introductory paragraph in each added element’s definition section.

— Section 2 —

  This is a
  better match for the way [W3C.REC-xml-20081126] and JSON, [RFC8259]
  handles such structures and allows richer definitions.

There’s an extraneous comma after “JSON”, and it should be “handle” to match the plural subject.

— Section 3 —
As with Section 1, you’re going into detail about the properties and component, details that again seem out of place.  Again, I suggest moving those details into the sections that define those items, and promoting Section 3.1 to be Section 3 (so Section 3 becomes the “Use Cases”).

— Section 5.3 —

      Its value MUST be an integer greater than or equal to 1 that
      quantifies the order with 1 being the first in the ordering.

You quantify cardinal numbers, not ordinal numbers.  I think “specifies” is the word you want here.

      A given value, or the
      absence of a value, MUST NOT be interpreted on its own.

I don’t understand what this means; can you explain?

      This parameter MAY be applied to any property that allows multiple
      instances.

What about properties that don’t allow multiple instances?  This MAY is unnecessary because you already have the equivalent “OPTIONAL” at the beginning if the definition.  I think your intent here is this:

NEW
      This parameter MUST NOT be applied to a property that does not
      allow multiple instances.
END

— Section 6 —

  Purpose:  This property provides a reference to information about a
      component such as a participant possibly as a vcard or optionally
      a plain text typed value.

This sentence needs some punctuation or rephrasing in order to make sense.  Can you try?

— Section 8.1 —

  Description:  This component provides information about an
      participant in an event, task or poll.

Make it “a participant”.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

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

The IANA Functions Operator understands that upon approval of this document, there are five actions to be completed.

First, in the Properties registry on the iCalendar Element Registries page located at

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

seven new registrations will be made:

Property: CALENDAR-ADDRESS
Status: Current
Reference: [ RFC-to-be ] Section 7.2

Property: PARTICIPANT-TYPE
Status: Current
Reference: [ RFC-to-be ] Section 7.1

Property: SOURCE
Status: Current
Reference: [ RFC-to-be ] Section 6

Property: STRUCTURED-DATA
Status: Current
Reference: [ RFC-to-be ] Section 7.6

Property: STYLED-DESCRIPTION
Status: Current
Reference: [ RFC-to-be ] Section 7.3

Property: STRUCTURED-LOCATION
Status: Current
Reference: [ RFC-to-be ] Section 7.4

Property: STRUCTURED-RESOURCE
Status: Current
Reference: [ RFC-to-be ] Section 7.5

As this document requests registrations in an Expert Review (see RFC 8126) registry, we have initiated the required review in a separate ticket.

Second, in the Parameters registry also on the iCalendar Properties Registries page located at

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

four new registrations will be made:

Parameter: LOCTYPE
Status: Current
Reference: [ RFC-to-be ] Section 5.1

Parameter: ORDER
Status: Current
Reference: [ RFC-to-be ] Section 5.2

Parameter: RESTYPE
Status: Current
Reference: [ RFC-to-be ] Section 5.3

Parameter: SCHEMA
Status: Current
Reference: [ RFC-to-be ] Section 5.4

We have initiated the required expert review in a separate ticket.

Third, in the Components registry also on the iCalendar Element Registries page located at

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

one new registration will be made:

Component: PARTICIPANT
Status: Current
Reference: [ RFC-to-be ] Section 8.1

We have initiated the required expert review in a separate ticket.

Fourth, a new registry called Participant Types will be created under the heading "iCalendar Element Registries" at

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

The new registry will be managed via Expert Review as defined in RFC 8126. These are the initial registrations:

+-------------------+---------+----------------------------+
| Participant Type | Status | Reference |
+-------------------+---------+----------------------------+
| ACTIVE | Current | [ RFC-to-be ], Section 7.1 |
| INACTIVE | Current | [ RFC-to-be ], Section 7.1 |
| SPONSOR | Current | [ RFC-to-be ], Section 7.1 |
| CONTACT | Current | [ RFC-to-be ], Section 7.1 |
| BOOKING-CONTACT | Current | [ RFC-to-be ], Section 7.1 |
| EMERGENCY-CONTACT | Current | [ RFC-to-be ], Section 7.1 |
| PUBLICITY-CONTACT | Current | [ RFC-to-be ], Section 7.1 |
| PLANNER-CONTACT | Current | [ RFC-to-be ], Section 7.1 |
| PERFORMER | Current | [ RFC-to-be ], Section 7.1 |
| SPEAKER | Current | [ RFC-to-be ], Section 7.1 |
+-------------------+---------+----------------------------+

Fifth, a new registry called Resource Types will be created under the heading "iCalendar Element Registries" at

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

The new registry will be managed via Expert Review as defined in RFC 8126. These are the initial registrations:

+-------------------------+---------+----------------------------+
| Resource Type | Status | Reference |
+-------------------------+---------+----------------------------+
| PROJECTOR | Current | [ RFC-to-be ], Section 5.2 |
| ROOM | Current | [ RFC-to-be ], Section 5.2 |
| REMOTE-CONFERENCE-AUDIO | Current | [ RFC-to-be ], Section 5.2 |
| REMOTE-CONFERENCE-VIDEO | Current | [ RFC-to-be ], Section 5.2 |
+-------------------------+---------+----------------------------+

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,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-04-29):

From: The IESG
To: IETF-Announce
CC: daniel.migault@ericsson.com, draft-ietf-calext-eventpub-extensions@ietf.org, Daniel Migault , calext-chairs@ietf.org, calsify@ietf.org, alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Event Publishing Extensions to iCalendar) to Proposed Standard


The IESG has received a request from the Calendaring Extensions WG (calext)
to consider the following document: - 'Event Publishing Extensions to
iCalendar'
  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
ietf@ietf.org mailing lists by 2019-04-29. 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 updates RFC5545 by introducing a number of new
  iCalendar properties and components which are of particular use for
  event publishers and in social networking.

  This specification also defines a new STRUCTURED-DATA property for
  iCalendar RFC5545 to allow for data that is directly pertinent to an
  event or task to be included with the calendar data.




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

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


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

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?

(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.

  This specification updates [RFC5545]  and [RFC5546] by introducing a
  number of new iCalendar properties and components which are of
  particular use for event publishers and in social networking.

  This specification also defines a new STRUCTURED-DATA property for
  iCalendar [RFC5545] to allow for data that is directly pertinent to
  an event or task to be included with the calendar data.


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?

The document dd not raised any controversy, but in my opinion the document would need some more feed backs from the community. At this point we mostly rely on the experience of the author as well as his own implementation. 

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?

Michael has a partial implementation. He will make it public soon.


Personnel

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

Daniel Migault is the document shepherd and Alexey Melnikov 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.

I reviewed carefully the document, but I am not a calendar expert. My reviews have been sent to the list and my comments have been addressed by the author.

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

I believe more reviews would have been welcome. Though none objected anything, and the probability of wrong design is relatively low, the quality of the document is based on the implementation and seriousness of his author. 


(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. iCalendar syntax is being used, and the expertise is in the WG.

(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.

None

(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.

The author mention that he is 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.

No IPR disclosure has been filed.

(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? 

None objected to the draft.

(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.

idnits 2.16.0

/tmp/draft-ietf-calext-eventpub-extensions-10.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 :
  ----------------------------------------------------------------------------

  ** There is 1 instance of too long lines in the document, the longest one
    being 1 character in excess of 72.


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

    (Using the creation date from RFC5545, updated by this document, for
    RFC5378 checks: 2008-10-31)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)


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

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

    No issues found here.

    Summary: 1 error (**), 0 flaws (~~), 0 warnings (==), 1 comment (--).

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

--------------------------------------------------------------------------------
I do not believe this applies here as the current document does not cite these documents.


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

do not apply here.

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

Yes.

(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?

All reference have been published.

(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.

This document will update  RFC5545. This is specified in the header, abstract and introduction

(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 5226).

The IANA section seems fine to me. The IANA allocation is under expert review and potential expert could be Bernard Desruisseaux, or Cyrus Daboo.

https://www.iana.org/assignments/icalendar/icalendar.xhtml#properties


(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.

see above.

(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