Subject: [Uri-review] To whom it may concern

From: "Richard Shockey" <[email-masked]>
Date: Mon, 1 Oct 2007 11:02:15 -0400

The following ID contains a template for a new URI scheme to be known as
PSTN:

The rationale and usage of this new URI are contained in the document
attached.

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166
sip:rshockey(at)iptel.org 
PSTN Office +1 571.434.5651 
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> 
<mailto:richard.shockey(at)neustar.biz>

_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: Martin Duerst <[email-masked]>
Date: Tue, 02 Oct 2007 18:19:44 +0900

Hello Richard,

A few comments to your proposal:

- There is already a tel: URI scheme for actually initiating telephone
  calls to telephone numbers. My understanding is that your URI scheme
  doesn't do the same, but is for use behind the scenes. But I'm not
  sure, and would like you to clarify the relationship to the tel:
  scheme, at least on this mailing list.

- From the examples, it looks like the only or main purpose of the
  proposed scheme is to encode information in a specific protocol.
  With such a limited field of use, does it make sense to provide
  a new scheme? Couldn't that data be transferred more easily in
  a different way.

- It seems that the use of "pstn" as a scheme name is a bit problematic;
  usually pstn stands for "public switched telephone network", which
  in my understanding is more a generic term than the name of a specific
  protocol.

- Some examples use "charset=ascii", the mime preferred name is
  us-ascii (see http://www.iana.org/assignments/character-sets).
  What is the reason to not use the mime preferred name?

- The draft text contains non-ASCII characters (in particular
  apostrophes/quotes). Internet Drafts have to be US-ASCII only.

- Your draft says that "This specification does not preclude 
  the use of internationalized characters within the pstn URI, nor
  does it preclude the use of more than 15 characters."
  How would such 'internationalized' characters be encoded?
  Why are things such as 'charset=ascii' used at all, why not
  just define that data is always UTF-8? This would bring
  this scheme in accordance with IRIs [RFC3987].

Regards,    Martin.

><mailto:richard.shockey(at)neustar.biz>

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 3 Oct 2007 22:08:17 -0400

>  -----Original Message-----
>  From: Martin Duerst [mailto:[email-masked]]
>  Sent: Tuesday, October 02, 2007 5:20 AM
>  To: Richard Shockey; [email-masked]
>  Subject: Re: [Uri-review] To whom it may concern
>  
>  Hello Richard,
>  

Our first inclination to use the TEL: URI but I ran into massive objections
from the SIP/RAI community who adamantly rejected any use of TEL for data
not directly related to routing. CNAM is not routing data it is data
associated with a telephone number namely the verbose name of the caller.

After consulting with the usual suspects in the SIP community they suggested
using the data: URI.. fine by me but then I ran into opposition from the
IESG and others who were looking to deprecate the use of data: URI in much
the same way the IESG wants to halt the use of TXT RR in the DNS for strange
and bizarre data types that don't specifically fit into a nice neat shoe
box.

After consulting privately with Larry Masinter the author of the data URI he
clearly recognized the essence of the problem that A. the whole problem is
hack B. I had created 3 hacks when I only needed two hence the new draft and
the registration of the new URI scheme. (see below) 

I cannot express enough my personal frustration trying to find a way within
the IETF process to standardize a relatively simple PSTN signaling
replacement query response mechanism. It is the opinion of the authors that
this URI MAY have additional uses in replacing TCAP queries for standard
data involving PSTN endpoints but those have not yet surfaced as yet. The
creation of this unique URI is generally related to ENUM RFC3761 queries but
does not have to be.

>From the other perspective .. there is a boat load of service providers
(specifically non incumbents) that will implement the proposed URI in this
draft nearly instantly if it can be approved. There is a HUGE market need
for this protocol.

The issue, as I discussed in the draft, is that service providers are not
willing to implement a new query response mechanism namely LDAP or IRIS to
specifically implement this requirement. They want RFC 3761 because its
already there and adding new protocol stacks to SIP soft switches is
unacceptable.

>    a new scheme? Couldn't that data be transferred more easily in

Argument above .. yes there are multiple ways to implement the requirement
for non TCAP CNAM access but that adds unacceptable overhead to existing
protocol stacks within existing SIP soft switch environments. If this
application is denied and the requirement that LDAP/IRIS or some other
protocol stack has to be used then the IETF perpetuates for an indefinite
period of time the use of TCAP.

>    in my understanding is more a generic term than the name of a

So what do you want me to call it ..??? We initially thought of PSTNDATA:
but we were thinking that might be too close to the problem of data:.   I
really don't care its only a string. If you wanted me to call it pigeoncrap:
I could get a consensus among the service providers wanting to implement
this. The economic value of this protocol is in the tens of millions of
dollars. 

>    What is the reason to not use the mime preferred name?

This can be amended. 

>    apostrophes/quotes). Internet Drafts have to be US-ASCII only.

This can be fixed..

>    this scheme in accordance with IRIs [RFC3987].

We are trying to conform first to the relevant ANSI standards while leaving
the door open to Internationalized character sets. This is fundamentally a
transitional standard. As communications services move from classic PSTN to
SIP based end to end communications eventually the need for this protocol
will diminish. But that will clearly take years. The key here is that the
IETF continue to assist in the transition from classic PSTN signaling
(SS7/C7/TCAP) to all IP based routing and data signaling mechanisms. 

>  >The rationale and usage of this new URI are contained in the document

**********************

I'm sorry I didn't reply sooner....

I wasn't complaining about your intent, or the fact that you needed a
'hack', just that you had three levels of hack and you only needed two.

I suggest that you invent a new URI scheme instead of inventing a new MIME
type. Instead of data:application/cnam,<stuff> you'd write cnamfind:<stuff>
and define cnamfind as identifying whatever endpoint you'd reach by
interpreting <stuff>.

Larry

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]]
Sent: Monday, July 16, 2007 8:07 AM
To: [email-masked]
Cc: 'Livingood, Jason'; 'Scott O. Bradner'
Subject: RE: Hello folks..

Larry I don't disagree with any of your points but I'm somewhat caught
between a rock and a hard place here. The application described here is very
very valuable to service providers that are looking to use the technology of
RFC 3761 to solve a real business problem ( kill off SS7 ) and the SIP
community that is adamant we do not use the tel URI since, in their view, it
does not involve 'routing'. The overriding requirement here is some form of
single query mechanism using 3761 that delivers a definitive response to the
query.

Yes it looks like a hack but that is exactly what is. But I'm at a loss to
think of what other URI type would fit the requirements.

The use case here is when the call originates on the PSTN and the SIP
headers do not have the verbose Caller Display name. This technique permits
the SP to access another database to retrieve the data and avoid the SS7
TCAP dip ( and related charges). There are third party data providers that
can offer verbose Caller Name without having to query the originating
carriers databases.

The "u" flag is meant to designate that the result of the query is terminal
per DDDI . You have an final answer. We are going through the process of
revising 3761 to Draft and part of that should be under what conditions
should the flag field be modified to express different forms of data types. 

I'm cc Scott Bradner here because that is one of the outstanding issues left
open by 3761 and Scott is taking over the editorship of 3761.

We are very very open to ideas here. 

-----Original Message-----
From: Larry Masinter [mailto:[email-masked]] On Behalf Of Larry Masinter
Sent: Saturday, July 14, 2007 12:59 AM
To: 'Richard Shockey'
Subject: RE: Hello folks..

Using "data::" this way and registering a MIME type for specific use within
"data:" URIs seems like an awful lot of hackage together.

Why go through the two levels of indirection? Why not just put the caller
information in the record?

And there seems to be a use/mention problem, since the URI in the a "u"
NAPTR is supposed to be the URI of the endpoint, and not the URI of the
description of the endpoint. A "data" URI doesn't identify anything other
than the data contained within it.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Richard Shockey
Sent: Tuesday, July 10, 2007 11:47 AM
To: [email-masked]
Subject: Hello folks..

I understand I need to submit this draft for approval since it defines a new
media type.

Is this the right list?

Title		: IANA Registration for an Enumservice Calling Name Delivery
(CNAM) Information and IANA Registration for Media type "application/cnam"
	Author(s)	: R. Shockey, et al.
	Filename	: draft-ietf-enum-cnam-05.txt
	Pages		: 13
	Date		: 2007-5-29
	
  This document registers the Enumservice "pstn" and subtype "cnam" 
  using the URI scheme "data:" as per the IANA registration process
  defined in the ENUM specification, RFC 3761[1] and registers a new 
  media type application/cnam [17].   
   
  This data is used to facilitate the transfer of Calling Name Delivery
  (CNAM) data for calls that originate on the Public Switched Telephone
  Network (PSTN) that may be displayed on VoIP or other Real-time
  Client User Agents (CUA).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-cnam-05.txt

Richard Shockey
Director, Member of the Technical Staff
NeuStar
46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org PSTN
Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us> <mailto:richard.shockey(at)neustar.biz>

---

From: Martin Duerst <[email-masked]>
Date: Thu, 04 Oct 2007 16:28:17 +0900

Hello Richard,

At 11:08 07/10/04, Richard Shockey wrote:
>not directly related to routing.

Given your explanations of how this stuff works, which confirm my
previous vague understanding, I would have to agree.

