Re: [calsify] AD review of draft-ietf-calext-ical-relations-05

[Michael Douglass <[e-mail]>]

I'm hoping to get through all your message today but I thought I'd deal 
with at least one point separately:

On 11/19/20 14:08, Barry Leiba wrote:

> This is probably a good time to pay attention to BCP 178 (RFC 6648) by
> removing the x-name construction from the ABNF (also in Section 5.1).
>
>
I agree with your point - however 6648 says

>     5.  Does not override existing specifications that legislate the use
>         of "X-" for particular application protocols (e.g., the "x-name"
>         token in [RFC5545  <https://tools.ietf.org/html/rfc5545>]); this is a matter for the designers of those
>         protocols.
So 5545 in section 3.1 defines x-name

and goes on to say:

>     Applications MUST ignore x-param and iana-param values they don't
>     recognize.
There are about 50 references to "x-".

In section 3.6 I found

> Applications MUST ignore
>     x-comp and iana-comp values they don't recognize.  Applications that
>     support importing iCalendar objects SHOULD support all of the
>     component types defined in this document, and SHOULD NOT silently
>     drop any components as that can lead to user data loss.
>
On a side note in section 3.6.6 I found this:

>           Note: Implementations should carefully consider whether they
>           accept alarm components from untrusted sources, e.g., when
>           importing calendar objects from external sources.  One
>           reasonable policy is to always ignore alarm components that the
>           calendar user has not set herself, or at least ask for
>           confirmation in such a case.
>
>
and 3.8.6.1

>   Applications MUST ignore alarms with x-name
>        and iana-token values they don't recognize.
>
3.8.8.1 and 3.8.8.2 deals with iana and x-properties

I think what I'm working round to saying is that it's probably time to 
consider a replacement for 5545. In my opinion 5545+ should state up 
front what MUST be processed and what CAN or SHOULD be ignored (though 
that may differ with the protocol used)

In the shorter term we probably at least ought to have an update which 
explicitly deprecates x- for 5545