6 Appendix A: Product Behavior

Article
02/14/2019

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 Office 2010 suites
Microsoft Office Groove 2007
Microsoft Office Groove Server 2007
Microsoft Groove Server 2010
Microsoft SharePoint Workspace 2010

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: The Office Groove 2007 clients support both the Secure Tunnel and SOCKS tunneling protocol, but the SharePoint Workspace 2010 clients support only the Secure Tunnel protocol. The SharePoint Workspace 2010 clients do not support the SOCKS protocol.

<2> Section 2.2.1.2.3: The Office Groove 2007 and SharePoint Workspace 2010 clients specify the following User-Agent product token value string:

"Mozilla/4.0 (compatible; MSIE 5.5; Win32)"

Implementers are advised to provide an implementation specific string as their product token value string.

<3> Section 2.2.1.2.8: The Office Groove 2007 and SharePoint Workspace 2010 implementations do not follow the common usage form for multiple cache-directives. Each cache-directive is specified using a separate Cache-Control Header. This syntax is used in place of the more common form of a single Cache-Control Header with a comma separated list of cache-directives.

<4> Section 2.2.1.3.2: The Office Groove Server 2007 relay server specifies the following Server header server product name and version token value as the HTTP Response Server header string:

"Groove-Relay/12.0"

The Groove Server 2010 relay server specifies the following Server header server product name and version token value as the HTTP Response Server header string:

"Groove-Relay/14.0"

Implementers are advised to provide an implementation-specific server product name and version string to identify their implementation.

<5> Section 2.2.2.1.1.3: The Office Groove 2007 and SharePoint Workspace 2010 implementations use 0x7ffff000 (2147479552 decimal) octets as the LongLived-Content-Length value. If implementers choose to increase this length, they are advised to do extensive testing with a wide variety of proxies to determine if the new length is within the proxies’ acceptable limits.

<6> Section 3.1: If only port 80 is allowed through the firewall, the Office Groove 2007 and SharePoint Workspace 2010 clients always use the LongLived Encapsulation Protocol. The implementer could choose to use KeepAlive or Polling Encapsulation as their preferred protocol.

<7> Section 3.1: The Office Groove 2007 and SharePoint Workspace 2010 client implementation HTTP based encapsulation protocols (LongLived, KeepAlive, Polling) use only the HTTP proxy.

<8> Section 3.1.1.2: Firewalls are generally transparent to clients. Clients need no configuration information to use a firewall, as firewalls perform routing at Layer 3 (Network Layer) of the OSI model [ISO/IEC 7498-1:1994].

Proxies are not transparent to clients. Clients need to be configured with the proxy connection information (FQDN, PORT, and Protocol) to be able to establish a connection with a proxy. The Office Groove 2007 and SharePoint Workspace 2010 clients use the proxy configuration information from a browser. The Office Groove 2007 and SharePoint Workspace 2010 clients can also access proxy auth-configuration or PAC files to get this information. In this case all that is needed is the proxy FQDN and Port Number. Therefore Office Groove 2007 and SharePoint Workspace 2010 clients do not actually store the proxy configuration persistently.

<9> Section 3.1.2.3: The Office Groove 2007 and SharePoint Workspace 2010 implementations of SSTP [MS-GRVSSTP] assists the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols are used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommended behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<10> Section 3.1.2.3: The Office Groove 2007 and SharePoint Workspace 2010 clients' HTTP Encapsulation implementation adjusts the SSTP protocol layer implementation’s default KeepAlive timer value. The HTTP Encapsulation layer overrides the SSTP default KeepAlive timer value, changing the default value of 5 minutes to 45 seconds. The default SSTP KeepAlive timer is modified to increase the frequency of the KeepAlive messages to help ensure that proxies do not treat the connections as idle and close them.

<11> Section 3.1.4.1: The Office Groove 2007 and Microsoft SharePoint Workspace 2010 clients' connect sequence without proxies configured is as follows. The client attempts to create a direct connection using the following protocols in the specified order. If any attempt succeeds, the direct connection to the target server is established. If all connection attempts fail, then the connection attempt to the target server fails. The Office Groove 2007 and SharePoint Workspace 2010 clients attempt connections in the following order:

