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

From: Doug Royer <[email-masked]>
Date: Mon, 13 May 2019 19:40:34 -0600

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

-- 

Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Marten Gajda <[email-masked]>
Date: Tue, 14 May 2019 22:24:26 +0200

Am 14.05.19 um 03:40 schrieb Doug Royer:
> 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.

Marten

>
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: Doug Royer <[email-masked]>
Date: Thu, 16 May 2019 21:24:43 -0600

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

---

From: Doug Royer <[email-masked]>
Date: Thu, 16 May 2019 21:50:31 -0600

> the same as the "absent" path.

And I just checked, that is not in the spec. A reader would have to 
assume that. From the spec:

4.3.3.  excluded

    Type: "Boolean" (optional, default:"false")

    Defines if this object is an overridden, excluded instance of a
    recurring JSCalendar object (also see Section 4.3.2).  If this
    property value is "true", this calendar object instance MUST be
    removed from the occurrence expansion.

I could assume that when set to false, it is added as an instance and 
not intended to indicate an instance removed.

---

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 17 May 2019 15:41:15 +1000

>  Type: "Boolean" (optional, default:"false")

The *default: "false"* bit means that absent is the same as false. This is what the default annotation is for.

> not intended to indicate an instance removed.

I agree it never hurts to be explicit and say that a value of `false` has no effect.

Neil.