Re: Comment to vCard MIME

["Frank Dawson" <fdawson@xxxxxxxxxxxxx>]

Kitayama-san:

Thank you for contributing the MOPA comments concerning the IETF ASID vCard
draft. My replies are provided inline in your comments.

- - Frank Dawson

============================================


Mobile Office Promotion Association (MOPA), which is an industry
consortium in Japan, has reviewed the Internet Draft of vCard MIME
(ietf-asid-mime-vcard-03.txt) and has the following comments.

1. We intend to use SOUND for pronunciation of names, addresses in text
format. The Draft says "Type value: The default is binary. It may also
be reset to url." The original vCard spec allows the use of SOUND for
text, and we like to confirm that this is true. Since it is not always
easy to know the pronunciation of names in Kanji, it is a Japanese
custom to have pronunciation fields for name and address in PIM
applications.

<FRD>You are correct. This is an omission that must have been introduced
into the IETF specification due to editor error. A "VALUE=TEXT" should be
added back into the specification.</FRD>

2. It is not clear what properties are mandatory. The original vCard
spec is clear on that 'N' and 'VERSION' are mandatory. The Internet
Draft for "vCard Scheme for Use in LDAPv3" says that 'Formatted Name'
which corresponds to 'FN' is mandatory. All these three specs should be
consistent.

<FRD>The "Conformance" section of Version 2.1 vCard indicates "...in order
for a vCard Writer to conform to this specification it must meet the
following additional criteria:

    - Must be able to send at least the Version, Formatted Name, Name,
      Address, Telephone, Email, and Mailer properties."

However, the earlier property sections only indicate that a "vCard Writer"
must support "FN" and "VERSION" properties and that "vCard Readers" must
support all mandatory properties and be able to parse the non-standard
properties for conformance to the specification.

Obviously, not very consistent.

I believe that change from "N" to "FN" was made in the IETF ASID
specification because this is the closest property to the LDAP and X.500
"Common Name" or "CN" property. However, you raise a reasonable comment.

I do not think that we necessarily need to perpetuate bad decisions in vCard
Version 2.1. Within the progression of the vCard in the IETF ASID WG, we
have the opportunity to rework such decisions.

Having the "N" property in every vCard is beneficial in providing at least
one property to sort the names associated with the vCard object. I agree
that the "FN" property does not afford the same level of specificity for
this function. However, having a "FN" property in every vCard permits the
recipient to display the name associated with the vCard object, as intended
by the originator.

It makes sense to me to make the "VERSION", "FN" and "N" properties
mandatory in the IETF ASID vCard draft. This will allow consistency with the
Version 2.1 vCard and also allow us to display a formatted name for the
vCard object.</FRD>

3. We do not understand why VALUE parameter is necessary.

<FRD>Early discussion within the IETF ASID WG on the MIME Directory
Content-Type (the draft that codifies the grammar used in the IETF ASID
vCard draft) indicated a preference for stronger data typing within the
vCard, and any other formats using the MIME Directory syntax. This led to
the introduction of the ";VALUE=" property parameter and specific value
typing of each property. Please note that if an instance of a property makes
use of the default value type, then this parameter need *not* be specified.
The consensus of the IETF ASID WG is that this is a "good thing".</FRD>

4. The Draft says that for AGENT type value, "It may be reset to text
or url". However, the BNF in the Draft does not support this.

<FRD>Thank you for this observation. You are correct. The grammar will be
modified in the pending revision to the vCard draft.</FRD>

5. Typo or like.

   Section 2: Predefined MIME Directory used; PROFILE appear twice.
   Section 4.1.3: Type example; PHOTO;VALUE=url:=http:....
                  What is the second '='?
   The BNF: '8bit' is missing for 'value' definition.

<FRD>Thank you. We will correct these.</FRD>

- - Frank