Subject: [paws] proposal to update PAWS doc regarding vCard

From: "Harasty, Daniel J" <[email-masked]>
Date: Mon, 9 Dec 2013 16:28:16 +0000

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

---

From: Vincent Chen <[email-masked]>
Date: Mon, 9 Dec 2013 23:24:13 -0800

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-masked]>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.
>
>
>
> ·         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-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 10 Dec 2013 06:46:46 -0500

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-masked]<mailto:[email-masked]>>
Date: Tuesday, December 10, 2013 2:24 AM
To: "Harasty, Daniel J" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

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.

  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-masked]<mailto:[email-masked]>> 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.

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Tue, 10 Dec 2013 09:55:43 -0800

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-masked]>wrote:

> From: Vincent Chen <[email-masked]>
> To: "Harasty, Daniel J" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>> 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
>> 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?
>>
>>
>>
>> ·         The recipient must parse/accept any valid vCard, and may
>> ignore fields that are not required by the regulatory domain.
>>
>>
>>

-- 
-vince