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

[Michael Douglass <[e-mail]>]

I should perhaps point out that many of these issues are really due to 
the practice of requiring full replacement of an entity rather than 
having an update mechanism.

SOAP for example, explicitly requires that an unrecognized (by the 
schema) element be dropped so it's a requirement to have an update 
mechanism that doesn't require a full copy of the data. The 
specification only defines what's valid.

I've been advocating for some time (while recognising the work involved) 
that we should have a data model specification that is independent of 
the representation. Other specs defining representations would then 
effectively be mappings onto the model.

OASIS - I believe - does this with their pim - a platform independent 
model. The psm is the platform specific model which defines that mapping.

They do in fact have a pim for a large subset of the calendaring model.

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-calendar#technical


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