>CNAM is not routing data it is data
>using the data: URI.. fine by me

I guess that would have been fine by me, too. Excuse me for being dense,
but I'm not totally clear on why you need an URI in the first place.
Is your protocol (RFC3761) unable to transmit anything else than an URI?
In that case, that looks like bad protocol design, but I understand
that at least at the moment, that's different to change.

>but then I ran into opposition from the

I understand the argument for the TXT record, because there is no
official way to indicate something like a (sub)type for a TXT RR.
For data:, that situation is a bit different.

>creation of this unique URI is generally related to ENUM RFC3761 queries but

I'm not on the IESG, but it sounds to me that while two hacks is better
than three, inventing new URI schemes to represent data when there is
a data URI scheme, and when the essence of the problem is not a new
way to access information (for which typically an URI is used) but
a new kind of information (for which usually a MIME type is used)
is totally the wrong way round.

>already there and adding new protocol stacks to SIP soft switches is

So it seems to come down to the fact that RFC 3761 can only transmit
URIs, not other kinds of data, such as (what would have been most
handy in this case) some kind of attribute-value pairs. Seems like
a rather bad  kind of protocol design, but difficult to change in
the short term.

>but we were thinking that might be too close to the problem of data:.

For me, it looks like data and nothing else. I'd personally be happy
with pstndata. I'd also be happy with some clear language in the
draft/registration essentially describing that this is for restricted
use only.

I think that rather than thinking about other cute ideas to hack some
more, it would be better to address the larger problem in a more
long-term architectural fashion, while closing our eyes for this one.

>I

Well, this one has to :-(.

>We are trying to conform first to the relevant ANSI standards

Do you mean US-ASCII (defined as an ANSI standard), or do you mean
the stuff on the telephone side?

>while leaving the door open to Internationalized character sets.

I just checked with a colleague here familiar with the Japanese
phone system. He said that only numbers are used. Apparently,
providing font data on phones for Japanese characters was too
expensive. If necessary, the end systems do the conversion.
I don't know the situation for other countries. One problem
that could surface is that the phone industry e.g. in Germany
or France or somewhere uses an encoding totally different from
those registered at http://www.iana.org/assignments/character-sets.
Such things have been known for the library industry, and for the
television industry, so it wouldn't be surprising. In that case,
they would have to register a 'charset' label acording to
http://www.ietf.org/rfc/rfc2978.txt.

>This is fundamentally a
>will diminish.

So SIP has the possibility to transmit small keyword-value pairs
and such, and won't need to use this URI scheme? Great.

Anyway, I think I understand a lot more now. The whole thing
is a badly needed hack, and I don't intend to hold it up.

Regards,   Martin.

>But that will clearly take years. The key here is that the

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 4 Oct 2007 12:25:14 -0400

In line ...

>  that at least at the moment, that's different to change.

Bad design or not, its not going to change. RFC 3761 aka ENUM delivers NAPTR
records which incorporate URI's. 

>  a rather bad  kind of protocol design, but difficult to change in

Almost impossible in the short term I'd say. 3761 is now totally entrenched
in the architecture of most next generation landline and mobile network
architectures including GSM. It's the protocol of choice for number
translations. Phone number in URI out. That is what it was designed for.

>  draft/registration essentially describing that this is for restricted

I'm fine with that ... pstndata: it is. I'll add the restricted use case
language as well. This kind of language is exactly what we did in RFC 4769
which deals with other PSTN data types ( local number portability ) that
have similar restricted use.

>  Well, this one has to :-(.

Of course.

>  the stuff on the telephone side?

Telephone side. The teleco requirements.

American National Standards Institute (ANSI),Telecommunications - Calling
Name Identification Presentation, ANSI T1.641-1995

>  expensive.

Correct .. I'm aware of that. Most of Europe also use ANI [phone numbers]
display signaling ( a 300 bps modem transmission between the first and
second rings) to identify the calling party on the phone display. In North
America it is a very popular and very profitable service for phone
companies.

 If necessary, the end systems do the conversion.
>  and such, and won't need to use this URI scheme? Great.

Correct. Again this protocol requirement is ultimately transitional.
Eliminating one more TCAP query from the media gateways to the PSTN thus
simplifying the architecture of PSTN to SIP interworking.

Verbose calling name data can be incorporated in the SIP headers along with
practically anything else. The SIP calling party then has control over if
and how a verbose calling name is or should be displayed. The called party
then, of course has the option of accepting or denying the SIP session based
on whether the data exists or not. This in SIP terms is called anonymous
call rejection. 

>  is a badly needed hack, and I don't intend to hold it up.

Thanks much appreciated .. I'll incorporate these requirements and repost.