Re: Comments on RFC2806bis

Flemming wrote:
>
>Take another example where I as a consumer actually dial a particular carrier
>selection code as part of my call, but by default, all my calls are handled by
>another carrier. I don't see how you will route this call correctly without a
>guarantee that at least one entity in the forwarding path understands the
>extension (not to mention the fact that routing can be rather inefficient if
>preceeding hops routed the call incorrectly because they didn't understand the
>extensions).
>
>In other words, I don't see how these parameters can be optional. If you are
>concerned about lack of implementation support, then perhaps the best way to
>address that is by including the extensions in 2806bis, since they 
>do seem to be
>a prerequisite for a generally useful tel-URI.
>
To which I reply:
  It can be used in SIP, but it can also be used in a static form 
(e.g. DNS NAPTR
content). In the latter case, it may be in the public ENUM space, or it might
be stored within a Service provider's private space.

I do not believe that a rn or cic parameter is a prerequisite for all these
cases - Indeed, for the static (DNS) cases one may or may not need this
parameterisation at all.

I agree with James that it cannot be mandatory (i.e. "use this or fail").
For example, looking at the SIP case, a recipient of a SIP dialog may or
may not have a trust relationship with the sender of this information.
If they do not then they are at liberty to do another dip themselves.
Thus a mandatory "do or die" is not appropriate, IMHO.

My DSL router/FW/SIPproxy/Registrar box at home sure doesn't understand
this parameter. Then again, when I outcall with this kind of URI there
WILL be some external outbound proxy and/or gateway in line, and whilst
understanding this parameter by *that* box may be required (for regulatory
reasons ?), I'd be really unhappy if my home box were to be declared
non-standard because it cannot understand nor act on a cic value but
instead passes it downstream.

For both these reasons, I belive that this is a stand-alone extension, and
is NOT a core part of RFC2806bis. Note that we lost the 'tsp=' parameter as
well in the bis process; that would also be a stand-alone extension.

all the best,
   Lawrence

-- 
[email protected]: +44 1794 833666::<my opinions>: