Subject: Re: [alto] State of the WG

From: Wendy Roome <[email-masked]>
Date: Tue, 08 Mar 2016 09:14:51 -0500

A few points:

* The original proposal did not provide an explicit stop-updates request.
The server just pushed updates until the client closed the stream. Then
after implementing that, I discovered that it took a long time for the
server to discover that the client had closed the stream. That is why I
added stop-updates. At first that was just stop-everything; then it seemed
like a simple extension to allow the client to stop a subset of the
resources. If adding a control interface causes controversy, we could
drop stop-updates altogether.

* Delivering push-updates for multiple resources via one stream was only
partly to minimize the number of streams. The bigger reason is that cost
maps depend on network maps, and if the network map changes, the cost map
changes as well. It is easier for the client to handle those dependencies
if the server delivers updates for all those resources via a single
stream, in a predictable order.

* What would a two-channel approach look like? Remember the client must
send the stop-updates request via a new TCP stream, because SSE is not
bi-directional (the client cannot sen anything after the original request
parameters). So it seems to me that it already separates control from data.

* Because resources are identified by resource id, if a client wants
updates for N different ECS/EPS requests, the client must create N
different update-stream requests. Conceptually that is ugly. But if to
allow multiple ECS/EPS requests in one stream, we need a new identifier
for the specific request, which complicates the protocol. And I doubt many
clients will need that anyway. So that seemed like a premature
optimization.

     - Wendy Roome

>Message: 1
>Date: Sat, 5 Mar 2016 15:45:25 +0800
>From: Gao Kai <[email-masked]>
>To: Qiao Xiang <[email-masked]>, Jensen Zhang
>	<[email-masked]>
>Subject: Re: [alto] State of the WG
>
>Hiall,
>
>I'd like to share some of my thoughts on the
>draft-ietf-alto-incr-update-sse.
>
>There has been a debate on the options of "start-updates" and
>"stop-updates" and Wendy has already proposed some options.  I think
>since we need two channels, one for data and the other one for control,
>it is better to separate them explicitly.  Basically I would vote for
>option 3 but there are still a few details I'd like to discuss.
>
>One of the reasons that "start-updates" and "stop-updates" cannot be
>mixed together is that the draft allows one stream to push updates for
>several resources.  In my understanding, it is aimed to reduce the
>number of connections.  However, there is a constraint that requests are
>identified only by the their resource id which is the reason why it is
>difficult to add/modify resources.
>
>Consider a system-wide ALTO client, which can have multiple ECS/EPS
>requests with different parameters.  By allowing clients to label the
>requested parameters, we can provide better control functionality and
>also further reduce the number of active connections.
>
>Your thoughts and suggestions can highly appreciated.
>
>Regards,
>Kai
>
>On 29/02/16 06:26, Qiao Xiang wrote:
>>Hi All,
>>
>>The following are my comments on the draft-ietf-alto-incr-update-sse
>>draft.
>>
>>1. The last sentence of Paragraph 4 in Sec. 2 and the last sentence in
>>Sec. 6.5 use the same example. but the first one uses "should" and the
>>second one uses "SHOULD". I suggest capitalize the first one to make
>>the draft consistent.
>>
>>2. Section 6.6.3, "the that stream" -> "the same stream".
>>
>>3. Section 6.9, first sentence of Paragraph 1: "a line-at-a-time" ->
>>"one line-at-a-time" seems more appropriate.
>>
>>4. Section 6.9, second sentence of Paragraph 1: "of not tens of" ->
>>"if not tens of".
>>
>>5. Regarding the exclusion issue of "start-updates" and
>>"stop-updates", discussed by Hans, Wendy and Jensen, I am inclined to
>>vote for Wendy's option 3, i.e., using two separate request
>>"start-new-update-stream" and "modify-existing-update-stream".
>>
>>I will post to the group if I have any other comments. Thanks.
>>
>>
>>
>>Best
>>Qiao
>>

---

From: "Chenguohai (G Robert)" <[email-masked]>
Date: Wed, 9 Mar 2016 01:39:54 +0000

