According to RFC 3261, a URI field (name-addr) should not have two URI parameters with the same name, or two field parameters with the same name. The current Url class is not set up to enforce this restriction at all, though it appears that no user of the Url class expects this restriction to be violated. Overall, cleaning up the situation is not complicated. However, there is the question of what to do when we are asked to parse a name-addr that has parameters with duplicate names. There are several strategies:
- Consider the URI to be invalid. This would take extra work to enforce, since we currently do not parse the parameters until the caller demands it. - Accept the duplicate parameters; in particular, when reconstituting the string version of the URI (Url::toString(), et al.), generate duplicate parameters. This causes the reconstituted string to closely resemble the original string, but the reconstituted string is invalid according to RFC 3261. - Have one parameter value (e.g., the first or the last) be effective and ignore the others. This allow the reconstituted string to always be valid, but it may be significantly different from the original string. Comments? Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