SSTP 2492/TCP connecting
SSTP 443/TCP connecting
HTTP LongLived Encapsulation 80/TCP connecting

The Office Groove 2007 and SharePoint Workspace 2010 clients' connect sequence with proxies configured is as follows. The client attempts to create a proxy connection using the following protocols in the specified order. If any attempt succeeds, the connection to the target server is established. If all connection attempts fail, then the connection attempt to the target server fails. The Office Groove 2007 and SharePoint Workspace 2010 clients attempt connections in the following order:

1. Secure Tunnel Encapsulation 443/TCP connecting

2. SOCKS Encapsulation 1080/TCP connecting (Office Groove 2007 clients only; SharePoint Workspace 2010 clients do not support SOCKS Encapsulation.)

3. HTTP LongLived Encapsulation 80/TCP connecting

4. HTTP KeepAlive Encapsulation 80/TCP connecting

5. HTTP Polling Encapsulation 80/TCP connecting

<12> Section 3.1.4.1.2: The Office Groove 2007 and SharePoint Workspace 2010 clients support the following HTTP Proxy Authentication schemes: basic authentication scheme and NTLM.

<13> Section 3.1.4.3: The Office Groove 2007 and SharePoint Workspace 2010 clients behave differently than recommended when the LongLived Encapsulation GET session maximum content length limit is reached at the server. The behavior works as expected when the client reaches the LongLived-Content-Length limit on the POST session. Following is the behavior when the server reaches the LongLived-Content-Length limit:

Recommended behavior:

The server closes the GET sessions. The client then detects the close connection request from the server and closes the virtual LongLived connection. The client then establishes a new LongLived virtual connection using a new Virtual-Connection-GUID. The client and server then begin sending and receiving data using the new LongLived connection.

Actual behavior:

The server closes the GET session. The client ignores the TCP disconnect request.

The GET session data flow stops. POST session traffic continues until the encapsulated protocol (SSTP) blocks waiting for GET session messages, at which point the LongLived connection hangs. The connection eventually times out and disconnects. The KeepAlive timer eventually causes the virtual connection to close. The client then establishes a new LongLived virtual connection using a new Virtual-Connection-GUID and starts to exchange SSTP commands.

<14> Section 3.1.6.3: The Office Groove 2007 and SharePoint Workspace 2010 implementations of SSTP [MS-GRVSSTP] assists the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommend behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<15> Section 3.2.2.3: [1] The Office Groove Server 2007 and Groove Server 2010 implementations of SSTP [MS-GRVSSTP] assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommended behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<16> Section 3.2.3.1: The Office Groove Server 2007 and Groove Server 2010 servers use a special purpose HTTP 1.0 protocol stack. Except for the subset of HTTP Request-Headers and Response-Headers specified in this document, all other HTTP Headers will be ignored as specified in the HTTP 1.0 [RFC1945] sections 5.2, 6.2 and 7.1.

<17> Section 3.2.4.2: The Office Groove Server 2007 and Groove Server 2010 servers behave differently than recommended when the LongLived Encapsulation GET session maximum content length limit is reached at the server. The behavior works as expected when the client reaches the LongLived-Content-Length limit on the POST session. Following is the behavior when the server reaches the LongLived-Content-Length limit:

Recommended behavior:

The server closes the GET sessions. The client then detects the close connection request from the server and close the virtual LongLived connection. The client then establishes a new LongLived virtual connection using a new Virtual-Connection-GUID. The client and server then begin sending and receiving data using the new LongLived connection.

Actual behavior:

The server closes the GET session. The client ignores the TCP disconnect request.

<18> Section 3.2.5.1.1: Office Groove Server 2007 and Groove Server 2010 do not check the protocol version of the encapsulation protocols.

<19> Section 3.2.5.1.1: The Office Groove Server 2007 and Groove Server 2010 relay servers do not validate that the URI contains a Relay-Server-Name that equals the local server name. The implementer is recommended to validate this field to ensure that the message was routed to the intended server.

<20> Section 3.2.5.2.1: Office Groove Server 2007 and Groove Server 2010 do not check the protocol version of the encapsulation protocols.

<21> Section 3.2.5.2.1: The Office Groove Server 2007 and Groove Server 2010 relay servers do not validate that the URI contains a Relay-Server-Name that equals the local server name. The implementer is recommended to validate this field to ensure that the message was routed to the intended server.