Hi all,

I would prefer to one TCP stream not two ones. Adding more communication TCP streams is just a burden for an ALTO server because all the control and data message are application processed.

BR
G.Robert  Chen
-------------------------------------------------------------------------------------------------------------------------------------
G.Robert  Chen (Chen Guohai  陈国海). Network Research Department, Huawei Technologies Co., Ltd. Telephone: 0086-25-56624606;   http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the  information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
----------------------------------------------------------------------------------------------------------------------------------------

-----Original Message-----
From: alto [mailto:[email-masked]] On Behalf Of Wendy Roome
Sent: Tuesday, March 08, 2016 10:15 PM
To: [email-masked]
Subject: Re: [alto] State of the WG

A few points:

* The original proposal did not provide an explicit stop-updates request.
The server just pushed updates until the client closed the stream. Then after implementing that, I discovered that it took a long time for the server to discover that the client had closed the stream. That is why I added stop-updates. At first that was just stop-everything; then it seemed like a simple extension to allow the client to stop a subset of the resources. If adding a control interface causes controversy, we could drop stop-updates altogether.

* Delivering push-updates for multiple resources via one stream was only partly to minimize the number of streams. The bigger reason is that cost maps depend on network maps, and if the network map changes, the cost map changes as well. It is easier for the client to handle those dependencies if the server delivers updates for all those resources via a single stream, in a predictable order.

* What would a two-channel approach look like? Remember the client must send the stop-updates request via a new TCP stream, because SSE is not bi-directional (the client cannot sen anything after the original request parameters). So it seems to me that it already separates control from data.

* Because resources are identified by resource id, if a client wants updates for N different ECS/EPS requests, the client must create N different update-stream requests. Conceptually that is ugly. But if to allow multiple ECS/EPS requests in one stream, we need a new identifier for the specific request, which complicates the protocol. And I doubt many clients will need that anyway. So that seemed like a premature optimization.

     - Wendy Roome

>number of connections.  However, there is a constraint that requests 
>are identified only by the their resource id which is the reason why it 
>is difficult to add/modify resources.
>

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: Gao Kai <[email-masked]>
Date: Wed, 9 Mar 2016 14:05:55 +0800

Hi Wendy and all,

Please see below.

> drop stop-updates altogether.
For simplicity, I agree on dropping the stop-updates.  And the stream-id
is also no longer needed with the removal of control interfaces.
> stream, in a predictable order.
Maybe we should make it explicit that only the cost map with its
dependent network map(s) can be pushed in one stream?
> parameters). So it seems to me that it already separates control from data.
Exactly.  That's why I think we should make it explicit that
"start-updates" is for data and "stop-updates" is for control, by
separating them like the third option you proposed in the discussion
with Hans.

I also suggest we use "get" instead of "start" for the data channel,
especially if we decide to drop "stop-updates".

Regards,
Kai

---

From: Wendy Roome <[email-masked]>
Date: Wed, 09 Mar 2016 13:51:19 -0500

I think it is still is useful to provide a mechanism to gracefully shutdown
an update stream. If the client just closes the stream (or crashes), the
server keep on sending updates for quite a while before the TCP stack times
out. This obviously eats up resources.

But I think it should be considerably simpler than the current draft. So how
about this approach:

* A server offers one or more update-stream resources. Each such resource
provides updates for a set of resources selected by the server. The client
request specifies a subset of those resources, and the server responds by
pushing updates to the client. This is the only type of request an
update-stream resource accepts, so we do not need to call it start-updates
or get-updates.

* We define another resource type, called close-stream, with a different
media-type. The client request is a list of stream-ids for active
update-streams. The server responds by closing its end of those streams. A
close-stream can close a stream obtained from any update-stream resource.
Hence a close-stream resource is not tied to a specific update-stream
resource, and a server does not need to offer more than one close-stream
resource.

I think that is simple & unambiguous. What does everyone think of that
modification?

- Wendy

