Dan, I think not restricting to a subset of vCard fields is a good idea. But I believe it's still reasonable to require a minimum set of fields.
The current text for Section 5.5 of draft 07 reads: All contact information MUST be expressed using the structure defined by the vCard Format Specification [RFC6350]. Only the contact fields of vCard are supported: fn Full name of an individual org Name of the organization adr Address fields tel Telephone numbers email Email addresses I think that word, "Only", was a poor choice on my part. The intent was not to restrict to only these fields but to indicate that these are minimum required fields. A regulatory domain may require additional fields, but those should be documented in the IANA Considerations section under the appropriate Ruleset ID sections. It might also make sense to add statements, such as, Names of organizations MUST use the "org" field. Names of individuals MUST use the "fn" field. -vince On Mon, Dec 9, 2013 at 8:28 AM, Harasty, Daniel J <[email protected]>wrote: > PAWS WG, > > > > The team I’m on is active both with PAWS, and with the other US WS DBAs > in the “InterOp forum” to define the exchange of records between US WS DBAs. > > > > The PAWS spec and InterOp specs are just slightly out-of-sync on how vCard > objects are handled. > > · They state different subsets are “the only supported fields” > > o Example: InterOp states “N” is supported, PAWS states it is excluded. > > · They state different datatype restrictions. > > o Example: InterOp allows only “text” and “integer”, PAWS allows “uri” > types. > > · Neither states how a recipient is supposed to handle/reject a > message that has “extra” fields. > > > > But most importantly, IMO, there is no particular implementation advantage > to an “approved subset”; in fact, it tends to complicate things. In > effect, the implementation *required *to add ad-hoc validations (to > determine that certain fields are NOT present) , either custom validations > after the use of a generic vCard library / parser, or implementation of a > custom vCard parser. > > > > Furthermore, everywhere else (outside the vCard) PAWS expressly > *requires*message recipients to “ignore all parameters it does not > understand”. Why > not apply the same design concept to parsing of vCards? > > > > As such I’d like to propose to PAWS a different approach: > > · The sender must send valid vCard, and must include anything > required by its regulatory domain. (All optional fields allowed by the > vCard spec are expressly allowed in the InterOp/PAWS messages.) > > · The recipient must parse/accept any valid vCard, and may ignore > fields that are not required by the regulatory domain. > > > > This approach is MUCH simpler to state, MUCH simpler to implement, much > more consistent with current practices (allow sending optional fields), and > – if approved by both – removes the disparities between the two specs > regarding encoding of contacts. > > > > I’ve already presented the same to the US InterOp team, and believe there > is general support for this approach in the InterOp spec. > > > > If, after a discussion here, there is general agreement, I’m willing to > draft updated text for Section “5.5. DeviceOwner”… and the whole of it > will probably be shorter than this email! > > > > Dan Harasty > > > > > > > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