<22> Section 3.2.5.2.2: Office Groove Server 2007 and Groove Server 2010 use an implementation defined internal buffer size of 32768 octets.

<23> Section 3.2.6.3: The Office Groove Server 2007 and Groove Server 2010 implementations of SSTP [MS-GRVSSTP] assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommended behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<24> Section 3.3.1.2: Firewalls are generally transparent to clients. Clients need no configuration information to use a firewall, as firewalls perform routing at Layer 3 (Network Layer) of the OSI model [ISO/IEC 7498-1:1994].

Proxies are not transparent to clients. Clients need to be configured with the proxy connection information (FQDN, PORT, Protocol) to be able to establish a connection with a proxy. The Office Groove 2007 and SharePoint Workspace 2010 clients use the proxy configuration information from a browser. The Office Groove 2007 and SharePoint Workspace 2010 clients can also access proxy auth-configuration or PAC files to get this information. In this case all that is needed is the proxy FQDN and Port Number. Therefore the Office Groove 2007 and SharePoint Workspace 2010 clients do not actually store the proxy configuration persistently.

<25> Section 3.3.2.4: The Office Groove 2007 and SharePoint Workspace 2010 implementations of SSTP [MS-GRVSSTP] assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommend behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<26> Section 3.3.4.1: Firewalls are generally transparent to clients. Clients need no configuration information to use a firewall, as firewalls perform routing at Layer 3 (Network Layer) of the OSI model [ISO/IEC 7498-1:1994].

<27> Section 3.3.6.4: The Office Groove 2007 and SharePoint Workspace 2010 implementations of SSTP, as specified in [MS-GRVSSTP], assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommend behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<28> Section 3.4.2.3: The Office Groove Server 2007 and Groove Server 2010 implementations of SSTP, as specified in [MS-GRVSSTP], assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommended behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<29> Section 3.4.3.1: The Office Groove Server 2007 and Groove Server 2010 servers use a special purpose HTTP 1.0 protocol stack. Except for the subset of HTTP Request-Headers and Response-Headers specified in this document, all other HTTP Headers will be ignored as specified in the HTTP 1.0 [RFC1945] sections 5.2, 6.2 and 7.1.

<30> Section 3.4.5.1.1: Office Groove Server 2007 and Groove Server 2010 do not check the protocol version of the encapsulation protocols.

<31> Section 3.4.5.1.1: The Office Groove Server 2007 and Groove Server 2010 relay servers do not validate that the URI contains a Relay-Server-Name that equals the local server name. The implementer is recommended to validate this field to ensure that the message was routed to the intended server.

<32> Section 3.4.5.1.1.2: Office Groove Server 2007 and Groove Server 2010 do not check the protocol version of the encapsulation protocols.

<33> Section 3.4.5.1.2: Office Groove Server 2007 and Groove Server 2010 do not check the protocol version of the encapsulation protocols.

<34> Section 3.4.5.1.2: The Office Groove Server 2007 and Groove Server 2010 relay servers do not validate that the URI contains a Relay-Server-Name that equals the local server name. The implementer is recommended to validate this field to ensure that the message was routed to the intended server.

<35> Section 3.4.5.2: Office Groove Server 2007 and Groove Server 2010 do not check the protocol version of the encapsulation protocols.

<36> Section 3.4.5.2: The Office Groove Server 2007 and Groove Server 2010 relay servers do not validate that the URI contains a Relay-Server-Name that equals the local server name. The implementer is recommended to validate this field to ensure that the message was routed to the intended server.

<37> Section 3.4.6.3: [1] The Office Groove Server 2007 and Groove Server 2010 implementations of SSTP [MS-GRVSSTP] assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommend behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<38> Section 3.5.1.1: To interoperate with Office Groove 2007 and SharePoint Workspace 2010, clients and servers need to support the Polling Connection idle connection back off algorithm. This value is sent by servers to clients on every POST response. The recommended behavior is that client implementations refresh the idle connection back off values on a per request/response basis.

<39> Section 3.5.1.1: To interoperate with Office Groove 2007 and SharePoint Workspace 2010, clients and servers need to support the Polling Connection idle connection back off algorithm. This value is sent by servers to clients on every POST response. The recommended behavior is that client implementations refresh the idle connection back off values on a per request/response basis.

