6 Appendix A: 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.

  • Windows NT operating system

  • Windows 98 operating system

  • Windows 2000 operating system

  • Windows Millennium Edition operating system

  • Windows XP operating system

  • Windows Server 2003 operating system

  • Windows Vista operating system

  • Windows 7 operating system

  • Windows 8 operating system

  • Windows 8.1 operating system

  • Windows 10 operating system

  • Windows 11 operating system

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.2.1.1: The Windows WIN32ERR header is only sent when condition 1 and at least one of the following conditions 2–9 are met:

  1. The NT5 dialect of the protocol is in use (not the Win95 dialect).

  2. A CONNECT, PUT, or SETPATH request is received and both of the following conditions are true:

    • The request has one or more of the following headers: NAME, LENGTH, TIME, BODY, BODY END, WHO, and WIN32ERR.

    • The value in the header is invalid or is not formatted correctly. For instance, the (nonzero) value length is less than what is expected for that header, or the file name is invalid.

      If a file name is invalid—for instance, the file name is longer than 260 characters—Microsoft implementations will always return an error.

  3. A CONNECT message is received and any of the following conditions are true:

    • The HKCU\Control Panel\Infrared\File Transfer\Allow Send registry value is set to 0.

    • The system is going to sleep.

  4. A CONNECT request is received and there is an error while creating a base file reception directory that does not already exist.

  5. A PUT or SETPATH request is received and any of the following conditions are true:

    • There is an error while creating the file or directory; for instance, access is denied.

    • The user denies permission to receive the file.

    • The user denies permission to create the directory through the UI.

  6. A PUT request is received and there is an error while trying to write the data to the file; for instance, the disk is full.

  7. A PUT request is being sent and the transfer is canceled.

  8. There is an error reading the file to be sent or there is an error during the transmission (sending) of the file data.

  9. Data is being received and either the transfer is canceled, or a transmission error occurs.

  10. If the incoming CONNECT/PUT/SETPATH request contains a WIN32ERR header with a nonzero error code, a WIN32ERR header will be sent out in the response with the same code.

<2> Section 2.2.1.1: Certain Microsoft implementations of this protocol behave differently when processing this header.

In some cases, the packet length field does not include the length of the WIN32ERR header even though the WIN32ERR header is sent. This behavior, as listed in the previous behavior note, occurs in the following four condition cases: 2 (except for receiving a CONNECT message), 5, 6, and 9.

In addition, for cases 7 and 8, the length will be wrong if the Win95 dialect of the protocol is used. The packet length will include the length of the WIN32ERR header even though the header is not sent out in the Win95 dialect. This behavior is consistent in all implementations of the Win95 dialect. All applicable Windows releases are capable of using the Win95 dialect of this profile.

<3> Section 3.1.3: At initialization time, Windows registers two class names for the IrOBEX service in the IAS store: OBEX and OBEX:IrXfer as specified in [IROBEX] section 6.1. There is no difference in behavior by the server irrespective of which class name that the client uses to connect to the server.

<4> Section 3.1.5: [IROBEX] section 3 does not explicitly state that any headers have to be supported. Unless otherwise stated, Windows discards all headers it receives and does not include any headers in messages that it sends over the link.

<5> Section 3.1.5.1: Windows parses the following optional headers as part of a CONNECT message as specified in [IROBEX] section 2.1:

  • NAME header

  • LENGTH header

  • TIME header: Both [ISO-8601] and UNIX time formats are parsed.

  • WHO Header

<6> Section 3.1.5.1: A device that relies on authenticating the server will not interoperate with the Windows implementation of the IrDA OBEX protocol profile because the authentication header in a CONNECT message is discarded.

<7> Section 3.1.5.3: Windows implementations parse the following optional headers as part of a PUT message as specified in [IROBEX] section 2.1:

  • NAME header

  • LENGTH header

  • TIME header: Both [ISO-8601] and UNIX time formats are parsed.