Subject: Re: PINT-Parser, questions & proposuals

From: [email-masked] (Lawrence Conroy)
Date: Thu, 12 Aug 1999 15:03:26 +0100

At 2:20 am 12/8/99, Henning Schulzrinne wrote:
>> I would invite opinions from others at this point, too. Perhaps I could state
>> mine for what it is worth, too: I think that the telephony URL is an elegant
>> thing, which would end up standardized sooner or later, anyway. But then
...
>
>One possible course of action might be to ask the AD and the I-D author
>whether to make the tel: I-D a PINT work item and then immediately call
>for a WG last call, as the draft seems to have undergone a lot of
>informal review, judging from the time it has been around and the
>version number. This might accelerate the process. PINT is more likely
>than MMUSIC to have the right kind of people on its mailing list to
>provide technical review.
>
To which I reply:

I think that there are a couple of places in the current (-08) tel-url
draft where a little work could be done. I had hoped to see Antti in Oslo,
but it looks like it'll be done on the list - as Henning suggests, PINT is
as good a place as any and may be more appropriate than on conf-ctrl (Igor
& Steve permitting :).

For example, the definition in the draft for 'area:' is not quite what we
have in PINT (for one thing, we call it 'phone-context:' :). We also have
private contexts, and these are not (yet) included in Antti's draft.

Also, from a purely textual poing of view, I'm happier if the draft
mentions that local numbers are part of a dialling plan, whilst
international numbers are part of a number plan - these are different.
Perhaps this matters more when one comes on to Private Network Numbering
Plans and Private Network Dialling Plans; these are the meat and drink of
private phone networks (or Centrex systems).
Hmmm...did someone mention NATs?

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"|
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

---------
This message came from the IETF PINT Working Group Mailing List.

---

From: Scott Bradner <[email-masked]>
Date: Thu, 12 Aug 1999 10:54:30 -0400 (EDT)

no ID with a restrictive boilerplate can be considered for 
IETF standards action

Scott

---------

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 12 Aug 1999 12:07:37 -0400

> no ID with a restrictive boilerplate can be considered for 

Right.  The proper thing to do is to approach the author and offer a WG home 
for the draft.  (Right now, it's an individual submission.)  I personally 
don't care whether it's in PINT or MMUSIC; I'll leave that to the area 
directors.

---------

---

From: [email-masked]
Date: Fri, 13 Aug 1999 09:37:09 +0200

> You might think that this solves the problem, but unfortunately not quite,
> because a URL like:
>
> sip:+16177387225;user=phone
>
> is not a valid SIP url, because there is no hostport part. (i.e. there
> is no "@hostname" part after the +16177387225).

Another solution might be this one:

if you want to call from a SIP terminal into the PSTN, there will likely
be a need to specify the address of an IP-PSTN gateway. Somewhere in the
RFC2543 or one of the SIP/PINT drafts I've seen it done like this:

sip: [email-masked];user=phone

where net2phone.com is the DNS name of an IP-PSTN gateway, which knows how
to transfer this call to PSTN. As far as I can tell this is a valid SIP url,
and it solves your problem.

Angelo

========================================================================
A house is a machine built for living in.
                                     (Read on a t-shirt)
========================================================================
Ing. A.E.M. Hulshout                         [email-masked]
Philips Research Laboratories          Information & Software Technology
Prof. Holstlaan 4 (Building WL11)                         Room WL p 1.20
5656 AA Eindhoven, The Netherlands                Tel. (+31 40 27) 43704
========================================================================

---------

---

From: [email-masked] (Lawrence Conroy)
Date: Fri, 13 Aug 1999 14:33:43 +0100

>and it solves your problem.

I seem to remember that some examples in conf-ctrl were using the "empty
hostport" style of Request-URIs. These are, as Jonathon points out,
invalid.

It's likely that PINT infrastructures will be somewhat simpler than SIP
ones (many fewer proxies/redirect servers in the path).
We COULD define this as a variant on SIP. In that case, PINT would relax
the requirement on hostport relative to SIP.  I wholeheartedly agree with
Scott's desire for this approach - A private/corporate PINT proxy could
easily add a default hostport for "it's users" when proxying the requests
onwards to a public net PINT Gateway. However, as that might break any SIP
proxy the message encountered, IMHO (and with regrets) this is NOT a good
idea.

Angelo's suggestion fits with what we have in the draft already, and works
fine.

Whether or not someone wants to provide a NON-COMPLIANT proxy and client
for corporate use that appends a hostport on exit from the corporate
environment is another matter. As long as, by the time it hits the rest of
the world, it's in a form that can be unambiguously recognised, who's to
know? This is no more bizzare than the record-route//route report removal
stuff in SIP that hides the internal structures of a corporate net. The
only real difference seems to be that we might do this for convenience,
whilst the route removal stuff is for privacy.

All the best, Lawrence

---------