From:  EXT Gao Kai <[email-masked]>
Date:  Wed, March 9, 2016 at 01:05
To:  Wendy Roome <[email-masked]>, <[email-masked]>
Subject:  Re: [alto] State of the WG

> drop stop-updates altogether.
For simplicity, I agree on dropping the stop-updates.  And the stream-id is
also no longer needed with the removal of control interfaces.

---

From: Wendy Roome <[email-masked]>
Date: Wed, 09 Mar 2016 14:26:27 -0500

That is a useful guideline, but I do not think it should be a strict
requirement. Right now, the only dependency is between a cost map & a
network map. But we have talked about other relationships, such as topology
or routing maps between PIDs. So I think the SSE update draft should be
general enough that it could be applied to new dependency relationships, and
those future relationships might result in more general graphs than the
rooted-tree of a network map and its cost maps.

Section 6.5 does recommend that the resource set for each update-stream
resource be closed under the dependency relationship. However, that allows a
server to define one update-stream for several network maps & their
dependent cost maps, while I think you are suggesting that each network map
(and its dependent cost maps) should have its own update-stream resource. We
could extend the recommendation by adding, ³and no subset  of the resource
set should be closed², which I think accomplishes what you suggested. But I
do not see how that would simplify either clients or servers.

- Wendy Roome

On 08/03/16 22:14, Wendy Roome wrote:
> partly to minimize the number of streams. The bigger reason is that cost maps
> depend on network maps, and if the network map changes, the cost map changes
> as well. It is easier for the client to handle those dependencies if the
> server delivers updates for all those resources via a single stream, in a
> predictable order.
Maybe we should make it explicit that only the cost map with its dependent
network map(s) can be pushed in one stream?

---

From: Gao Kai <[email-masked]>
Date: Thu, 10 Mar 2016 18:37:25 +0800

Here is how I think of pushing updates for multiple resources in one
streamand also explains why I'm not comfortable with the current design.

1. Can multiple resources be put in one stream?
Yes -> 2
NO -> I can live with this.  But as Wendy suggested, we still want to
make it easier for clients to handle dependencies.

2. Can arbitrary resources be put in one stream?
Yes/NO -> 3
NO -> What's the principle here then?  At the moment dependency (not
necessarily the binding of network map and cost map but it's the only
dependency defined by now) is the only principle that makes sense.

3. Do we allow closing a subset of resources in a stream?
Yes -> 4
NO -> I can live with this.

4. Can a client add resources to a stream then?
Yes -> That's what I prefer because if we support closing a subset, it
seems reasonable and natural to have the symmetric operation.  But we
might have to extend the protocol.
NO -> That's where we are and it really doesn't make any sense to me.

Regards,
Kai

On 10/03/16 03:26, Wendy Roome wrote:
> network map. But we have talked about other relationships, such as
> topology or routing maps between PIDs. So I think the SSE update draft
> should be general enough that it could be applied to new dependency
> relationships, and those future relationships might result in more
> general graphs than the rooted-tree of a network map and its cost maps.
>
> Section 6.5 does recommend that the resource set for each
> update-stream resource be closed under the dependency relationship.
> However, that allows a server to define one update-stream for several
> network maps & their dependent cost maps, while I think you are
> suggesting that each network map (and its dependent cost maps) should
> have its own update-stream resource. We could extend the
> recommendation by adding, “and no subset  of the resource set should
> be closed”, which I think accomplishes what you suggested. But I do
> not see how that would simplify either clients or servers.
>
> - Wendy Roome
>
> From: EXT Gao Kai <[email-masked]
> <mailto:[email-masked]>>
> To: Wendy Roome <[email-masked]
> <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>
>> * Delivering push-updates for multiple resources via one stream was
>> only partly to minimize the number of streams. The bigger reason is
>> that cost maps depend on network maps, and if the network map
>> changes, the cost map changes as well. It is easier for the client to
>> handle those dependencies if the server delivers updates for all
>> those resources via a single stream, in a predictable order.

---

From: Wendy Roome <[email-masked]>
Date: Thu, 10 Mar 2016 15:23:51 -0500

Kai,

