Re: [calsify] draft-ietf-calext-jscalendar - excluded

[Doug Royer <[e-mail]>]

On 5/14/19 2:24 PM, Marten Gajda wrote:
> 
> Am 14.05.19 um 03:40 schrieb Doug Royer:
>> >> 12. _excluded_ property (4.3.2). I assume (ambiguous) if it can ever
>> >> be set to false? Can I send it in object set to false at all? When
>> >> would it be valid to set it to false? What is the point of ever being
>> >> able to send one set to false?
>> >
>> > This property represents what's EXDATEs in iCalendar. It could be set
>> > to false, but it's only really useful to set it to true, or not at
>> > all.
>>
>> Just trying to reduce dead code issues in implementations (ambiguous 
>> handling and expectations). If the spec specifically said that it 
>> should only be supplied when TRUE, then no code will ever be written 
>> to do otherwise.
>>
>> No need to code "... else when set to false ..." because that code 
>> would NEVER execute == dead code.
> 
> Every implementation should be able to handle `false`. It's the default 
> if the property is absent and there may be implementations which prefer 
> being explicit rather than relying on defaults. We see this in iCalendar 
> a lot when implementations specify VALUE=DATE-TIME even though it's the 
> default for those properties.
> 
> I don't see much of an issue here, especially since the `false` path is 
> the same as the "absent" path.

Every implementation being able to handle false is not the same thing as 
every implementation handling false differently - because it is NOT 
documented in the spec - so just guess? Yes a small hole.

I would bet that some implementations may default to true, others false, 
then when the two meet, oops happens because of some other seemingly 
unrelated issue.


--
Doug Royer (http://DougRoyer.US http://SoftwareAndServices.US)