Re: [calsify] WGLC JSCalendar

Hi,

While discussion can continue. I am confident a consensus will be find.

I am writing the write-up shepherd and here are some elements I would
like to clarify:

1) IPR

Could each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.

2) existing implementation

Has any organization planing to implement JSCalendar - apart fast mail. If
you are aware of any implementation that would help our ADs.

3) URIs section.

This is clearly a detail, but I am not sure the URIs section is actually
standard. I expect that we will be asked to move it to Informative section.

Yours,
Daniel

On Mon, Oct 28, 2019 at 1:18 AM Michael Douglass <mikeadouglass@gmail.com>
wrote:

>
> On 10/28/19 00:55, Neil Jenkins wrote:
>
> On Mon, 28 Oct 2019, at 15:36, Michael Douglass wrote:
>
> As for the @path - In section 4.3.3 (version 21) for recurrence overrrides
> we have
>
>    A pointer in the PatchObject MUST be ignored if it starts with one of
>    the following prefixes:
>
>    o  @type
> and a bunch more
>
>
> That's just to do with the application of the patch in this instance, not
> an inherent attribute of the PatchObject. The PatchObject is used
> generically in JMAP RFC8620, Section 5.3
> <https://tools.ietf.org/html/rfc8620#section-5.3>, and it makes no sense
> for it to have properties that are not patches; that would mean
> semantically "every key in this object is a patch except if it's this
> special value", which would be horrible to work with.
>
> Well my experience in implementing it is the reverse. Having the @type
> simplifies things considerably.
>
> However - in the absence of any other input (an invitation for anybody
> else to state an opinion on either side) I'll live with it.
>
>
> Neil.
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify
>