Thanks for continuing the discussion. I¹ll summarize what I think you are
proposing; please correct me if I misunderstood you.

First, I think you would prefer that an ALTO server offer a single
update-stream resource, which handles updates for all resources, rather than
allowing a server to define N different update stream resources, each of
which handles a different subset of resources.

I think most servers will provide a single update-stream resource. I think
that is the simplest approach, and I would be happy to recommend that. But I
do not think we should require that. For one thing, we haven¹t done that for
other services. E.g., suppose a server provides ECS for 4 cost types. A
server can offer one ECS resource for all 4 cost types, and most servers
will do that. But we did not require that; a server can offer 4 different
ECS resources, with one cost type each, if the server wants.

Also, suppose an ALTO server has two different network maps: one is public,
and available to everyone, while the other is private, and only available to
authorized users. The private network map & cost maps use https and require
a client certificate. In this case the server needs two separate update
stream resources: a public one for updates to the public maps, and a private
one, which also requires a client certificate, for updates to the private
maps.

I believe your other suggestion is that a client should be able add or
remove resources for an existing stream. Eg, suppose a client creates an
update stream and initially requests updates for the network map and
routingcost, but not hopcount. I believe you would like to allow a client to
be able to add hopcount updates  to that existing stream at some later time,
without having to close the stream and create a new one.

II agree that is a logical extension. But it does complicate the protocol,
and I cannot think of a reason why a client would actually want to do that.
Can you come up with a use case where that helps?

- Wendy Roome

From:  EXT Gao Kai <[email-masked]>
Date:  Thu, March 10, 2016 at 05:37
To:  Wendy Roome <[email-masked]>, <[email-masked]>
Subject:  Re: [alto] State of the WG

Here is how I think of pushing updates for multiple resources in one stream
and also explains why I'm not comfortable with the current design.

1. Can multiple resources be put in one stream?
Yes -> 2
NO -> I can live with this.  But as Wendy suggested, we still want to make
it easier for clients to handle dependencies.

4. Can a client add resources to a stream then?
Yes -> That's what I prefer because if we support closing a subset, it seems
reasonable and natural to have the symmetric operation.  But we might have
to extend the protocol.
NO -> That's where we are and it really doesn't make any sense to me.

Regards,
Kai

---

From: Gao Kai <[email-masked]>
Date: Fri, 11 Mar 2016 10:23:23 +0800

On 11/03/16 04:23, Wendy Roome wrote:
> Kai,
>
> Thanks for continuing the discussion. I’ll summarize what I think you
> are proposing; please correct me if I misunderstood you.
>
> update-stream resource, which handles updates for all resources,
> rather than allowing a server to define N different update stream
> resources, each of which handles a different subset of resources.
>
> I think most servers will provide a single update-stream resource. I
> think that is the simplest approach, and I would be happy to recommend
> that. But I do not think we should require that. For one thing, we
> haven’t done that for other services. E.g., suppose a server provides
> ECS for 4 cost types. A server can offer one ECS resource for all 4
> cost types, and most servers will do that. But we did not require
> that; a server can offer 4 different ECS resources, with one cost type
> each, if the server wants.
>
> Also, suppose an ALTO server has two different network maps: one is
> public, and available to everyone, while the other is private, and
> only available to authorized users. The private network map & cost
> maps use https and require a client certificate. In this case the
> server needs two separate update stream resources: a public one for
> updates to the public maps, and a private one, which also requires a
> client certificate, for updates to the private maps.
>
Actually I have no problem with multiple update-stream resources. 
Instead I would like to allow a server to have multiple ones as you
suggested.

> remove resources for an existing stream. Eg, suppose a client creates
> an update stream and initially requests updates for the network map
> and routingcost, but not hopcount. I believe you would like to allow a
> client to be able to add hopcount updates  to that existing stream at
> some later time, without having to close the stream and create a new one.
>
> I agree that is a logical extension. But it does complicate the
> protocol, and I cannot think of a reason why a client would actually
> want to do that. Can you come up with a use case where that helps?
One intuitive reason is that if closing a subset of resources is
allowed, the symmetric behaviour - starting a subset of resources - (at
least for me) should be expected.

