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
