История изменений

https://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2

 Selection owners are required to support the following targets. All other targets are optional.

    * TARGETS - The owner should return a list of atoms that represent the targets for which an attempt to convert the current selection will succeed (barring unforseeable problems such as Alloc errors). This list should include all the required atoms.
    * MULTIPLE - The MULTIPLE target atom is valid only when a property is specified on the ConvertSelection request. If the property argument in the SelectionRequest event is None and the target is MULTIPLE, it should be refused.

    When a selection owner receives a SelectionRequest (target==MULTIPLE) request, the contents of the property named in the request will be a list of atom pairs: the first atom naming a target and the second naming a property ( None is not valid here). The effect should be as if the owner had received a sequence of SelectionRequest events (one for each atom pair) except that:
        The owner should reply with a SelectionNotify only when all the requested conversions have been performed.
        If the owner fails to convert the target named by an atom in the MULTIPLE property, it should replace that atom in the property with None . 

Convention

    The entries in a MULTIPLE property must be processed in the order they appear in the property. For further information, see section 2.6.3. 

The requestor should delete each individual property when it has copied the data from that conversion, and the property specified in the MULTIPLE request when it has copied all the data.

The requests are otherwise to be processed independently, and they should succeed or fail independently. The MULTIPLE target is an optimization that reduces the amount of protocol traffic between the owner and the requestor; it is not a transaction mechanism. For example, a client may issue a MULTIPLE request with two targets: a data target and the DELETE target. The DELETE target will still be processed even if the conversion of the data target fails.

    * TIMESTAMP - To avoid some race conditions, it is important that requestors be able to discover the timestamp the owner used to acquire ownership. Until and unless the protocol is changed so that a GetSelectionOwner request returns the timestamp used to acquire ownership, selection owners must support conversion to TIMESTAMP, returning the timestamp they used to obtain the selection. 

https://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2

 Selection owners <b>are required to support the following targets. All other targets are optional</b>.

    * TARGETS - The owner should return a list of atoms that represent the targets for which an attempt to convert the current selection will succeed (barring unforseeable problems such as Alloc errors). This list should include all the required atoms.
    * MULTIPLE - The MULTIPLE target atom is valid only when a property is specified on the ConvertSelection request. If the property argument in the SelectionRequest event is None and the target is MULTIPLE, it should be refused.

    When a selection owner receives a SelectionRequest (target==MULTIPLE) request, the contents of the property named in the request will be a list of atom pairs: the first atom naming a target and the second naming a property ( None is not valid here). The effect should be as if the owner had received a sequence of SelectionRequest events (one for each atom pair) except that:
        The owner should reply with a SelectionNotify only when all the requested conversions have been performed.
        If the owner fails to convert the target named by an atom in the MULTIPLE property, it should replace that atom in the property with None . 

Convention

    The entries in a MULTIPLE property must be processed in the order they appear in the property. For further information, see section 2.6.3. 

The requestor should delete each individual property when it has copied the data from that conversion, and the property specified in the MULTIPLE request when it has copied all the data.

The requests are otherwise to be processed independently, and they should succeed or fail independently. The MULTIPLE target is an optimization that reduces the amount of protocol traffic between the owner and the requestor; it is not a transaction mechanism. For example, a client may issue a MULTIPLE request with two targets: a data target and the DELETE target. The DELETE target will still be processed even if the conversion of the data target fails.

    * TIMESTAMP - To avoid some race conditions, it is important that requestors be able to discover the timestamp the owner used to acquire ownership. Until and unless the protocol is changed so that a GetSelectionOwner request returns the timestamp used to acquire ownership, selection owners must support conversion to TIMESTAMP, returning the timestamp they used to obtain the selection. 

https://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2

 Selection owners are required to support the following targets. All other targets are optional.

    * TARGETS - The owner should return a list of atoms that represent the targets for which an attempt to convert the current selection will succeed (barring unforseeable problems such as Alloc errors). This list should include all the required atoms.
    * MULTIPLE - The MULTIPLE target atom is valid only when a property is specified on the ConvertSelection request. If the property argument in the SelectionRequest event is None and the target is MULTIPLE, it should be refused.

    When a selection owner receives a SelectionRequest (target==MULTIPLE) request, the contents of the property named in the request will be a list of atom pairs: the first atom naming a target and the second naming a property ( None is not valid here). The effect should be as if the owner had received a sequence of SelectionRequest events (one for each atom pair) except that:
        The owner should reply with a SelectionNotify only when all the requested conversions have been performed.
        If the owner fails to convert the target named by an atom in the MULTIPLE property, it should replace that atom in the property with None . 

Convention

    The entries in a MULTIPLE property must be processed in the order they appear in the property. For further information, see section 2.6.3. 

The requestor should delete each individual property when it has copied the data from that conversion, and the property specified in the MULTIPLE request when it has copied all the data.

The requests are otherwise to be processed independently, and they should succeed or fail independently. The MULTIPLE target is an optimization that reduces the amount of protocol traffic between the owner and the requestor; it is not a transaction mechanism. For example, a client may issue a MULTIPLE request with two targets: a data target and the DELETE target. The DELETE target will still be processed even if the conversion of the data target fails.

    * TIMESTAMP - To avoid some race conditions, it is important that requestors be able to discover the timestamp the owner used to acquire ownership. Until and unless the protocol is changed so that a GetSelectionOwner request returns the timestamp used to acquire ownership, selection owners must support conversion to TIMESTAMP, returning the timestamp they used to obtain the selection.