Subject: [Iptel] trunk-group draft: parameter name contemplation...

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 03 Nov 2005 11:56:17 +0100

After reading through RFC3261 and RFC3966 again, i'd appreciate your 
comments of the following issue:

According to the ABNF of draft-ietf-iptel-trunk-group-04, trunk group 
related parameters to the "tel" URI are to be specified in the exact order

tel:<omitted>;trgrp=BLA;trunk-context=example.com

so that the "trunk-context" parameter immediately follows the "trgrp" 
parameter. According to RFC3261, Section 19.1.6, telephone-subscriber 
parameters should be ordered lexically by parameter name when they are 
incorporated in a SIP URI user part. This would not change anything in the 
plain example above ("trunk-context" > "trgrp"). However, if a future 
parameter with a name "between" those two parameters is introduced (see 
example below):

tel:<omitted>;troll=yes;trgrp=BLA;trunk-context=example.com

It would be mapped to a SIP URI of:

sip:<omitted>;trgrp=BLA;troll=yes;trunk-context=[email-masked]

effectively splitting the trunk parameters because the new parameter "troll" 
is lexically in between. Broken implementations might then not recognize the 
trunk parameters because they expect "trunk-group" immediately following 
"trgrp" even in SIP URIs.

Does the group consider this a problem?

If it does, the issue could probably be mitigated by either:

- renaming one of the parameters ("trgrp-context"?)
   [that does not _solve_ it, as there are always strings "between"]
- instructing IANA to not register any tel URI parameter "between"
- relaxing the order of the parameters
- clarifying that clients which parse SIP user parts as tel URI must
   must not rely on the parameter order.

Anything else?

comments appreciated.

Alex Mayrhofer
enum.at

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

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 05 Nov 2005 08:29:47 -0800

That is a great catch. I think we should fix the BNF so that it relaxes the
order constraint and perhaps add a note pointing out the the troll example.

Seems there are two ways to fix the ABNF, one would be

 par = parameter / extension  / isdn-sub / trunk-group / trunk-group-context

and then add text that say if there is a trunk-group there MUST be a
trunk-group-context. The other way might be to define

trunk-group = ";tgrp=" trunk-group-lable [ *(par) ] ";trunk-context="
trunk-context

Now par is defined as allowing a trunk-group in it and trunk-group allows a
par in it and I no longer know if this is a valid ABNF. I think I prefer the
first approach. 

Cullen

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 08 Nov 2005 00:48:49 -0600

Cullen Jennings wrote:
> That is a great catch. 

Agreed.  Thanks for connecting the obtuse dots, Alex.
More inline.

> I think we should fix the BNF so that it
> relaxes the order constraint and perhaps add a note pointing out the
> the troll example.
> 

There is one more option that does not depend on lexicographical
ordering at all.  For the sake of completeness, I will list it
here, but I will note that if we had to choose, I would rather
choose Cullen's first option listed above.

The third option is to have one name-value parameter,
but impose some order on the value portion of that parameter.
In other words,

par = parameter / extension/ isdn-sub / trunk-group
trunk-group = ";tgrp=" trunk-group-label

and impose some order on trunk-group-label such that what used
to be "trunk-context" occurs now in trunk-group-label, possibly
following the label itself in some well defined manner.  While
this shields implementations from lexicographical ordering, it
has the capacity to introduce some brittleness in system.

For that reason, I prefer Cullen's first option.  It appears
to be one with the least amount of disruption to what is currently
specified.

Any other thoughts?  If not, I will just as soon choose it...

Thanks,

- vijay

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 08 Nov 2005 07:12:51 -0800

> Any other thoughts?  If not, I will just as soon choose it...

I'm voting for just choose soon :-)