Re: [calsify] Roman Danyliw's No Objection on draft-ietf-calext-ical-relations-09: (with COMMENT)

On 2/16/22 11:14, Roman Danyliw via Datatracker wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-calext-ical-relations-09: No Objection
>
> 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 tohttps://www.ietf.org/blog/handling-iesg-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-ical-relations/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to Catherine Meadows for the SECDIR review.
>
> ** Abstract.  The abstract text needs to mention that it is updating RFC5545.
Done
>
> ** Section 6.2.  Typo. s/temporaly/temporarily/

Actually not a type but arguably a bad word. It's a temporal relationship.

--------- OLD

between two temporaly related components.

--------- NEW

between two components with a temporal relationship.

-------------

>
> ** Section 8.1.  Per the example,
> “CONCEPT:http://example.com/event-types/arts/music”  should this use https?
All http should now be https
>
> ** Section 10.  Thanks for noting the RFC3986 considerations on using URIs.
> Digging a bit more into the implementation approaches of the CONCEPT parameter,
> would clients be expected dereference the taxonomy URI in real-time?   I’m
> wondering if there would be a chance for tracking mechanism akin to a “web bug”
> on a web page or in HTML email.  For example, an .ics file is sent via an
> asynchronous mechanism (email) with a CONCEPT URI to something unique/unknown
> to the end-client and to a destination controlled by the sender or even a third
> party.  Could it function as a read-receipt or to harvest an identifier for the
> system the client is on (IP address)?
Not in general - the URI itself is enough. The referenced document might 
be used in searches but not when retrieving the calendar entity.
>
>
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify