JSON data formats for vCard and iCalendar
charter-ietf-jcardcal-01

[Ballot block]
Note: I discussed this with Pete already, and we're apparently in agreement on the principles. The new text below has not been discussed yet.

Assuming the standard iCalendar and vCard field semantics are in [RFC5545] and [RFC6350], respectively, and that we don't want to change that, we need to improve this paragraph:

    Requirements from other working groups looking to adopt the jCard or
    jCal data formats will be considered. Requirements that are not
    explicitly mentioned in this charter will be considered so long as they
    do not conflict with the other stated objectives. Specific requirements
    for consideration are:

Indeed, we can't have new requirements on the semantic, but only requirements regarding the syntax. Like in network management [RFC3444], there is an information model and data models: we can optimize the data model, i.e., the encoding, but not the information model. The potential concern is the divergence of semantic between the different encodings. Not good.

NEW:

    Syntax-related requirements from other working groups looking to adopt
    the jCard or jCal data formats will be considered. New semantic-related
    requirements are out of scope. Requirements that are not
    explicitly mentioned in this charter will be considered so long as they
    do not conflict with the other stated objectives. Specific requirements
    for consideration are:

[Ballot block]
Note: I discussed this with Pete already, and we're apparently in agreement on the principles. The new text below has not been discussed yet.

Assuming the standard iCalendar and vCard field semantics are in [RFC5545] and [RFC6350], respectively, and that we don't want to change that, we need to improve this paragraph:

    Requirements from other working groups looking to adopt the jCard or
    jCal data formats will be considered. Requirements that are not
    explicitly mentioned in this charter will be considered so long as they
    do not conflict with the other stated objectives. Specific requirements
    for consideration are:

Indeed, we can't have new requirements on the semantic, but only requirements regarding the syntax. Like in network management [RFC3444], there is an information model and data models: we can optimize the data model, i.e., the encoding, but not the information model. The potential concern is the divergence of semantic between the different encodings. Not good.

NEW:

    Syntax-related requirements from other working groups looking to adopt
    the jCard or jCal data formats will be considered. New semantic-related
    requirements are out of scope. Requirements that are not
    explicitly mentioned in this charter will be considered so long as they
    do not conflict with the other stated objectives. Specific requirements
    for consideration are:


Btw, isn't it?
OLD:

will be considered so long as

NEW:

will be considered as long as

[Ballot comment]
Nit

The jcardcal working group is chartered to develop JSON-based data
formats that are accurate, straightforward representations of iCalendar
and vCard data, allowing for conversion between any of the various
equivalent data formats without any loss of semantic meaning, and
maximal interoperability.

The formats are not accurate representations of data, but they may
"allow" it.

---

Nit

Specific requirements
for consideration are:

* a need for conveying unstructured address information (weirds WG).

That looks like exactly one requirement :-)

---

Minor issue

Mar 2013 - Determine requirements of other Working Groups.

This seems ambitious! Further more, it is probably an ongoing
activity. How about adding "initial"?

But also, how will this milestone be met? Will there be an I-D?