Calendaring Extensions
charter-ietf-calext-02

[Ballot comment]
As I remarked on the -01-00:
How is "use cases where there is demand" to be evaluated?  In a certain
sense, if a single user asks for a feature, that is "demand", but I do
not think that scenario should prompt us to take on the work in question.

Do we perhaps want to say "significant" or "sufficient" demand?


Separately, does a "robust" mapping between icalendar/jscalendar or
vcard/jscontact entail the ability to round-trip between formats without
loss of fidelity?  Or is it a weaker requirement, to allow for some variation
when appropriate for the data models of the pair of protocols in question?

[Ballot comment]
"generate documents describing existing vendor extensions which are in common usage, and
likely to be encountered in the wild."

Is there a reason this wouldn't be done in the ISE? I assume that in these cases the IETF wouldn't have change control!

[Ballot comment]
As Éric notes, the markdown formatter seems to have mangled some (but
not all?) of the lists.

How is "use cases where there is demand" to be evaluated?  In a certain
sense, if a single user asks for a feature, that is "demand", but I do
not think that scenario should prompt us to take on the work in question.

[Ballot block]
  - publish informative documents describing existing vendor extensions
    which did not come through the IETF consensus process, but are
    nonetheless in common usage and likely to be encountered in the wild.

I understand the intent, but all IETF documents require consensus (rfc8789). Publishing a vendor extension without consensus should be done through the ISE.

[Ballot block]
  - publish informative documents describing existing vendor extensions which
    did not come through the IETF consensus process, but are nonetheless in
    common usage and likely to be encountered in the wild.

I understand the intent, but all IETF documents require consensus (rfc8789). Publishing a vendor extension without consensus should be done through the ISE.

[Ballot comment]
Please help me understand how JSContact fits into this charter.  It confuses me because it is a draft that belongs to a different WG, which also contradicts the statement that "work which is in scope for any other ART area working group" is out of scope.  It may be premature to list draft-ietf-jmap-jscontact as part of the base documents.

[Ballot comment]
No objection, but...

> out of scope for the working group:
>
> - Any change that significantly impacts backwards compatibility with
> existing deployed iCalendar/iTIP/CalDAV clients and servers.

I wonder whether what you consider as significant is the same as what I would call significant.

[Ballot comment]
This all looks fine. One question for my benefit.

"- Define a set of new iCalendar properties and parameters to standardise
some existing experimental X- properties in common use, based on a
survey of existing implementations."

I wasn't quite sure whether this meant standardizing an "X-Foo" experimental property, or standardizing a renamed "Foo:". It's unlikely that needs to be stated in a charter, either way, but just in case it does ... if the deliverable was "standardise some existing experimental properties", I wouldn't have thought to ask, but given the existence of http://tools.ietf.org/html/rfc6648, I wondered.

[Ballot comment]
This text seems a little vague:

"Define a set of new iCalendar properties and parameters to standardise
some existing experimental X- properties. This will include a new set of
"top-level" properties for the "CALENDAR" component, as well as an new
"IMAGE" property to allow users more control of the visual appearance of
events and tasks within their calendars."

Are there specific X- properties the group intends to standardize besides the IMAGE property (assuming "IMAGE" is an example of such a property, which I'm not sure about)? The use of "some" in the first sentence makes it sound like there is some expected subset of existing properties that will be in scope, but they're not listed.