</a:Address> </a:EndpointReference> </d:Bye> </s:Body> </s:Envelope> Lines (06-08) indicate this is a Bye, and like Hello in , Line (12) indicates that it is sent unicast to a Discovery Proxy over HTTP. Like Hello in , the application sequencing information is omitted because the messages sent unicast over HTTP are received in the same order in which they are sent. Like Bye in Table 10 the Body (Lines 15-21) is an abbreviated form of the corresponding information in the Hello. Client In an ad hoc mode, Clients SHOULD listen for Bye messages, marking or removing corresponding information as invalid. Clients MAY wish to retain information associated with a Target Service that has left the network, for instance if the Client expects the Target Service to rejoin the network at some in the future. Conversely, Clients MAY discard information associated with a Target Service at any time, based on, for instance, preset maximums on the amount of memory allocated for this use, lack of communication to the Target Service, preferences for other Target Service Types or Scopes, and/or other application-specific preferences. Discovery Proxy In an ad hoc mode, A Discovery SHOULD send a Bye for itself (as a Target Service of type) d:DiscoveryProxy when it is preparing to leave the network as described in Section 4.2.1 Target Service. A Discovery Proxy MAY be configured to reduce multicast traffic on an ad hoc network, in this capacity: A Discovery Proxy MUST listen for multicast Bye messages, marking or removing corresponding information as invalid. In a managed mode, A Discovery Proxy MUST listen for unicast Bye messages, marking or removing corresponding information as invalid. Note that both in an ad hoc mode and a managed mode, a Discovery Proxy MAY retain information associated with a Target Service that has left the network, for instance if the Discovery Proxy expects the Target Service to rejoin the network at some point in the future. Conversely, Discovery Proxy MAY discard information associated with a Target Service at any time, based on, for instance, preset maximums on the amount of memory allocated for this use, lack of communication to the Target Service, preferences for other Target Service Types or Scopes, and/or other application-specific preferences.
</a:Address> </a:EndpointReference> </d:Bye> </s:Body> </s:Envelope> Lines (06-08) indicate this is a Bye, and like Hello in , Line (12) indicates that it is sent unicast to a Discovery Proxy over HTTP. Like Hello in , the application sequencing information is omitted because the messages sent unicast over HTTP are received in the same order in which they are sent. Like Bye in Table 10 the Body (Lines 15-21) is an abbreviated form of the corresponding information in the Hello. Client In an ad hoc mode, Clients SHOULD listen for Bye messages, marking or removing corresponding information as invalid. Clients MAY wish to retain information associated with a Target Service that has left the network, for instance if the Client expects the Target Service to rejoin the network at some in the future. Conversely, Clients MAY discard information associated with a Target Service at any time, based on, for instance, preset maximums on the amount of memory allocated for this use, lack of communication to the Target Service, preferences for other Target Service Types or Scopes, and/or other application-specific preferences. Discovery Proxy In an ad hoc mode, A Discovery SHOULD send a Bye for itself (as a Target Service of d:DiscoveryProxy type) when it is preparing to leave the network as described in Section 4.2.1 Target Service. A Discovery Proxy MAY be configured to reduce multicast traffic on an ad hoc network, in this capacity: A Discovery Proxy MUST listen for multicast Bye messages, marking or removing corresponding information as invalid. In a managed mode, A Discovery Proxy MUST listen for unicast Bye messages, marking or removing corresponding information as invalid. Note that both in an ad hoc mode and a managed mode, a Discovery Proxy MAY retain information associated with a Target Service that has left the network, for instance if the Discovery Proxy expects the Target Service to rejoin the network at some point in the future. Conversely, Discovery Proxy MAY discard information associated with a Target Service at any time, based on, for instance, preset maximums on the amount of memory allocated for this use, lack of communication to the Target Service, preferences for other Target Service Types or Scopes, and/or other application-specific preferences.