Scott Lawrence wrote:
> Does the standard allow for non-standard elements? Even if it does, we
> will need to test for backward compatibility.
>
> It might be best to control this with an extension to the subscription -
> add a proprietary option tag (sipxecs-regpath) to a Supported header on
> the SUBSCRIBE, and provide the path element only if that is present -
> the sipXrls would send it, but any other reginfo subscriber would not
> and would then receive only the standard reginfo.
>
Here's the relevant part of the schema
.
.
<xs:element name="contact">
<xs:complexType>
<xs:sequence>
<xs:element name="uri" type="xs:anyURI"/>
<xs:element name="display-name" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="unknown-param" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="state" use="required">
.
.
The full schema is in Page 17 - http://www.ietf.org/rfc/rfc3680.txt
I am not sure, but I think the path element would fall under "<xs:any
namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>".. Also, what do you mean by maintaining backwards
compatibly (i.e. with what)?
Alternatively, we could encode the path header into the uri, i.e.
<uri>sip:[EMAIL PROTECTED];Route=my.path.com</uri>
Arjun
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