<40> Section 3.5.1.1: To interoperate with Office Groove 2007 and SharePoint Workspace 2010, clients and servers need to support the Polling Connection idle connection back off algorithm. This value is sent by servers to clients on every POST response. The recommended behavior is that client implementations refresh the idle connection back off values on a per request/response basis.

<41> Section 3.5.1.2: Firewalls are generally transparent to clients. Clients need no configuration information to use a firewall, as firewalls perform routing at Layer 3 (Network Layer) of the OSI model, as specified in [ISO/IEC 7498-1:1994].

Proxies are not transparent to clients. Clients need to be configured with the proxy connection information (FQDN, PORT, Protocol) to be able to establish a connection with a proxy. The Office Groove 2007 and SharePoint Workspace 2010 clients use the proxy configuration information from a browser. The Office Groove 2007 and SharePoint Workspace 2010 clients can also access proxy auth-configuration or PAC files to get this information. In this case all that is needed is the proxy FQDN and Port Number. Therefore, the Office Groove 2007 and SharePoint Workspace 2010 clients do not actually store the proxy configuration persistently.

<42> Section 3.5.2.3: The default Polling-Virtual-Connection-Response-Message values sent by the server to the client on a Polling-POST-Response were empirically derived using many firewall and proxy vendor implementations.

In the Office Groove Server 2007 and Groove Server 2010 implementations, the default Poll Timer values used by Polling connections for polling servers for application data are:

Default server specified MaxPollInterval value is 120 seconds

Default server specified MinPollInterval value is 5 seconds

Default server specified PollRepetitions value is 3 iterations

The maximum MaxPollInterval value’s upper limit is determined by limits imposed by firewall and proxies on the maximum idle time for connections. Once the poll interval exceeds a proxy’s maximum idle timer value, the connection will be automatically closed by the proxy.

<43> Section 3.5.4.1: Firewalls are generally transparent to clients. Clients need no configuration information to use a firewall, as firewalls perform routing at Layer 3 (Network Layer) of the OSI model [ISO/IEC 7498-1:1994].

<44> Section 3.5.5.1.1.1: Office Groove 2007 and SharePoint Workspace 2010 do not check the protocol version of the encapsulation protocols.

<45> Section 3.5.5.1.1.1: The Office Groove Server 2007 and Groove Server 2010 relay servers do not validate that the URI contains a Relay-Server-Name that equals the local server name. The implementer is recommended to validate this field to ensure that the message was routed to the intended server.

<46> Section 3.5.5.1.1.2: Office Groove 2007 and SharePoint Workspace 2010 do not check the protocol version of the encapsulation protocols.

<47> Section 3.5.5.1.1.2: The Office Groove Server 2007 and Groove Server 2010 relay servers do not validate that the URI contains a Relay-Server-Name that equals the local server name. The implementer is recommended to validate this field to ensure that the message was routed to the intended server.

<48> Section 3.6.3.1: The Office Groove Server 2007 and Groove Server 2010 servers use a special purpose HTTP 1.0 protocol stack. Except for the subset of HTTP Request-Headers and Response-Headers specified in this document, all other HTTP Headers will be ignored as specified in the HTTP 1.0 [RFC1945] sections 5.2, 6.2 and 7.1.

<49> Section 3.6.5: Office Groove Server 2007 and Groove Server 2010 do not check the protocol version of the encapsulation protocols.

<50> Section 3.6.5: The Office Groove Server 2007 and Groove Server 2010 relay servers do not validate that the URI contains a Relay-Server-Name that equals the local server name. The implementer is recommended to validate this field to ensure that the message was routed to the intended server.

<51> Section 3.6.5.1: Office Groove Server 2007 and Groove Server 2010 do not check the Sequence Number on the Initial Handshake Request of the Polling Encapsulation protocol.

<52> Section 3.6.5.2.1: The Office Groove Server 2007 and Groove Server 2010 relay servers do not use load balancing algorithms to control the client's poll timer interval (see section 3.5.2.3). The PollingMinRepetitionInterval, PollingMinRepetitionInterval and PollingRepetitionCount state variable values are set during application initialization. The default values are specified in <21>.

