[calsify] Barry Leiba's Discuss on draft-ietf-calext-eventpub-extensions-12: (with DISCUSS and COMMENT)

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-calext-eventpub-extensions-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/



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


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