Partager via

7 Appendix B: Product Behavior

  • Article

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

  • 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

  • Microsoft Skype for Business 2019

  • Microsoft Skype for Business Server 2019

  • Microsoft Skype for Business 2021

  • Microsoft Skype for Business LTSC 2024

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates 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.