Subject: Re: [dispatch] [Modern] draft charter

From: Richard Shockey <[email-masked]>
Date: Wed, 25 Feb 2015 13:54:14 -0500

Humm.. Thanks.

I¹m not sure anyone has actually deployed a 50 character service. Does
anyone know?  

On 2/25/15, 12:31 PM, "DRAGE, Keith (Keith)"
<[email-masked]> wrote:

>ITU-T Recommendation I.251.9 specifies:
>
>calling name: Information associated with a specific calling party
>number. The maximum length is at least 15 characters and may be up to 50
>characters. The exact length, format and character set (e.g. T.51, T.52)
>of the calling name to be delivered is a service provider option
>
>Therefore 15 would appear to be a deployment specific limitation.
>
>I believe QSIG defines 50 characters.
>
>The definition above also raises the question of character set.
>
>QSIG defines a number of different character sets.
>
>
>
>Regards
>
>Keith 
>
>> -----Original Message-----
>> From: dispatch [mailto:[email-masked]] On Behalf
>> Of Richard Shockey
>> Sent: 25 February 2015 17:05
>> To: DOLLY, MARTIN C
>> Cc: Holmes, David W [CTO]; [email-masked]; [email-masked];
>> [email-masked]
>> Subject: Re: [dispatch] [Modern] draft charter
>> 
>> 
>> Thanks Martin .. This is my very raw first cut at a charter.
>> Its hopefully simple and straight forward.
>> 
>> Send me any edits etc.
>> 
>> *****
>> 
>> CNIT Charter [Calling Name Identity Trust]
>> 
>> 
>> WG Chairs TBD:
>> 
>> 
>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII
>> Characters of information associated with a specific E.164
>> calling party number in the Public Switched Telephone Network
>> [PSTN].  In the PSTN this data is sent by the originating
>> network only at the specific request of the terminating
>> network via a SS7 Transaction Application Part [TCAP]
>> response message.  In the Session Initiation Protocol [SIP]
>> this information can be inserted into the FROM: part of the
>> originating INVITE message or by other means.
>> 
>> 
>> As with the originating source telephone number, this data
>> can be altered in transit creating a variety of malicious
>> abuses similar to the ones identified by the IETF STIR working group.
>> 
>> 
>> The purpose of the CNIT working group will be to define a
>> data structure, a new SIP header or repurpose an existing SIP
>> header to carry an advanced form of CNAM as well as
>> information from a STIR Validation Authority.  The purpose of
>> this work is to present to the SIP called party trusted
>> information from the calling party in order that the called
>> party make a more reasoned and informed judgment on whether
>> to accept the INVITE or not.
>> 
>> 
>> The working group will not invalidate any existing SIP
>> mechanism for anonymous calling.
>> 
>> 
>> The working group will, to the best of its ability, reuse
>> existing IETF protocols.
>> 
>> 
>> Full Internationalization of the Calling Name Identity Trust
>> data object(s) is a requirement.
>> 
>> 
>> The working group will closely work with the IETF STIR working group
>> 
>> 
>> The working group will immediately liaison with 3GPP SA-1 in
>> order to coordinate efforts.
>> 
>> 
>> The working group will coordinate with National Numbering
>> Authorities and National Regulatory Authorities as needed.
>> 
>> 
>> The working group will deliver the flowing.
>> 
>> 
>> * A problem statement and requirements detailing the current
>> deployment environment and situations that motivate work on
>> Calling Name Identity Trust.
>> * Define either a new SIP header or document a repurpose of
>> an SIP existing header for Calling Name Identify Trust data *
>> Define a data model for the Calling Name Identity Trust
>> object (s) which may include various forms of multimedia data
>> * Deliver an analysis of privacy implications of the proposed
>> Calling Name Identity Trust mechanism.
>> 
>> 
>> 
>> 
>> Milestones:
>> 
>> 
>> -
>> Richard Shockey
>> Shockey Consulting LLC
>> Chairman of the Board SIP Forum
>> www.shockey.us
>> www.sipforum.org
>> richard<at>shockey.us
>> Skype-Linkedin-Facebook rshockey101
>> PSTN +1 703-593-2683
>> 
>> 
>> From: "DOLLY, MARTIN C" <[email-masked]>
>> Date: Tuesday, February 24, 2015 at 9:02 PM
>> To: Richard Shockey <[email-masked]>
>> Cc: "Holmes, David W [CTO]" <[email-masked]>,
>> "[email-masked]" <[email-masked]>, "[email-masked]"
>> <[email-masked]>, "Peterson, Jon" <[email-masked]>
>> Subject: Re: [Modern] [dispatch] draft charter
>> 
>> 
>> I support Richard on this
>> 
>> Martin Dolly 
>> Lead Member of Technical Staff
>> Core & Gov't/Regulatory Standards
>> AT&T Standards and
>> Industry Alliances
>> +1-609-903-3390
>> 
>> Sent from my iPhone
>> 
>> On Feb 24, 2015, at 6:36 PM, Richard Shockey
>> <[email-masked]> wrote:
>> 
>> 
>> 
>> 
>> 	Excellent points David.
>> 
>> 	My concern here is charter overreach. I really want to
>> keep CNAM+/CNIT out of this.  IMHO that is a very separate
>> and highly focused effort to define both the modification of
>> the SIP headers necessary to support some enhanced calling
>> party identification and a very limited effort to define the
>> object and or the STIR validation data.
>> 
>> 	I'm violently opposed to "end world hunger" WG's.
>> 
>> 	If registries can be used fine but I certainly want to
>> see how this can be accomplished in bi lateral agreements
>> between consenting service providers and work with CUA
>> vendors on how the data is displayed aka Apple, Samsung,
>> Microsoft in the context of a formal liaison with 3GPP.
>> Certainly the relevance of CNAM+/CNIT in enterprise and
>> residential access markets is important but we all know
>> "Money is the answer what is the  question .."
>> 
>> 	I've asked for time in Dispatch to look at the
>> CNAM/CNIT issue and report on the JTF on NNI. As you well
>> know we have made considerable progress.
>> 
>> 	Last week I gave a talk on this to a panel that
>> included many of our friends among the national regulators.
>> 
>> 	http://apps.fcc.gov/ecfs/document/view?id=60001033217
>> 
>> 
>> 
>> 	
>> 	From: "Holmes, David W [CTO]" <[email-masked]>
>> 	Date: Tuesday, February 24, 2015 at 5:06 PM
>> 	To: "Peterson, Jon" <[email-masked]>,
>> "[email-masked]" <[email-masked]>
>> 	Subject: Re: [Modern] draft charter
>> 	
>> 
>> 
>> 	Jon, 
>> 
>> 	 
>> 
>> 	Thank you for the work in assembling this draft of the
>> charter for MODERN.
>> 
>> 	 
>> 
>> 	We would like to suggest some minor clarifications to
>> the bullets describing the deliverables, to align them with
>> the statement regarding flexibility to support the needs of
>> different regulatory regimes, & thus to ensure that if quoted
>> alone they are not taken out of context; i.e. the group
>> product will be the protocols to support the allocation etc.
>> activities, & it would not attempt to define the allocation
>> processes.  We also would like the charter to note the
>> relevant work that has already been performed by both IETF &
>> the ATIS/SIP Forum JTF, & incorporate that into the output
>> from the MODERN WG as appropriate.  These changes/additions
>> are have been added to your text inline below.
>> 
>> 	 
>> 
>> 	We are hoping that the MODERN session at IETF#92 will
>> have remote access, to allow participation by those of us
>> that cannot attend in person due to other commitments that week.
>> 
>> 	 
>> 
>> 	Regards, 
>> 
>> 	 
>> 
>> 	David/Sprint 
>> 
>> 	
>> ______________________________________________________________
>> ________________
>> 
>> 	 
>> 
>> 	From: Modern [mailto:[email-masked]] On Behalf
>> Of Peterson, Jon
>> 	Sent: Wednesday, February 11, 2015 9:19 AM
>> 	To: [email-masked]
>> 	Subject: [Modern] draft charter
>> 
>> 	 
>> 
>> 	 
>> 
>> 	At the Dallas IETF meeting in March, we'd like to get
>> together and talk about what a working group for MODERN might
>> look like. As an initial input to the discussion, a few of us
>> have put together a proposed charter. While the TeRQ work was
>> positively evaluated in the DISPATCH process, we feel this is
>> broader enough in scope to warrant its own BoF.
>> 
>> 	 
>> 
>> 	Comments are welcome, this is just a starting point.
>> 
>> 	 
>> 
>> 	------
>> 
>> 	 
>> 
>> 	Modern charter text:
>> 
>> 	 
>> 
>> 	The MODERN working group will define a set of
>> Internet-based mechanisms for the purposes of managing and
>> resolving telephone numbers (TNs) in an IP environment.
>> Existing mechanisms for these purposes face obsolescence as
>> the voice communications infrastructure evolves to IP
>> technology and new applications for TNs become possible.  The
>> traditional model of a TN having an association to a single
>> service provider and a single application is breaking down.
>> Its use as a network locator is going away, but its use as an
>> identifier for an individual or an organization will remain
>> for some time. Devices, applications, and network tools
>> increasingly need to manage TNs, including requesting and
>> acquiring TN delegations from authorities.
>> 
>> 	 
>> 
>> 	The working group will define a framework for the roles
>> and functions involved in managing and resolving TNs in an IP
>> environment. This includes a protocol mechanism for acquiring
>> TNs, which will provide an enrollment process for the
>> individuals and entities that use and manage TNs. TNs may
>> either be managed in a hierarchical tree, or in a distributed
>> peer-to-peer architecture.  Privacy of the enrollment data
>> and security of the resource will be primary considerations.
>> 
>> 	 
>> 
>> 	Additionally, the working group will deliver a protocol
>> mechanism for resolving TNs which will allow entities such as
>> service providers, devices, and applications to access data
>> related to TNs, possibly including caller name data (CNAM).
>> Maintaining reliability, real time application performance,
>> security and privacy are primary considerations.  The working
>> group will take into consideration existing IETF work
>> including ENUM, SPEERMINT, STIR, and DRINKS.
>> 
>> 	 
>> 
>> 	The work of this group is limited to specifying a
>> solution for TNs and covers any service that can be addressed
>> using a TN.  Expanding the work to other identifiers is out
>> of scope.  Solutions and mechanisms created by the working
>> group will be flexible enough to accommodate different
>> policies, e.g., by different regulatory agencies.
>> 
>> 	 
>> 
>> 	The work group will deliver the following:
>> 
>> 	 
>> 
>> 	-          An architecture overview document that
>> includes high level requirements and security/privacy
>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum
>> JTF, that included:
>> 
>> 	o   Call routing architecture
>> 
>> 	o   Inter-carrier NNI
>> 
>> 	o   Cryptographically-enabled Anti-spoofing (STIR)
>> 
>> 	o   Enhanced Calling Name (CNIT/CNAM)
>> 
>> 	-          A document describing the protocols to
>> support enrollment processes for existing and new TNs
>> including any modifications to metadata related to those TNs
>> 
>> 	-          A document describing protocol mechanisms
>> for accessing contact information associated with enrollments
>> 
>> 	-          A document describing protocol mechanisms
>> for resolving information related to TNs
>> 
>> 	 
>> 
>> 	-           
>> 
>> 
>> ________________________________
>> 
>> 	
>> 	This e-mail may contain Sprint proprietary information
>> intended for the sole use of the recipient(s). Any use by
>> others is prohibited. If you are not the intended recipient,
>> please contact the sender and delete all copies of the message.
>> 	
>> 	_______________________________________________ Modern
>> mailing list [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/modern
>> 
>> 	_______________________________________________
>> 	dispatch mailing list
>> 	[email-masked]
>> 	https://www.ietf.org/mailman/listinfo/dispatch
>> 	
>> 
>> _______________________________________________ Modern
>> mailing list [email-masked]
>> https://www.ietf.org/mailman/listinfo/modern
>> 
>_______________________________________________
>Modern mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/modern

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Feb 2015 19:40:41 +0000

I wonder if we're just talking about an unstructured string, or rather something more structured, e.g., to be able to distinguish the name of the caller from the organization, such as

name=Hala Mowafy / ou=Ericsson

________________________________________
From: cnit [[email-masked]] on behalf of Hala Mowafy [[email-masked]]
Sent: Wednesday, February 25, 2015 2:17 PM
To: Richard Shockey
Cc: Holmes, David W [CTO]; [email-masked]; [email-masked]; DRAGE, Keith (Keith); [email-masked]; DOLLY, MARTIN C
Subject: Re: [cnit] [Modern] [dispatch]    draft charter

Not to my knowledge in North America.
Keith, I believe you are referencing an ISDN PBX standard so it may have been just within a business group - not inter-network?? Correct me if I'm wrong.

In our discussions at ATIS last year for CNAM in SIP headers someone brought up limitations on network elements handling more than 35 characters and that is what we are planning to support with an objective of 60 ch in the future.
I think 35 is more than enough even for some of the longest, hyphenated names.

Hala Mowafy
ERICSSON

> On Feb 25, 2015, at 1:55 PM, Richard Shockey <[email-masked]> wrote:
>
>
> Humm.. Thanks.
>

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

---

From: Hala Mowafy <[email-masked]>
Date: Wed, 25 Feb 2015 19:17:24 +0000

Hala Mowafy
ERICSSON

---

From: Richard Shockey <[email-masked]>
Date: Wed, 25 Feb 2015 14:57:57 -0500

Structured.  IMHO the easiest path to success would be repurpose the
CALL-INFO header with a RFC 7095 (json vcard) object. The terminating CSCF
would also insert the STIR validation data (what ever that was)  CUA’s
could then have customized settings like we have ring tones ‘WARNING
WARNING WILL ROBINSON’ ‘DIVE DIVE DIVE’  Klaxon, Sirens etc.

We might be able to get this ready before iOS 12.

On 2/25/15, 2:40 PM, "Henning Schulzrinne" <[email-masked]>
wrote:

>I wonder if we're just talking about an unstructured string, or rather
>something more structured, e.g., to be able to distinguish the name of
>the caller from the organization, such as
>
>Cc: Holmes, David W [CTO]; [email-masked]; [email-masked]; DRAGE, Keith
>(Keith); [email-masked]; DOLLY, MARTIN C
>Keith, I believe you are referencing an ISDN PBX standard so it may have
>been just within a business group - not inter-network?? Correct me if I'm
>wrong.
>
>In our discussions at ATIS last year for CNAM in SIP headers someone
>brought up limitations on network elements handling more than 35
>characters and that is what we are planning to support with an objective
>of 60 ch in the future.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 25 Feb 2015 22:27:55 +0000

There were two ISDN standards directions for calling name. 

1)	The public network standards. The service definition is the ITU-T Recommendation I.251.9 reference. As far as I aware, ITU-T did not proceed to produce the related protocol standards (DSS1 and ISUP) but I could be wrong on this.

2)	The private (or business network standards) defined in ECMA international, ETSI and ISO (the same document in all groups). These did result in a protocol definition for QSIG.

Both sets of documents quote 50 octets maximum length, and both specify that different character sets are possible. And both are defined for internetwork operation as well as internal operation.

I would suggest that if you think some other value is appropriate, then that alternative figure is the one that should be justified, given that the entire charter is ISDN centric!

In regards to assessing length of names in general use, please give source references for what you think is reasonable. I am aware that this will vary from country to country, and deployment to deployment, based on style of naming, language, formal or informal address, title or professional qualifications and so on. I would prefer not to work beginning from statements that start "I think..."

http://www.historyrundown.com/top-5-people-with-the-longest-names/

Regards

Keith

Regards

Keith

> From: Hala Mowafy [mailto:[email-masked]] 
> Sent: 25 February 2015 19:17
> To: Richard Shockey
> Cc: DRAGE, Keith (Keith); DOLLY, MARTIN C; Holmes, David W 
> [CTO]; [email-masked]; [email-masked]; [email-masked]
> Keith, I believe you are referencing an ISDN PBX standard so 
> it may have been just within a business group - not 
> inter-network?? Correct me if I'm wrong. 
> 
> In our discussions at ATIS last year for CNAM in SIP headers 
> someone brought up limitations on network elements handling 
> more than 35 characters and that is what we are planning to 
> support with an objective of 60 ch in the future. 
> >> number. The maximum length is at least 15 characters and 
> may be up to 
> >> 50 characters. The exact length, format and character set 
> (e.g. T.51, 
> >> T.52) of the calling name to be delivered is a service provider 
> >> option
> >> 
> >>> From: dispatch [mailto:[email-masked]] On Behalf Of 
> >>> Richard Shockey
> >>> Characters of information associated with a specific 
> E.164 calling 
> >>> party number in the Public Switched Telephone Network [PSTN].  In 
> >>> the PSTN this data is sent by the originating network only at the 
> >>> specific request of the terminating network via a SS7 Transaction 
> >>> Application Part [TCAP] response message.  In the Session 
> Initiation 
> >>> Protocol [SIP] this information can be inserted into the 
> FROM: part 
> >>> of the originating INVITE message or by other means.
> >>> 
> >>> 
> >>> As with the originating source telephone number, this data can be 
> >>> altered in transit creating a variety of malicious abuses 
> similar to 
> >>> the ones identified by the IETF STIR working group.
> >>> 
> >>> 
> >>> The purpose of the CNIT working group will be to define a data 
> >>> structure, a new SIP header or repurpose an existing SIP 
> header to 
> >>> carry an advanced form of CNAM as well as information from a STIR 
> >>> Validation Authority.  The purpose of this work is to 
> present to the 
> >>> SIP called party trusted information from the calling 
> party in order 
> >>> that the called party make a more reasoned and informed 
> judgment on 
> >>> whether to accept the INVITE or not.
> >>> 
> >>> 
> existing 
> >>> IETF protocols.
> >>> Full Internationalization of the Calling Name Identity Trust data 
> >>> object(s) is a requirement.
> >>> 
> >>> 
> >>> The working group will immediately liaison with 3GPP SA-1 
> in order 
> >>> to coordinate efforts.
> >>> 
> >>> 
> >>> deployment environment and situations that motivate work 
> on Calling 
> >>> Name Identity Trust.
> >>> * Define either a new SIP header or document a repurpose 
> of an SIP 
> >>> existing header for Calling Name Identify Trust data * 
> Define a data 
> >>> model for the Calling Name Identity Trust object (s) which may 
> >>> include various forms of multimedia data
> >>> On Feb 24, 2015, at 6:36 PM, Richard Shockey <[email-masked]> 
> >>> wrote:
> >>> 
> >>> 
> >>> 
> >>> 
> >>>    Excellent points David.
> >>> 
> >>>    My concern here is charter overreach. I really want to keep 
> >>> CNAM+/CNIT out of this.  IMHO that is a very separate and highly 
> >>> focused effort to define both the modification of the SIP headers 
> >>> necessary to support some enhanced calling party 
> identification and 
> >>> a very limited effort to define the object and or the STIR 
> >>> validation data.
> >>> 
> >>>    If registries can be used fine but I certainly want to see how 
> >>> this can be accomplished in bi lateral agreements between 
> consenting 
> >>> service providers and work with CUA vendors on how the data is 
> >>> displayed aka Apple, Samsung, Microsoft in the context of 
> a formal 
> >>> liaison with 3GPP.
> residential 
> >>> access markets is important but we all know "Money is the answer 
> >>> what is the  question .."
> >>> 
> >>>    I've asked for time in Dispatch to look at the CNAM/CNIT issue 
> >>> and report on the JTF on NNI. As you well know we have made 
> >>> considerable progress.
> >>> 
> included many of 
> >>> our friends among the national regulators.
> >>> 
> >>>    Thank you for the work in assembling this draft of the charter 
> >>> for MODERN.
> >>> 
> >>>     
> >>> 
> the bullets 
> >>> describing the deliverables, to align them with the statement 
> >>> regarding flexibility to support the needs of different 
> regulatory 
> >>> regimes, & thus to ensure that if quoted alone they are not taken 
> >>> out of context; i.e. the group product will be the protocols to 
> >>> support the allocation etc.
> relevant work 
> >>> that has already been performed by both IETF & the ATIS/SIP Forum 
> >>> JTF, & incorporate that into the output from the MODERN WG as 
> >>> appropriate.  These changes/additions are have been added to your 
> >>> text inline below.
> >>> 
> >>>     
> >>> 
> have remote 
> >>> access, to allow participation by those of us that cannot 
> attend in 
> >>> person due to other commitments that week.
> >>> 
> >>>     
> >>> 
> >>>    Regards,
> >>> 
> >>>     
> >>> 
> >>>    David/Sprint
> >>> 
> >>>    
> >>>    From: Modern [mailto:[email-masked]] On Behalf Of 
> >>> Peterson, Jon
> >>>    At the Dallas IETF meeting in March, we'd like to get together 
> >>> and talk about what a working group for MODERN might look 
> like. As 
> >>> an initial input to the discussion, a few of us have put 
> together a 
> >>> proposed charter. While the TeRQ work was positively evaluated in 
> >>> the DISPATCH process, we feel this is broader enough in scope to 
> >>> warrant its own BoF.
> >>> 
> >>>     
> >>> 
> >>>    The MODERN working group will define a set of Internet-based 
> >>> mechanisms for the purposes of managing and resolving telephone 
> >>> numbers (TNs) in an IP environment.
> >>> Existing mechanisms for these purposes face obsolescence as the 
> >>> voice communications infrastructure evolves to IP 
> technology and new 
> >>> applications for TNs become possible.  The traditional 
> model of a TN 
> >>> having an association to a single service provider and a single 
> >>> application is breaking down.
> >>> identifier for an individual or an organization will 
> remain for some 
> >>> time. Devices, applications, and network tools 
> increasingly need to 
> >>> manage TNs, including requesting and acquiring TN 
> delegations from 
> >>> authorities.
> >>> 
> >>>     
> >>> 
> >>>    The working group will define a framework for the roles and 
> >>> functions involved in managing and resolving TNs in an IP 
> >>> environment. This includes a protocol mechanism for 
> acquiring TNs, 
> >>> which will provide an enrollment process for the individuals and 
> >>> entities that use and manage TNs. TNs may either be managed in a 
> >>> hierarchical tree, or in a distributed peer-to-peer 
> architecture.  
> >>> Privacy of the enrollment data and security of the 
> resource will be 
> >>> primary considerations.
> >>> 
> >>>     
> >>> 
> >>>    Additionally, the working group will deliver a 
> protocol mechanism 
> >>> for resolving TNs which will allow entities such as service 
> >>> providers, devices, and applications to access data 
> related to TNs, 
> >>> possibly including caller name data (CNAM).
> >>> Maintaining reliability, real time application 
> performance, security 
> >>> and privacy are primary considerations.  The working 
> group will take 
> >>> into consideration existing IETF work including ENUM, SPEERMINT, 
> >>> STIR, and DRINKS.
> >>> 
> >>>     
> >>> 
> >>>    The work of this group is limited to specifying a solution for 
> >>> TNs and covers any service that can be addressed using a TN.  
> >>> Expanding the work to other identifiers is out of scope.  
> Solutions 
> >>> and mechanisms created by the working group will be 
> flexible enough 
> >>> to accommodate different policies, e.g., by different regulatory 
> >>> agencies.
> >>> 
> >>>     
> >>> 
> >>> considerationsbuilt on the work of IETF & the ATIS/SIP Forum JTF, 
> >>> that included:
> >>> 
> including any 
> >>> modifications to metadata related to those TNs
> >>> 
> intended 
> >>> for the sole use of the recipient(s). Any use by others is 
> >>> prohibited. If you are not the intended recipient, please contact 
> >>> the sender and delete all copies of the message.
> >>>    
> >>>    _______________________________________________ Modern mailing 
> >>> list [email-masked] <mailto:[email-masked]> 
> mailing list 
> >>> [email-masked] https://www.ietf.org/mailman/listinfo/modern

---

From: Jonathan Cronin <[email-masked]>
Date: Thu, 26 Feb 2015 13:03:36 -0500

> On Feb 25, 2015, at 5:27 PM, DRAGE, Keith (Keith) <[email-masked]> wrote:

> In regards to assessing length of names in general use, please give source references for what you think is reasonable. I am aware that this will vary from country to country, and deployment to deployment, based on style of naming, language, formal or informal address, title or professional qualifications and so on. I would prefer not to work beginning from statements that start "I think…”

We’ve been compressing caller names down to 15 octets for caller-name for a quarter-century or so.  We store a long name of 40 octets used to create the short name. I believe that at some point in the past that was the length limit on listed name for Bell System standard service orders. Just a reference point.

There are cases other than single personal names that will benefit from longer caller name:

1) Businesses, particularly professional firms (e.g Smith, Jones and McGarrity) 
2) Couples (e.g Donald & Millicent Scanlin) 
3) Couples with different surnames:  (John Doe and Mary Roe)

(I know this from complaints. :))

(from different mail from Keith Drage)
> QSIG defines a number of different character sets.

I would use UTF-8 and be done with it.

Other thoughts:

I’m not familiar (yet :)) with the ITU recommendation but what with the wide variety terminating equipment intelligence, I don’t think one size fits all anymore.  I think a network caller-name/caller-id database should store rich data (like the JSON vcards, I think Richard Shockey suggested?)
The terminating equipment (or intermediate system) can query for as much data as it can use, or just say “I can display n chars, send me that”.
 
