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

[Barry Leiba <[e-mail]>]

I agree that it's not up to this document to deprecate x- for
iCalendar in general, I agree that we should probably consider a
5545bis, and that we might at least consider a separate doc to
deprecate x-.  Still, I see no reason that we shouldn't *now*
eliminate "x-" from new extensions/additions that we publish.

That said, I'm not going to hold out on this point, and if the working
group thinks it's best to leave "x-" in for now, I will still move the
document forward.  But I'd like to hear *why* the working group think
that (and not just "because it's still in a lot of other places as
well").

Barry

On Tue, Dec 15, 2020 at 12:26 PM Michael Douglass
<[e-mail]> wrote:
>
> 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]); 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
>
>
>
>