<53> Section 3.7.1.2: Firewalls are generally transparent to clients. Clients need no configuration information to use a firewall, as firewalls perform routing at Layer 3 (Network Layer) of the OSI model, as specified in [ISO/IEC 7498-1:1994].

<54> Section 3.7.2.3: The Office Groove 2007 and SharePoint Workspace 2010 implementations of SSTP, as specified in [MS-GRVSSTP], assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommended behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<55> Section 3.7.4.1: Firewalls are generally transparent to clients. Clients need no configuration information to use a firewall, as firewalls perform routing at Layer 3 (Network Layer) of the OSI model [ISO/IEC 7498-1:1994].

<56> Section 3.7.6.3: The Office Groove 2007 and SharePoint Workspace 2010 implementations of SSTP, as specified in [MS-GRVSSTP], assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommend behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<57> Section 3.8.2.1: The Office Groove Server 2007 and Groove Server 2010 implementations of SSTP, as specified in [MS-GRVSSTP], assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore, the recommend behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<58> Section 3.8.2.1: The Office Groove 2007 and SharePoint Workspace 2010 clients’ HTTP Encapsulation implementation adjusts the SSTP protocol layer implementation’s default KeepAlive timer value. The HTTP Encapsulation layer overrides the SSTP default KeepAlive timer value, changing the default value of 5 minutes to 45 seconds. The default SSTP KeepAlive timer is modified to increase the frequency of the KeepAlive messages to help ensure that proxies do not treat the connections as idle and close them.

<59> Section 3.9.1.2: This proxy configuration information applies to Office Groove 2007 and SharePoint Workspace 2010.

<60> Section 3.9.1.2: Firewalls are generally transparent to clients. Clients need no configuration information to use a firewall, as firewalls perform routing at Layer 3 (Network Layer) of the OSI model [ISO/IEC 7498-1:1994].

<61> Section 3.9.2.3: The Office Groove 2007 and SharePoint Workspace 2010 implementations of SSTP as specified in [MS-GRVSSTP], assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore the recommend behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

<62> Section 3.9.4.1: Firewalls are generally transparent to clients. Clients need no configuration information to use a firewall, as firewalls perform routing at Layer 3 (Network Layer) of the OSI model [ISO/IEC 7498-1:1994].

<63> Section 3.9.4.1.1: The Office Groove 2007 and SharePoint Workspace 2010 clients support two SOCKS authentication methods: 0x00 (NO AUTHENTICATION REQUIRED) and 0x02 (USERNAME/PASSWORD). These two methods are represented by a sequence of two hex octets: [00 02]. The SharePoint Workspace 2010 client will not support the SOCKS protocol.

<64> Section 3.9.4.1.1: The Office Groove 2007 and SharePoint Workspace 2010 clients do not support GSSAPI.

<65> Section 3.9.5.1.1: The Office Groove 2007 and SharePoint Workspace 2010 clients do not support GSSAPI.

<66> Section 3.9.6.3: [1] The Office Groove 2007 and SharePoint Workspace 2010 implementations of SSTP, as specified in [MS-GRVSSTP], assist the HTTP encapsulation protocols by implementing KeepAlive semantics. SSTP's KeepAlive semantics are implemented using an SSTP_NOOP command. SSTP_NOOP commands are used to send SSTP ACKs over SSTP Connections. If there are no SSTP ACKs to send, SSTP sends an SSTP_NOOP command with a ACK count of 0. SSTP_NOOPs are sent at 45 second intervals. The SSTP default KeepAlive value of 5 minutes is overridden when SSTP is encapsulated. If HTTP Encapsulation of SSTP protocols is used to encapsulate non-SSTP data, then these non-SSTP protocols need to implement their own KeepAlive mechanisms, as the HTTP encapsulation protocols provide no KeepAlive semantics of their own. KeepAlive requests are important to HTTP encapsulation protocols used with proxy connections. Proxies can implement various timers to close idle proxy connections. Some firewalls and proxy implementations do not distinguish between proxy and non-proxy connections. Therefore, the recommend behavior is that encapsulated protocols always send a KeepAlive message when used with HTTP Encapsulation.

Share via

6 Appendix A: Product Behavior

Additional resources