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

[Michael Douglass <[e-mail]>]

On 12/15/20 13:03, Barry Leiba wrote:
> 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.
I think it's reasonable to remove them from this spec
>
> 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").

I think we've already moved in practice away from  x-. It's just we 
haven't explicitly said so anywhere.

Probably an agenda item for the next meeting?

>
> 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
>>
>>
>>
>>