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

Thanks Barry.

On 5/16/19 04:14, Barry Leiba via Datatracker wrote:
> 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.
Removed
> — 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.
Maybe a brief discussion at CalConect/IETF meeting?
>
> ----------------------------------------------------------------------
> 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.
Done
> — 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.
Yes - done
> — 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?
No. Not sure what I was trying to say. I think the preceding sentence is 
sufficient.
>        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
Done
> — 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?

Is this better?

	This property provides a reference to information
	about a component such as a participant. For example, that
	information may be a vcard or a plain text typed value.

> — Section 8.1 —
>
>     Description:  This component provides information about an
>        participant in an event, task or poll.
>
> Make it “a participant”.
Done
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify