[calsify] Roman Danyliw's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-calext-eventpub-extensions-13: 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:
----------------------------------------------------------------------

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.


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