Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

From: Michael Hammer <[email-masked]>
Date: Mon, 1 Jul 2013 14:27:51 +0000

Although you are disagreeing with me, your statements actually support my
points.
Note, however, that the value of an E.164 number is not just syntactical, 
you need all the digits to be semantically unambiguous.

While current systems have learned through trial and error, I still think
that 
explicitly specified mechanisms would help to ensure interoperability
sooner.

Where signatures are concerned, having ambiguous inputs will lead to high
probability of validation failure.
That was where I felt things were getting off track.

Mike

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Saturday, June 29, 2013 11:16 AM
To: Michael Hammer
Cc: [email-masked]
Subject: Re: [stir] URI formats (was RE: Do we agree on the basics?)

On Jun 28, 2013, at 12:21 PM, Michael Hammer <[email-masked]>
wrote:

> To prove that A exists is not a proof that B cannot exist.

Let's assume there is a B.  Let's say that there exists an Edsel car company
somewhere receiving these complaint forms with completely wrong numbers.
They can't make heads or tails of them.  How has Edsel been using these
contact numbers for anything meaningful today, if they're nonsensical
numbers?  I.e., in what way is Edsel using the contact number such that we
can or need to provide a verification mechanism for them?  The problem that
Edsel is having is different than our problem - we're not being asked to fix
received caller-id's being unintelligible; we're being asked to provide a
way for Dodge to know the E.164 contact number they got in the complaint
form is really the contact number of the human who sent it.

> Second, your analogy relies on the partial discipline of the PSTN, 
> that you also later note can be intentionally broken.
> What you don't yet recognize is that one can also unintentionally 
> break things, unless some discipline removes the possibility 
> (application of Murphy's Law).

The assumption I'm making for the "discipline of the PSTN" is that the
terminating domain can figure out what the source/dest E.164 phone numbers
are for requests they  get, regardless of where they got them from.  If they
don't, then STIR won't work for them, but that's not a problem for STIR to
fix.  There are RFCs that tell them how to syntactically format their URIs,
and they can choose to use those to solve that problem.  But we don't need
those syntactic forms to be used end-to-end to get STIR to work.

> Third, you assume that all senders and receivers know all others a 
> priori and that all know each other's conventions.
> You have not yet proven that is a reasonable assumption.
> While 100 years of history have allowed the accumulation of such 
> knowledge in the PSTN, that doesn't transfer to the Internet.

OK, let's ignore the way all SIP domain interconnect today.  Let's assume
they behaved more like email, where essentially any domain can send SIP
requests to any other domain, without foreknowledge of conventions.  For
that model to work at all, all domains must agree on some common convention,
or there has to be some protocol means for them to negotiate/learn one to
use.  For example they could use TEL URLs for E.164 numbers.  STIR will
function fine in that environment.  STIR will not function fine if they
don't pick a common convention - but that's not a fault of STIR nor a
problem STIR is being formed to address/fix - that would be a problem even
if no one used STIR to begin with.

> So, you need to get back to the fundamental question I am asking.
> What data does the function at the receive side need to rely on, and 
> where does it get that information?

The data the function relies on are the E.164 phone numbers being used (plus
some other data to prevent replay/cut+paste, but that other data can all be
sent in the new header).

The receive side gets that "data" from the To/From, but again the "data" is
E.164 numbers, not encoding strings.

> The second you start assuming a priori out-of-band knowledge, this breaks.
> Unless you can show me how that knowledge can be learned upon receipt 
> of the call, I am not buying it.

Since the existing interconnection model does deliver caller-id in an
intelligible manner, and has for many years, it clearly hasn't broken the
second it was assumed. Don't get me wrong - it's not how we'd like to do
this stuff, clearly, but we need to focus on the problem at hand - not a
different problem that might happen someday.

-hadriel