Re: proposed short-term changes to TCS


I think a basic principle is that there is a boundary over which the user has control.  For example, the server is clearly holding your IP address as long as  the TCP connection is open -- but either end can close it at any time.  Similarly in HTTP/2 the server might be pushing stuff after the exactly requested resource -- but the client can cancel the pushes or close the connection.

On Nov 14, 2013, at 2:14 , Mike O'Neill <> wrote:

> Hash: SHA1
> Candidate B in the CfO for Issue-5 refers to a network transaction, and clearly means a single request/response pair or at most a single request + its associated  responses  up to the end of any enclosing tcp connection.
> Mike
> From: Brad Kulick [] 
> Sent: 13 November 2013 18:01
> To: (
> Subject: Fwd: proposed short-term changes to TCS
> I believe this is the archived email that Roy was referencing on the call today. I have removed the parts non-relevant to the Network Transaction discussion. 
> - -brad
> Begin forwarded message:
> Resent-From: <>
> From: "Roy T. Fielding" <>
> Subject: proposed short-term changes to TCS
> Date: September 20, 2013 4:20:11 PM PDT
> To: " (" <>
> ...
> 2.3 Network Transaction
>  A network interaction is the set of HTTP requests and responses, or any
>  other sequence of logically related network traffic caused by a user visit
>  to a single web page or similar single action. Page re-loads, navigation,
>  and refreshing of content cause a new network interaction to commence.
> Section header does not match the defined term.  The defined term does
> not make any sense (a network interaction is any message).  The second
> sentence needs to be prefixed with "For example, ..."; and "Page re-load"
> is a subset of "refreshing of content".
> If we want to make requirements on any network interaction, then we
> should make them on any sent message, or use "network interaction"
> exclusively for single request/response pairs.
> If we want to make requirements on a set of network interactions that
> result from a single user action, then we should come up with a term
> for that (i.e., "user action").
> If we want to differentiate between a browser's initial resource
> request (initiated by user action) and the sequence of automated
> redirects and embedded subrequests that follow as a direct result
> of how the browser is instructed or configured to process the results
> of those interactions, then we should come up with specific terms
> for each of those things.  Note that those interactions are often
> caused by configuration outside the referring site's control, such
> as how the browser is implemented, what plug-ins have been installed,
> what proxies are defined, what accessibility options have been
> enabled, and so on; so, we might need to differentiate between
> subrequests caused by the user (i.e., "configured requests") and
> subrequests caused by content received as the result of an interaction
> that instructs the user agent (i.e., "embedded requests"). *phew*
> Cheers,
> Roy T. Fielding                     <>
> Senior Principal Scientist, Adobe   <>
> Version: GnuPG v1.4.13 (MingW32)
> Comment: Using gpg4o v3.1.107.3564 -
> Charset: utf-8
> POw1Fni950pGl/3eRjCvjal5b9W6L/2YvwW4MeovQa/VKtId2yPccKGG7/Wz4Stc
> N22yiwzWUPR64t0neiYbPvyvTmS4WpuLVB5Wzk5r9vq0ODY0x6PKBSQYTVRI7hWr
> z79EW6YM1anCpbKMD0bhmjI5lol8QVYeUNWrEG7uRoPWfHfL1SMVwSbEzjTEZRA9
> mtx+C2+AMJEKh3dCI2MkrqpHa076cwFfvfODh450CovbP7tL5VaiwoCQrzcwefsD
> VTmUPZdULH+Es4Ep1VpB+Cs5eIoqn1MgHI8eQBOFbebwC5qHca1EPagcgv36pdc=
> =Ylgj
> <PGPexch.htm><PGPexch.htm.sig>

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Thursday, 14 November 2013 01:05:09 UTC