Re: [calsify] Working Group Last call for jscontact drafts

[Ken Murchison <[e-mail]>]

Here are my review comments, questions, and nits.

JSContact

  * Section 1, bullet 2: "attributes of the *cards* data" -> "attributes
    of the *card* data"
  * Section 1, last para: "makes *Card* easier to adopt" -> "makes
    *JSContact* easier to adopt"
  * Section 1.4.1, last para: the term "Card" is used here before its
    defined in Section 2.  Perhaps a reference here would be appropriate.
  * Section 1.4.4: /type /definition is missing a leading bullet
  * Section 1.5: "... and better be defined just once." doesn't read
    right to me.  Perhaps "... and are defined here to avoid
    repetition."  Or something similar.
  * Section 1.6: "This is to allow implementations correctly" -> "This
    is to allow implementations *to* correctly"
  * Section 1.6: " Such RFC document" -> " Such *a* RFC document"
  * Section 1.7: ", vendor-specific properties in Section 1.8.1
    <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-05.html#vendor-specific-properties>"
    -> ", *while *vendor-specific properties *are defined* in Section
    1.8.1
    <https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-05.html#vendor-specific-properties>"
  * Section 1.7.1: "that *got* registered" -> "that *has been* registered"
  * Section 2.3.5, Figure 21: the second French preference object has
    the incorrect @type
  * Section 2.5.1: Why is the context for delivery /postal/ rather than
    /delivery/ ?
  * Section 2.6.4: It might be useful in the example to include a
    /data:/ URI so that developers know how to embed data in the card
  * Section 2.8.1: The date properties in the example are /String/
    values and not either /Timestamp/ or /PartialDate/ objects
  * Section 2.8.1: It might be worth noting that if /calendarScale/ is a
    system with leap months, that a MM-DD date (with no year) might not
    have enough context to property convert between the Gregorian date
    and the calendarScale date
  * Section 4.2.6, 4.3.2: Is there an actual /Resource @type/ that needs
    to be registered, or is this here to reserve it so that it doesn't
    get used?


JSContact <-> vCard

  * Section 1.1: "defines a standard *how* to convert" -> "*process*",
    "*procedure*", or "*mechanism*"
  * Section 2.1.1: "generate a unique identifier as value" -> "generate
    a unique identifier as *a* value"
  * Section 2.1.1: "MAY *does* not convert" -> "MAY not convert"
  * Section 2.3.4: Should /DEATHDATE/ also be mention here?
  * Section 2.3.9: The first sentence is hard to read.  I prefer that
    way that Section 2.3.7 reads.
  * Section 2.3.9, bullet 2: "*has not* the LANGUAGE parameter set" ->
    "*does not have* the LANGUAGE parameter set"  Note that there are
    other instances of the same working which could be fixed in the same
    manner.
  * Section 2.6.5: This spec says that Given Name maps to /personal/,
    but JSContact calls it /given/.  This conflict needs to be resolved.
  * Section 2.10.3: "the PREF parameter *has not* a JSContact
    counterpart; however, *the implementers* MAY" -> "the PREF parameter
    *does not have* a JSContact counterpart; however, *implementations* MAY"
  * Section 2.10.4: "Implementations MAY allow *to represent
    organizational untits*" -> "Implementations MAY allow
    *representation of organizational units*"
  * Section 2.10.5: "an entry for each entity the entity described by
    the Card is associated with"  This sentence is hard to parse and
    could use some rewording
  * Section 2.11.1 - 2.11.4: "The INDEX parameter is represented as the
    index of the expertise among the declared expertises" Does this mean
    the order of the objects?  If so, I think that should be stated more
    clearly.
  * Section 3.1: "applying the *reserve* rules" -> "applying the
    *reverse* rules"
  * Section 3.1, bullet 2: "they MUST the DERIVED parameter" -> "they
    MUST *set* the DERIVED parameter"


-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC