Subject: [dispatch] comment on draft-peterson-terq-02

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Nov 2012 20:42:53 -0400

I have one small comment on this draft:

Section .1.1. TN Range Type:

This is incomplete without an explanation of how to determine what 
numbers are and are not "between" a pair of numbers.

For some pairs this is fairly easy to define. But one can find pairs of 
<telephone-subscriber> values for which this is ambiguous or undefined.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 2 Nov 2012 11:50:33 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

In regard to the type definitions:

   6.1.  Telephone Number Type

   The telephone number type conforms to the telephone number syntax
   given in RFC3966 Section 3, in the ABNF for "telephone-subscriber."

   Type Code: T

   [TBD - need for subtying?  E.164, Service Code, Short Code, Prefix,
   Nationally-Specific and Unknown. ]

As I read it, <telephone-subscriber> can be <local-number>, which
includes a <context>, with the format "phone-context=...".  So it
looks like you're already including some subtyping facility.  More
importantly, you're likely to have to standardize the subtyping to
make the lookup mechanism useful.  (What do people do now within
lookups?  If we don't cover the current use cases, the new system will
be shut out of many environments.)

   6.1.1.  TN Range Type

   The TN range type consists of a set of two telephone number types,
   and semantically includes all numbers between those two numbers.

   Type Code: R

Presumably meaning, "includes the two numbers and all numbers between
them".  But that requires defining "between".  (BTW, the presence of
<visual-separator> in <telephone-subscriber> is going to make
everything harder.)

More subtly, it means that a query must include both a first number
and a last number.  That makes it somewhat hard to express a set like
"the United States phone numbers with area code 617".  That set can be
specified as "16170000000 through 16179999999", but that requires that
you know that US E.164 phone numbers have 11 digits total.  It would
be far more natural to specify "the range starting with 1617, to but
not including 1618 (in lexicographic order)".  Or even better "all
numbers starting with 1617".

There are some messy interactions between TN ranges and TN subtypes...

   6.5.  Service Provider Identifier (SPID) Type

   The SPID type consists of a four-digit number.

   Type Code: S

Is 10,000 service providers enough?  A proposal several ITEFs ago had
8-digit service provider numbers.

   6.7.  Display Name Type

   The display name type conforms to the "display-name" ABNF given in
   RFC3261.

   Type Code: N

Given that the value of this item is quoted by its context, do we
require the double-quotes and backslash-escaping provided by the
<quoted-string> alternative to <display-name>?  (Or the "LWS" that can
follow <token>?)  Wouldn't this datum more naturally be a string of
Unicode characters (UTF-8 encoded)?

   6.9.  Priority Type

   The Priority type contains an integer between 0 and 1.

   Type Code: P

There aren't many *integers* between 0 and 1.

    "Bleem, that's what.  Bleem!" shouted Ersheim, banging his fists
    against the desk.  He then leaned close to Tomlin and whispered, "The
    secret integer between three and four."
    -- "The Secret Number" by Igor Teper

What is it you really mean?

   6.10.  Extension Type

   This code is reserved for future use.

   Type Code: X

It seems to me that it would be beneficial to specify the subtyping
mechanism now so we have a clear idea what the expansion mechanism is.
(I assume that the first byte of the value will contain a code
specifying the expansion type.)

Dale

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 2 Nov 2012 14:00:55 -0400

The text there is pretty strawman-ish, for all of the Element Types. The intent here is really just to put some initial stakes in the ground, and to show how we could build on existing work rather than defining new semantics for these categories. 

You are surely correct that ranges aren't trivial to determine for some numbering plans. There are of course a number of approaches to handling ranges: one is just to describe a prefix. Part of the analysis we'd need to do here is to determine what's the simplest way of specifying a range that actually works - there are number ranges that can't be described with prefixes, of course. Hopefully we can come up with some text that explains what "between" means in a way that is generalizable across the numbering plans we know.

Jon Peterson
NeuStar, Inc.

On Nov 1, 2012, at 5:42 PM, Paul Kyzivat wrote:

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 2 Nov 2012 14:48:20 -0400

