Peter, Thanks for the reminder. How about something like this?
All contact information MUST be expressed using the structure defined by the vCard Format Specification [RFC6350]. At minimum, the information MUST include: - At least one of the following: fn: Full name of an individual org: Name of the organization - Each of the following: adr: Address fields tel: Telephone numbers email: Email addresses Names of organizations MUST use the "org" field and names of individuals MUST use the "fn" field. On Tue, Dec 10, 2013 at 3:46 AM, Peter Stanforth <[email protected]>wrote: > Do we know that name and organization are both required? > Is it not more reasonable to think one or the other is required? > Peter S. > > From: Vincent Chen <[email protected]> > Date: Tuesday, December 10, 2013 2:24 AM > To: "Harasty, Daniel J" <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [paws] proposal to update PAWS doc regarding vCard > > 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 PAWSa 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 > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
