Subject: [calsify] Mirja Kühlewind's No Objection on draft-ietf-calext-eventpub-extensions-12: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Fri, 24 May 2019 10:36:19 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-calext-eventpub-extensions-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A couple of comments/questions:

1) “In addition the SOURCE property defined in [RFC7986] is redefined to
   allow VALUE=TEXT and broaden its usage.”
As you redefine the SOURCE property, this document should probably update
RFC7986.

2) “This section defines updates to the tables defined in [RFC5545] and new
tables.” I wouldn’t think that the table in RFC5545 need to be “updated”. Isn’t
the whole purpose of having a registry that you don’t need to update another
document in order to extend the table elements? I would recommend to just
define the new and updated elements.

3) “These tables may be updated using the same
   approaches laid down in Section 8.2.1 of [RFC5545]”
I find the use of the word “may” here a bit blurry. I would propose simply “are
updated”.

4) Why is this document Proposed Standard? The shepherd write-up sounds like
the review and deployment of these extension is currently very limited and
therefore experimental might be more appropriate…? It’s looks like the change
of the SOURCE property needs standards track, however, maybe it would be better
to split this up in a separate document then?

5) Can you maybe further elaborate what the use case for the Order Property
Parameter is?

6) “When a LABEL parameter is supplied the language of the label must
      match that of the content and of the LANGUAGE parameter if
      present.”
Shouldn’t this be a normative MUST? Or actually probably a SHOULD?

---

From: Michael Douglass <[email-masked]>
Date: Sat, 25 May 2019 23:14:35 -0400

Thanks Mirja

> https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
Yes - thanks.
> define the new and updated elements.
Removed that paragraph
> I find the use of the word “may” here a bit blurry. I would propose simply “are
Done
> to split this up in a separate document then?

Some vendors already use x-properties (if I can use the term) to support 
a number of the features being standardized here (e.g. locations and 
rich text).

This specification is a attempt to provide a standard for current behaviour

> 5) Can you maybe further elaborate what the use case for the Order Property
Added some text giving example use
> Shouldn’t this be a normative MUST? Or actually probably a SHOULD?
Yes - done
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Mirja Kuehlewind <[email-masked]>
Date: Sun, 26 May 2019 13:23:59 +0200

Thanks!

If this is already in use, I guess PS is fine. Just the shepherd-write up sounded differently.

> On 26. May 2019, at 05:14, Michael Douglass <[email-masked]> wrote:
> 
> Thanks Mirja
> 
> Some vendors already use x-properties (if I can use the term) to support a number of the features being standardized here (e.g. locations and rich text).
>