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

["Bron Gondwana" <[e-mail]>]

Hi Doug,

Thanks for engaging here - I'm glad you came across and took a look. This sort of thorough review is really important to creating a good document. I'm going to try to address the reasoning behind one specific bit here -- why differences!

Cheers,

Bron.

On Tue, May 14, 2019, at 08:09, Doug Royer wrote:
> Why change the names and some formats of existing types?
> One example why were the dashes added to date? (YYYYMMDD vs YYYY-MM-DD)

rfc3339 `full-date` and improved readability. YYYY-MM-DD is far superior in terms of lack of ambiguity and even lack of being accidentally interpreted as an integer when roundtripped through type-unsafe languages.

> It seems like a lot of work is being done to make it incompatible and 
> complicate the conversion process.

Compatibility is important - a lack of ambiguity and attractiveness to developers is more important if it wants to gain adoption than slavish compatibility with the existing format.

> In some cases only the case of the token was changed (UID -> uid).
> I do not see a technical reason, and it just adds to some confusion.
> Does it really matter to any code? Users will not see the contents.

ICALENDAR is case insignificant. JSON is case significant. It's necessary to chose an explicit case for JSON, and we decided on lowercase because that's what's generally expected by JSON-native developers.

> It just seems that someone did not like the names and wanted to start over.

Usability and familiarity to programmers are important factors, and they were considered when creating a JSON format which is expected to attract usage.

Bron.

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [e-mail]