On Tue, 2010-02-02 at 10:21 -0500, Carolyn Beeton wrote: > Are URLs supposed to have angle brackets, or are they optional? > > I am seeing this string: > entity=\"sip:m...@panther.pingtel.com:512;transport=tcp\" > converted to > entity="<sip:m...@panther.pingtel.com:512>;transport=tcp" > during the trip through SipDialogEvent, which converts the entity string > to a Url when it does buildBody. > > These angle brackets cause problems because they are themselves part of > an xml dialog-info message, and are not being escaped properly. This > shows up in the SAA feature and Nortel 1220 phones in particular (see > http://track.sipfoundry.org/browse/XX-7549) > > I think the correct thing to do is to unescape and escape when parsing > and generating the entity field - correct? But I wonder why these > brackets are being inserted when they weren't there originally.
There are two syntactic contexts within which a "URI" can appear. One is called "name-addr" and one is called "addr-spec". These borrow their names from BNF productions in section 25.1 of RFC 3261. More exactly, every syntactic context for a "URI" is either: - addr-spec, called "addr-spec" in the BNF of RFC 3261, which is also the same as a SIP URI. The critical point is that in the form "sip:x...@yyy;ppp=vvv", the "ppp=vvv" is a parameter on the URI, a "URI parameter". - name-addr, which is actually a shorthand for the BNF "name-addr / addr-spec" in RFC 3261. It is *not* a URI, despite that it contains one and is often called a URI in informal conversation. The critical point is that in the form "sip:x...@yyy;ppp=vvv", the "ppp=vvv" is a "field parameter", a parameter which modifies the significance of the URI within the operation specified by the URI's context. (If the URI needs to have a URI-parameter, it is enclosed in <...>: "<sip:x...@yyy;URI-param=value>". If field-parameters are also needed, they can be combined thus: "<sip:x...@yyy;URI-param=value>;field-param=value".) In practice, parsing a URI (converting from a string to the Url object) can only be done correctly if you know which context the URI appears in, as that determines how "sip:x...@yyy;ppp=vvv" is to be interpreted. Unparsing a URI (converting the Url object to a string) also requires knowing the context into which the string will be put, because in a name-addr, a URI-parameter must be represented "<sip:x...@yyy;ppp=vvv>", whereas in an addr-spec, that syntax is invalid, and "sip:x...@yyy;ppp=vvv" must be used. In the context of the "entity" element of a dialog event, the string which is the value of that attribute is supposed to be a URI (that is, addr-spec), so the enclosing <...> should not appear at all. (I'm fixing that latter bit.) Dale _______________________________________________ sipx-dev mailing list sipx-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
