Summary: Has 4 DISCUSSes. Needs one more YES or NO OBJECTION position to pass.
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).
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.
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 126.96.36.199 of [RFC5545]). Do you mean Section 3.1.3, Binary Content? Could you please make it clear which section you meant.
(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 188.8.131.52. Typo. s/non/none/ Section 7.5. Typo. s/sevices/services/ Section 9.2. Typo. s/plaaning/planning/
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.
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 184.108.40.206 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 </html> 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.
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.
— 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”.
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.
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?
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 ','