Consider a p2p client which downloads several files from different peer
groups and uses ECS to query the costs between each peer.  In the
current setting the client must use multiple persistent connections with
the ALTO server for incremental updates, which also consumes more
resources on both sides than a single connection.

Regards,
Kai

> stream and also explains why I'm not comfortable with the current design.
>

---

From: Wendy Roome <[email-masked]>
Date: Fri, 11 Mar 2016 13:38:22 -0500

Thanks!  Okay, I will outline a way to allow that. This uses the same basic
structure as the current proposal, but changes the plumbing around a bit.

* As in the current draft, the server defines one or more Update-Stream
resources, each of which covers a set of resource ids.

* To create an update stream, a client sends a Post request to an
Update-Stream resource. However, the client does NOT send any data with the
request.

* The server responds by sending an SSE event with a uri of a Stream Control
Resource. The client can send POST requests to that uri to control this
Update Stream. The uri would presumably contain an unique identifier for
this stream, but the mechanism is not specified.

* A client can send ADD, REMOVE, and SHUTDOWN commands on a Stream Control
resource. The client can send several commands in a single POST request.

* An ADD command tells the server to send update events for a new resource.
The command includes:

  + A unique request-id, chosen by the client (this is new).
  + The resource-id of the ALTO resource for which the client wants updates.
  + A boolean flag indicating whether the client will accept incremental
updates.
  + If resource-id is a tagged resource, the tag of the client's current
version.
  + If resource-id is POST-mode, the parameters for that request.

* The server includes the request-id in each SSE update event. This allows a
client use one Update Stream to get updates for several different ECS
requests (the original proposal did not allow that).

* A client should send one or more ADD commands immediately after receiving
the Stream Control URI from the server. If not, the server will close the
stream.

* A REMOVE command tells the server to stop sending updates for a previously
added resource. The command gives the request id. The server closes the
stream when the client removes the last request.

* For convenience, SHUTDOWN stops all updates and closes the stream.

* We might require a client to send a keep-alive request on the Control
resource every (say) 5 or 10 minutes, just to ensure the client is still
alive.

How do folks feel about this revision? It¹s different, but I don¹t think
it¹s any more complicated, or harder to implement & use, than the current
proposal.

- Wendy Roome

From:  EXT Gao Kai <[email-masked]>
Date:  Thu, March 10, 2016 at 21:23
To:  Wendy Roome <[email-masked]>, <[email-masked]>
Subject:  Re: [alto] State of the WG

> I believe your other suggestion is that a client should be able add or remove
> resources for an existing stream. Eg, suppose a client creates an update
> stream and initially requests updates for the network map and routingcost, but
> not hopcount. I believe you would like to allow a client to be able to add
> hopcount updates  to that existing stream at some later time, without having
> to close the stream and create a new one.
> 
> I agree that is a logical extension. But it does complicate the protocol, and
> I cannot think of a reason why a client would actually want to do that. Can
> you come up with a use case where that helps?
One intuitive reason is that if closing a subset of resources is allowed,
the symmetric behaviour - starting a subset of resources - (at least for me)
should be expected.

Consider a p2p client which downloads several files from different peer
groups and uses ECS to query the costs between each peer.  In the current
setting the client must use multiple persistent connections with the ALTO
server for incremental updates, which also consumes more resources on both
sides than a single connection.

Regards,
Kai

---

From: Gao Kai <[email-masked]>
Date: Sat, 12 Mar 2016 11:42:54 +0800

Ilike the new proposal.  Please see the inline comments.

On 12/03/16 02:38, Wendy Roome wrote:
> Thanks!  Okay, I will outline a way to allow that. This uses the same
> basic structure as the current proposal, but changes the plumbing
> around a bit.
>
> * As in the current draft, the server defines one or more
> Update-Stream resources, each of which covers a set of resource ids.
>
> Update-Stream resource. However, the client does NOT send any data
> with the request.
Is it possible to use GET if no input is required?  Or is POST used here
to allow future extensions?