Jonathan

Jonathan Cronin
[email-masked]
781 861 0670

EGH, Inc.
55 Waltham Street
Lexington, MA 02421

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 26 Feb 2015 19:35:33 +0000

Hi Keith, folks,
of historical interest only perhaps, but in the UK almost all fixed line TEs were connected via analogue termination service.
Thus, for the non-ISDN expected capabilities of TEs using this stuff ...
BT's specs for Caller Display Service (their brand of CLID service) are at Annex A (page 27 et seq) of:
<http://www.sinet.bt.com/sinet/SINs/pdf/242v2p4.pdf>
 and in detail within:
<http://www.sinet.bt.com/sinet/SINs/pdf/227v3p6.pdf>

Tech. specs of the analogue line itself are spelt out in <http://www.sinet.bt.com/sinet/SINs/pdf/351v4p6.pdf>

In SIN242 a maximum message size of 64 octets is specified for Caller ID messages.
The underlying datalink from SIN227 allows an absolute maximum of 255 octets per (basic mode) message.

Thus, whilst decidedly -not- NNI, nor ISDN (and not QSIG/DPNSS...) UNI, there's the spec and length limits for CDS in the UK.
[The equivalent Telcordia CLASS docs spell out the service used "over there" and no doubt set their own limits]

We now return you to your previous channel.

all the best,
 Lawrence

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 26 Feb 2015 19:47:58 +0000

Hi Jonathon, folks,
  The "standard example" used over here to argue against 15 character name field limits was the "Girl Guides Association".
Oldie but goodie.
The original suggestion for such a severe limit was, IIRC, driven by fitting the name into the same space as a number field.
That always was a wonky choice/over-simplification, and since time t is no longer at all relevant, IMHO.
atb,  Lawrence