[calsify] Roman Danyliw's Yes on draft-ietf-calext-jscontact-vcard-07: (with COMMENT)

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

Roman Danyliw has entered the following ballot position for
draft-ietf-calext-jscontact-vcard-07: Yes

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Phillip Hallam-Baker for the SECDIR review

Thank you Paul Kyzivat for the ARTAR review

** There are a few actionable tasks from idnits:

  -- The draft header indicates that this document updates RFC6350, but the
     abstract doesn't seem to mention this, which it should.

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

** Section 2.1.2.

    Whatever identifier generation
   scheme implementations use, they SHOULD generate values of short
   character length.  For example, this could be an incrementing number
   across all Ids or only unique within one JSON object.

Given that this guidance carries is a normative SHOULD, is there any hint on
what constitutes “short”?

** Section 2.2.2

   The TIME, DATE-TIME, DATE-AND-OR-TIME types and DATE type values that
   only define a month or day do not convert to any JSContact type.
   vCard properties or parameters having such values MAY convert as
   defined in Section 2.16.

What is the proposed alternative if NOT following the mechanism described for
Section 2.16.

** Please use https in example instead of http.  See Section 2.6.6, 2.10.2,
2.13.1, 2.14.1, 2.14.2, 2.14.3

** Section 2.14.2.  Per the use of the FTP example (Figure 42), is it common to
serve a .ics over a plaint-text channel with no integrity protection.  It seems
like calendaring information might be sensitive.  Perhaps ftps:// or just
another https:// example?