>
> * The server responds by sending an SSE event with a uri of a Stream
> Control Resource. The client can send POST requests to that uri to
> control this Update Stream. The uri would presumably contain an unique
> identifier for this stream, but the mechanism is not specified.
>
> * A client can send ADD, REMOVE, and SHUTDOWN commands on a Stream
> Control resource. The client can send several commands in a single
> POST request. 
Maybe we should set up some rules here for processing the commands to
prevent arbitrary behaviours.  For example, some implementation might
process the commands in order but others may not; some preserve the
transaction semantic but others may not.

>
> * An ADD command tells the server to send update events for a new
> resource. The command includes:
>
>   + A boolean flag indicating whether the client will accept
> incremental updates.
>   + If resource-id is a tagged resource, the tag of the client's
> current version.
> * The server includes the request-id in each SSE update event. This
> allows a client use one Update Stream to get updates for several
> different ECS requests (the original proposal did not allow that).
>
> * A client should send one or more ADD commands immediately after
> receiving the Stream Control URI from the server. If not, the server
> will close the stream.
>
> * A REMOVE command tells the server to stop sending updates for a
> previously added resource. The command gives the request id. The
> server closes the stream when the client removes the last request.
>
> * We might require a client to send a keep-alive request on the
> Control resource every (say) 5 or 10 minutes, just to ensure the
> client is still alive.
>
> How do folks feel about this revision? It’s different, but I don’t
> think it’s any more complicated, or harder to implement & use, than
> the current proposal.
>
> - Wendy Roome
>
>> I believe your other suggestion is that a client should be able add
>> or remove resources for an existing stream. Eg, suppose a client
>> creates an update stream and initially requests updates for the
>> network map and routingcost, but not hopcount. I believe you would
>> like to allow a client to be able to add hopcount updates  to that
>> existing stream at some later time, without having to close the
>> stream and create a new one.
>>
> allowed, the symmetric behaviour - starting a subset of resources -
> (at least for me) should be expected.
>
> Consider a p2p client which downloads several files from different
> peer groups and uses ECS to query the costs between each peer.  In the
> current setting the client must use multiple persistent connections
> with the ALTO server for incremental updates, which also consumes more

---

From: Wendy Roome <[email-masked]>
Date: Tue, 22 Mar 2016 14:10:15 -0400

Kai,

1. The Create-Stream request must be POST, not GET. The ALTO server doesn¹t
care, but the HTTP protocol allows proxies to cache GET requests. Proxies
are not supposed to cache POST requests.

2. The control commands I defined don¹t really interact with each other, so
I don¹t think we need to define a processing order, other than to say that
the server should not close the stream unless there are no resources left
after all commands have been processed. Oh yes, SHUTDOWN should be the only
command in a request; there is no point in combining SHUTDOWN with anything
else.

Does everyone like this alternative? If so, I will update the draft.

- Wendy

From:  EXT Gao Kai <[email-masked]>
Date:  Fri, March 11, 2016 at 23:42
To:  Wendy Roome <[email-masked]>, <[email-masked]>
Subject:  Re: [alto] State of the WG

I like the new proposal.  Please see the inline comments.

> Update-Stream resource. However, the client does NOT send any data with the
Is it possible to use GET if no input is required?  Or is POST used here to
allow future extensions?

> Resource. The client can send POST requests to that uri to control this Update
> Stream. The uri would presumably contain an unique identifier for this stream,
> but the mechanism is not specified.
> 

> client use one Update Stream to get updates for several different ECS requests
> (the original proposal did not allow that).
> 
> added resource. The command gives the request id. The server closes the stream
> when the client removes the last request.
> 
> How do folks feel about this revision? It¹s different, but I don¹t think it¹s
> any more complicated, or harder to implement & use, than the current proposal.
> 
> - Wendy Roome
>

---

From: Gao Kai <[email-masked]>
Date: Thu, 24 Mar 2016 11:04:54 +0800

Wendy,

1. That makes perfect sense and thanks for the clarification.