A couple quick points:

Agreed about the potential complications of using RFC3966, but, I think we need to decide fairly earlier on if we're going to rely on existing work as much as possible rather than reinventing the wheel here. If there is a better subset of the RFC3966 syntax that we can appropriate, perhaps, that would be a good thing to explore. I certainly hope we can reuse the work there. The assumption in lookups today is that they cover only fully-qualified E.164 numbers, though that is at best a polite fiction, and hides plenty of cobwebs we should clear out if we're taking a fresh look at the problem space.

Regarding the length of the SPID field, the SPID Type given here might differ from a, say, GSPID Type, or ITAD Type, or what have you, which could be specified as independent types in the data model. We certainly don't want to close the door on that. In the current vernacular of the PSTN, four-digit SPIDs are common, but I'm not aware off the top of my head of any existing IETF specification that gives their syntax or semantics (otherwise I'd just be pointing to it).

And yes, err, the set of integers between 0 and 1 is smaller than what service providers likely require to express priority. Blame the editor for that one.

The question of whether we need the restrictions of "display-name" is tough, as the data provided today in CNAM certainly only exercises a subset of Unicode, say. I think given the overarching goal of migration telephoning routing and directory functions to the Internet, we should choose a broad way of defining display names. Just specifying this as Unicode would probably work.

We do need to get the extensibility model for element types to be more clearly specified here before this spec is ready to go, totally agreed, but at this stage that''s just a placeholder.

Jon Peterson
NeuStar, Inc.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Nov 2012 14:52:38 -0400

> The text there is pretty strawman-ish, for all of the Element Types. The intent here is really just to put some initial stakes in the ground, and to show how we could build on existing work rather…

Yes, it was feeling strawman-ish when I read it.
Just trying to keep you honest.

> You are surely correct that ranges aren't trivial to determine for some numbering plans. There are of course a number of approaches to handling ranges: one is just to describe a prefix. Part of the…

Just some fun and games to do.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Nov 2012 15:09:05 -0400

> Agreed about the potential complications of using RFC3966, but, I think we need to decide fairly earlier on if we're going to rely on existing work as much as possible rather than reinventing the w…

Having now had this come up in several contexts,
I continue to be in favor of having a source (currently 3966) as an 
authoritative definition to reference. "Roll your own" attempts all seem 
to end up being inadequate.

But 3966 as it stands isn't ideal for this. I keep finding a need to 
reference <telephone-subscriber>, <global-number> or 
<global-nuber-digits>. And in many cases the desire is really to 
reference one of those while excluding <visual-separator>.

Having those symbols in the ABNF to reference is good, but it doing so 
clearly seems to be reaching beyond the intent of 3966.

Maybe it would be good to revise 3966 with the *intent* of defining an 
assortment of useful telephone-number related syntaxes, rather than just 
a URI.

	Thanks,
	Paul

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 2 Nov 2012 15:31:31 -0400

I hear you. The great compromise in RFC3966 is support for both "local numbers", effectively dial strings (which increasingly we should understand to mean any representation of a telephone number that might appear embedded on a web page), and for a canonical global format. The support for visual separators has to exist for those local use cases. Agreed that most of those requirements fall out from the need to specify the telephone number as a URI, which then must have sufficient markup to allow sensible dereferencing.

At a high level, I would not be averse to revisiting RFC3966 to find a syntax for telephone numbers independent of a URI, though whether or not that should happen in the context of the proposed work is a more complicated question.

Jon Peterson
NeuStar, Inc.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Nov 2012 15:45:34 -0400

> At a high level, I would not be averse to revisiting RFC3966 to find a syntax for telephone numbers independent of a URI, though whether or not that should happen in the context of the proposed wor…

I didn't intend to imply that this should be done in the scope of terq.
I don't have any preconceptions of how such work might be organized. It 
hardly seems like something that deserves its own wg. But I suspect that 
there would be a lot of opinions about it, so AD-sponsored also doesn't 
seem appropriate.

	Thanks,
	Paul