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

[Michael Douglass <[e-mail]>]

Thank you. Updates will appear in version 15

On 5/29/19 15:05, Roman Danyliw via Datatracker wrote:
> 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.
Not sure what I was looking at there. I have found some managed 
attachments text which I have modified and added
>
>
> ----------------------------------------------------------------------
> 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.
Done
>
> (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?
We're no longer updating that property
>
> (3) Editorial nits:
>
> Global.  “vcard” and “VCARD” is used interchangeably.  Recommend choosing one
> and being consistent
Used vCard throughout
>
> 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/
All done.
>
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify