Comments on Telephony-URL draft

[[e-mail] (Lawrence Conroy)]

In answer to the request for comments on the Telephony-URL final call,
herewith::

Generally, it's an excellent piece of work. Many thanks to Antti!

Specifically, there are a couple of bits that I would like to be changed
slightly to align with what we have already in PINT - I think these changes
will help to expand the Telephony-URL into something that can specify
pretty much any kind of telephone address.

*    The name "Area Specifier" and it's tag 'area'.
Please can we change these to something different?
It has caused confusion with the term 'area codes' used in North America,
when it it much more flexible in scope.

My vote's for "phone-context", as we use this neutral term in the PINT
draft already (and it means I don't have to go through and change them all
:).

*    Area-specifier allowed values;
In PINT we have two options not covered in the Telephony-URL draft. These
are local-context and private-context.

(i) Local Context
In those cases where there is an implicit "enclosing context" that is known
to both the sender and recipient of a Telephony-URL, then the value of the
area-specifier may usefully discard this enclosing context. If this is done
then the area-specifier holds a local number form (rather than the fully
qualified value). This could be useful where the recipient is connected to
a private network, and the phone-context could indicate, for example, the
PBX number. An E.164 number form would be inappropriate in this case (IMHO)
as a context.

(ii) Private Context
An alternative is also allowed in the PINT draft, and could usefully be
added to the Telephony-URL draft; this is the concept of 'private
contexts'.
I'm not completely happy with the name private context (contributions
gratefully received :), but the aim is to allow whatever characters are
needed as a context in this case.

In the PINT draft we suggested that such a context should start with an
x-token, and MUST start with a character that is neither a digit nor a '+'
so that it can be deleniated from either a global of local "public"
context.

This could be particularly useful in indicating, for example, one of a
number of private number plans; in this case, the x-token could indicate in
text form the name of the private number plan (e.g. X-IBM-vnet).

*    The syntax proposed for future-extension may have an implication on
the users of Telephony-URLs (such as SIP). The form suggested seems pretty
flexible, but is a tad more restrictive than that proposed in RFC2543.
Seems OK to me - comments from anyone else?

----------------------
In summary...
The collected BNF covering these is as follows, (and would replace the BNF
for area-specifier shown in the current Telephony-URL draft).

area-specifier = phone-context-tag "=" phone-context-ident
phone-context-tag = "phone-context"
phone-context-ident = network-prefix / private-prefix
network-prefix = intl-network-prefix / local-network-prefix
intl-network-prefix = "+" 1*<DIGIT>
local-network-prefix = 1*<DIGIT>
private-prefix = 1*excldigandplus 0*<uric>
excldigandplus = (0x21-0x2d,0x2f,0x40-0x7d)

(I'd like to keep the 'phone-context-tag' intermediate token if possible,
as we use it in the PINT BNF and it would mean we don't have to keep the
documents synchronised by cutting and pasting).


All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- [e-mail]  ---+- Tel: [phone]  Fax: [phone] --|