2. Maybe it's just my paranoia but I feel worried about "what if someone
squash ADD/REMOVE for the same request-id in one request".  May I
suggest that we add a statement that this behaviour is undefined and
must be avoided?

Sorry for my obsession with these details...Thanks!

Regards,
Kai

On 23/03/16 02:10, Wendy Roome wrote:
> Kai,
>
> 1. The Create-Stream request must be POST, not GET. The ALTO server
> doesn’t care, but the HTTP protocol allows proxies to cache GET
> requests. Proxies are not supposed to cache POST requests.
>
> 2. The control commands I defined don’t really interact with each
> other, so I don’t think we need to define a processing order, other
> than to say that the server should not close the stream unless there
> are no resources left after all commands have been processed. Oh yes,
> SHUTDOWN should be the only command in a request; there is no point in
> combining SHUTDOWN with anything else.
>
> Is it possible to use GET if no input is required?  Or is POST used
> here to allow future extensions?
>
>>
>> control this Update Stream. The uri would presumably contain an
>> unique identifier for this stream, but the mechanism is not specified.
>>

---

From: Wendy Roome <[email-masked]>
Date: Thu, 24 Mar 2016 09:05:46 -0400

Kai,

It never occurred to me that someone might send an ADD & REMOVE for the same
id in the same control message. I¹ll make it clear that is illegal.

I¹ll try to revise the draft by Friday. Would you or anyone else like to
look it over before I officially post it as a new version?

- Wendy

From:  EXT Gao Kai <[email-masked]>
Date:  Wed, March 23, 2016 at 23:04
To:  Wendy Roome <[email-masked]>, <[email-masked]>
Subject:  Re: [alto] State of the WG

Wendy,

2. Maybe it's just my paranoia but I feel worried about "what if someone
squash ADD/REMOVE for the same request-id in one request".  May I suggest
that we add a statement that this behaviour is undefined and must be
avoided?

Regards,
Kai

On 23/03/16 02:10, Wendy Roome wrote:
> care, but the HTTP protocol allows proxies to cache GET requests. Proxies are
> not supposed to cache POST requests.
> 
> 2. The control commands I defined don¹t really interact with each other, so I
> don¹t think we need to define a processing order, other than to say that the
> server should not close the stream unless there are no resources left after
> all commands have been processed. Oh yes, SHUTDOWN should be the only command
> in a request; there is no point in combining SHUTDOWN with anything else.
>

---

From: Gao Kai <[email-masked]>
Date: Thu, 24 Mar 2016 21:14:17 +0800

Wendy,

I can look it over, say next Monday.  Meanwhile, it's better to have
someone else take a look too.  Maybe Hans and Jensensince they have
reviewed the draft before?

Regards,
Kai

On 24/03/16 21:05, Wendy Roome wrote:
> Kai,
>
> It never occurred to me that someone might send an ADD & REMOVE for
> the same id in the same control message. I’ll make it clear that is
> illegal.
>
> I’ll try to revise the draft by Friday. Would you or anyone else like
> to look it over before I officially post it as a new version?
>
> - Wendy
>
> 2. Maybe it's just my paranoia but I feel worried about "what if
> someone squash ADD/REMOVE for the same request-id in one request". 
> May I suggest that we add a statement that this behaviour is undefined
> and must be avoided?
>
>> SHUTDOWN should be the only command in a request; there is no point
>> in combining SHUTDOWN with anything else.
>>

---

From: Hans Seidel <[email-masked]>
Date: Tue, 29 Mar 2016 09:14:10 +0200

Wendy, Kai

Yes, I can look it over as well.

Hans

On 24.03.2016 14:14, Gao Kai wrote:
>> To: Wendy Roome <[email-masked]>, <[email-masked] 
>> <mailto:[email-masked]>>
>> May I suggest that we add a statement that this behaviour is 
>> undefined and must be avoided?
>>
>>> are no resources left after all commands have been processed. Oh 
>>> yes, SHUTDOWN should be the only command in a request; there is no 
>>> point in combining SHUTDOWN with anything else.
>>>