Subject: [Iptel] Finishing work on trunk-group

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 18 Apr 2005 17:43:40 -0500

Folks:

I will really like to finish the remaing work on trunk-group.
The I-D has been WGLC'd, and the current version (-03) is
the version that includes comments raised and addressed
during WGLC.

Shortly after I posted -03, Paul K. pointed out a small
discrepancy that is worth addressing (his email, which has
mysteriously disappeared from the archives, is reproduced
in its entirety at the end of this mail).  I will like to
resolve this point and move the I-D forward.

Paul notes that the "phone-context" parameter may not be
applicable to a global tel URI (i.e., +1...) -- it may be
valid syntactically, but it is not the intent of rfc3966 that
it appear as such (and we all know that in ABNF, what may be
syntactically correct may not be semantically so).

So, there are two ways around this:

1) Change the examples in the I-D to use local numbers, and not
    global numbers;
2) Have the I-D suggest an alternate means to approximate the
    reason we have used the "phone-context" parameter.  That is,
    replace "phone-context" parameter with another parameter (see
    below for more on this).

(1) is sweeping the problem under the rug; as such, I don't think
we should go that route.  That leaves us with (2).

The reason we are using the "phone-context" parameter is to
impose a namespace on the trunk group (the way the I-D defines it,
a trunk group MUST have a "phone-context"), BUT, a "phone-context"
cannot appear in a global tel URI.  So, we simply define a
new parameter -- call it "trunk-context" -- that has the same
semantics as a "phone-context".  This new parameter will be
defined by the trunk-group I-D as such:

  par = parameter / extension / isdn-subaddress / trunk-group

  trunk-group = ";tgrp=" trunk-group-label ";trunk-context="
                trunk-context
  trunk-group-label = *1( unreserved / escaped /
                          trunk-group-unreserved )
  trunk-group-unreserved = "/" / "&" / "+" / "$"
  trunk-context = descriptor
  descriptor = domainname / global-number-digits

The new parameter replaces "phone-context", but provides the
same semantics of imposing a namespace.

I will like the WG to comment on this, or suggest alternative
means.  I think that this is a small enough change that
assuming the WG agrees to it, I can rev the I-D and request the
WG chairs to forward the I-D to IESG.

Please send me your comments and/or concerns.  Unless I hear
otherwise, I will make the requisite change and, hopefully,
finsish the pending work on trunk-group.

Thank you.

Begin Paul's original email ------

Subject: [Iptel] Re: draft-ietf-iptel-trunk-group-03
From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Feb 2005 19:26:05 -0500
To: "Vijay K. Gurbani" <[email-masked]>, [email-masked]
CC: iptel <[email-masked]>

One thing concerns me in this draft:

You are requiring use of the phone-context parameter, even with global 
numbers, such as:

     tel:+15555551212;phone-context=telco.example.com;tgrp=tg55

Now this may be debatable, but I believe that usage is currently invalid 
according to RFC3966. (Phone-context is only valid with a local-number.) 
Here is some of the ABNF from 3966:

    telephone-uri        = "tel:" telephone-subscriber
    telephone-subscriber = global-number / local-number
    global-number        = global-number-digits *par
    local-number         = local-number-digits *par context *par

    context              = ";phone-context=" descriptor

    par                  = parameter / extension / isdn-subaddress
    extension            = ";ext=" 1*phonedigit
    isdn-subaddress      = ";isub=" 1*uric

    parameter            = ";" pname ["=" pvalue ]
    pname                = 1*( alphanum / "-" )

Its arguable because "phone-context" can be parsed as both a 'context' 
and a 'parameter'. But I think it is pretty clear that isn't the intent. 
(And if it was, then semantically it would just be a parameer, not a 
context.)

So I think you need to make a *change* rather than just an *extension* 
to 3966 if you want to use phone-context with global numbers.

     Paul

End Paul's original email ------

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Apr 2005 19:06:26 -0400

Vijay,

I only have one point, and I think it is just a matter of my needing a 
clarification of your intent.

How do you imagine these parameters end up in a URI? I can only think of 
two ways:

- a request is coming in from a gateway. It knows the trunk group and so 
can form the URI as a contact address, or whatever.

- a request is going out toward a gateway. Initially the address is 
known as a phone number. Some server manages the gateway and is aware of 
the resources it contains and how they are named. It rewrites the R-URI, 
inserting tg and tg-context parameters.

I'm thinking about the latter case, if it is even in scope.

Then I am also thinking about the possiblity that the telephone number 
that is heading toward the gateway is a local rather than global number. 
 From your syntax, I presume you believe that to be ok.

For it to begin life as a local number, before having the tg added, it 
must have had a phone context. E.g. something like:

	tel:411;phone-context=+1

Now, when the proxy decides to insert the tg and tg-context, does the 
phone-context remain, or is it removed and *replaced* by the tg-context? 
Any clue what the relationship between the contexts might be?

E.g. which of the following does the above become?

	tel:411;tg=3;tg-context=+1
	tel:411;phone-context=+1;tg=3;tg-context=+1
	tel:411;phone-context=+1;tg=3;tg-context=something.else

I don't much care, as long as it works and makes sense. Maybe an example 
or two showing how this should work would help.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Apr 2005 09:48:55 -0500

> I'm thinking about the latter case, if it is even in scope.

Paul:

The latter case is actually what caused us to look into this
in the first place.

> Any clue what the relationship between the contexts might be?
[...]

OK; I see your point.  If it is a local number, it will have a phone-
context added.  This means that the trunk-context cannot replace
phone-context, it acts as another qualifier.

> or two showing how this should work would help.

Sure; in the next rev, I will spell out the interaction between
these with an example or so.

Thanks,

- vijay

---

From: "Shan Lu" <[email-masked]>
Date: Mon, 25 Apr 2005 15:40:29 -0400

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Vijay K. Gurbani
>Sent: Tuesday, April 19, 2005 10:49 AM
>To: Paul Kyzivat
>Cc: IETF IPTEL WG
>Subject: Re: [Iptel] Re: Finishing work on trunk-group
>
>
<snip>

Vijay,

I support adding "trunk-context". But I would prefer to allow 
"tel:411;phone-context=foo.com;tgrp=abc123" as a valid format. If
"trunk-context" is present, it defines context for the trunk group. If not,
"phone-context" serves that purpose. 

Often times, tel uri is carried in sip uri. The userinfo portion already
looks ugly w/o "trunk-context" :-)

>these with an example or so.

Would you be able to post your text/example to list before submitting new
rev? It may save another round of commenting.

Thanks,

Shan Lu