Subject: Re: [scim] Add TTY or TDD to canonical types for phoneNumbers.

From: Steve Moyer <[email-masked]>
Date: Thu, 17 Oct 2013 10:37:20 -0400 (EDT)

I think a more proper definition for the "phoneNumber" field's type would be:

"A numerical address that specifies an end-point connected to the public telephony infrastructure".

Thorsten wrote:

"As the canonical value for phonenumber type is an information about
"where will reach the person" rather than "on what kind of device""

But there are actually problems with the existing set of phoneNumber types ... fax, for instance, also describes "on what kind of device".  I've thrown together the following table to highlight some of the oddities (I've tried to put implied characteristics in parenthesis):

+------------------------------+-------------+--------------------+---------+
|Canonical types (phoneNumber) | what        | where              | how     |
+------------------------------+-------------+--------------------+---------+
| fax                          | fax         | ?                  | (modem) |
| home                         | (telephone) | home               | (voice) |
| mobile                       | (telephone) | (current location) | voice   |
|                              | (telephone) | (current location) | text    |
| other                        | ?           | ?                  | ?       |
| pager                        | pager       | ?                  | (text)  |
| work                         | (telephone) | work               | (voice) |
+------------------------------+-------------+--------------------+---------+

There's a lot of ambiguity in what each "type" really means, and if varies from "where the device is", "what the device is" and "how can I reach the end-point.  If your boss has two "phoneNumber" objects with the type "fax" as part of his User attributes, and he tells you "That document has to be signed today or you're fired - send it to my home fax machine immediately", what do you do?

My "emergency alerts" use case could be considered a special case, and I have no issue creating extensions as needed (we've already done it for other attributes) or adding producer specific values for type.  I would however submit that the general use case of "notify a user" is pretty common (reviewing the use-case document is on my to-do list and I'll give more specifics then).  For those of us in the U.S., the ADA (http://www.ada.gov/) governs what steps we've got to take to adapt our services for those with disabilities.  Most of us are familiar with the section 508 rules for making website's available to the blind, but our organization has other guidelines we have to follow related to telephony.

I'll let other comment for a few days, and develop whatever extensions I need to make this work, but I think the specification should at least address the implied operation of each phoneNumber type as shown in the table above.  I'll shut up now ... what do others think?

Steve

---

From: Thorsten Roßner <[email-masked]>
Date: Fri, 18 Oct 2013 09:58:47 +0200

> "A numerical address that specifies an end-point connected to the public telephony infrastructure".
As a non native speaker this sounds to me more like a definition for the
"phoneNumber" field not for the phoneNumber's type field?

> But there are actually problems with the existing set of phoneNumber types ... fax, for instance, also describes "on what kind of device".  I've thrown together the following table to highlight som…
I agree that for the "fax" option it would be helpful to have a
differentiation between work-fax and private-fax, but I don't think we
should get into full details for all cases. That would cause us to have
work-mobile / private-mobile, work-pager / private-pager etc.
We might even have to differentiate if a mobile device is able to
receive MMS beside text messages or if your landline phone can receive
text messages as well.

IMHO the SCIM standard should stick to the 80 side of the pareto principle.

>From what I understood from your usecase just adding your custom types
should be an easy way to solve the problem?

Thorsten

> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim