Subject: RE: [Sipping] draft-yu-tel-url-04.txt comment

From: "Yu, James" <[email-masked]>
Date: Mon, 15 Apr 2002 23:11:13 -0500

> Exactly, because a bis-only compliant implementation would 
> not care about
> those parameters.
> 
> However, bis DOES allow extensions (in this case your draft) 
> define new
> uri-parameters, by using the "other-parms" defined in bis. Then,
> implementations supporting your extension would support the 
> parameters, while
> implementations not supporting them would simply ignore them 
> - according to
> the rules in bis.
> 
> If you, however, put your parameters in the user-part, you may mess up
> implementations not supporting your extension, since bis 
> doesn't specify
> parameters for the user-part (even if it does allow the ";" 
> character).
>

Those parameters (rn, npdi and cic) are defined as the extensions to the tel
URL.  There were discussions on supporting tel URL a while back.  I believe
that bis has included texts that clarifies how parameters in the tel URL
(plus its extensions) are supported in the sip URL.  We are not discussing
how those tel URL extensions can be carried as the url-parameters, that is
implementation issue, as you have indicated.  We are discussing how tel URL
parameters (including extensions) are carried in the sip URL in a "standard"
way.  The consensus is that they'll appear in the user part of the sip URL
when user=phone is present.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Apr 2002 09:58:09 +0300

Hi,

> when user=phone is present.

So, what you say is: if user=phone, an implementation must always be able to
handle parameters in the SIP-URL???

If this is the case, I think it must be specified in bis, since user=phone is
also specified there.

OR, we can say that an implementation not supporting the parameters will simply
treat the whole user part as a single string, but again - that would probably be
rejected by PSTN routing handlers etc.

Regards,

Christer Holmberg
Ericsson Finland