7 Appendix B: Product Behavior

Office

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs.

  • Microsoft Lync Server 2010

  • Microsoft Lync 2010

  • Microsoft Lync Server 2013

  • Microsoft Lync Client 2013/Skype for Business

  • Microsoft Skype for Business 2016

  • Microsoft Skype for Business Server 2015

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms SHOULD or SHOULD NOT implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term MAY implies that the product does not follow the prescription.

<1> Section 2.1:  Lync Server 2010, Lync 2010: These product versions support only Internet Protocol version 4 (IPv4). They do not support Internet Protocol version 6 (IPv6).

<2> Section 2.2.5.2:  Lync Server 2010, Lync 2010: The limit is 1 to 454 characters.

<3> Section 3.1.4.1.1.1:  Lync 2010: Lync 2010 populates the elements of the GetLocationsRequest request out of order. To interoperate with this client, the server needs to support requests that have the elements out of order. The out-of-order element sequence is specified in the product behavior note in section 3.1.4.1.2.1.

<4> Section 3.1.4.1.2.1:  Lync 2010: The Lync 2010 implementation differs from the given schema, in the sense that it sends the GetLocationsRequest with a different order sequence of IP and MAC elements. To enable interoperability with Lync 2010, the server needs to use the following schema to validate the request.

<xsd:element name="GetLocationsRequest">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:element minOccurs="1" maxOccurs="1" name="Entity" type="tns:restrictedAnyURI" />
            <xsd:element minOccurs="0" maxOccurs="1" name="WAPBSSID" type="tns:EnetMacAddressType" />
            <xsd:element minOccurs="0" maxOccurs="1" name="RSSI" type="xsd:unsignedByte" />
            <xsd:element minOccurs="0" maxOccurs="1" name="IP" type="tns:IPAddress" />
            <xsd:element minOccurs="0" maxOccurs="1" name="MAC" type="tns:EnetMacAddressType" />
            <xsd:element minOccurs="0" maxOccurs="1" name="ChassisID" type="tns:LLDPChassisIDOrPortIDTLVType" />
            <xsd:element minOccurs="0" maxOccurs="1" name="PortID" type="tns:LLDPChassisIDOrPortIDTLVType" />
            <xsd:element minOccurs="0" maxOccurs="1" name="SubnetID" type="tns:IPAddress" />
        </xsd:sequence>
    </xsd:complexType>
</xsd:element>

<5> Section 4:  Lync Server 2010: Though attribute id of the element tuple, has the type xsd:ID, the Lync Server implementation currently differs in a way that it has a colon (:) character in its value in the server response.

<6> Section 6:  Lync Server 2010, Lync 2010: Though attribute id of the complex type tuple has the type xsd:ID, the current implementations differ in that they have a colon (:) character in the id value in the response.

Show: