DASH/XMPP workshop

I've been asked to pass along information relating to a workshop that a
non-subscriber to this list thinks would be of interest to you.  The
topic is on MPEG and session management, and it will take place on the
28th of July in Vienna.  The MPEG consortium is the host.  One of the
goals is to bring together folk who participate in various standards
organizations, as well as operators and others, to take a fresh look at
session management and control.  There's an obvious tie-in here to
multiple streams in a single tcp connection, which is why you might be
interested.  Anyway, more information can be found
at
http://multimediacommunication.blogspot.co.at/2013/05/mpeg-workshop-on-session-management-and.html. 
Please unicast queries about this to abegen@... if you are
interested.  Sorry it got to you late.

Questions on Frame Size

Hi,

The issues about frame size were discussed and might had some
agreements at SF interium but please let me ask some questions on the
current spec of "3.3.2 Frame Size" which is updated by
https://github.com/http2/http2-spec/commit/fd703b572cfc527582c0716e59f2c4044ae195a8

1. "For instance, individual DATA and HEADERS frames used to express
HTTP request and response messages (see Section 4) are not permitted
to exceed 16,383 octets of payload."

PUSH_PROMISE is not listed.
Is the data size of PUSH_PROMISE also limited to 16K or is it exceptional
for some reason?

2. "The absolute maximum amount of payload data any individual frame
 can contain is 65,535 octets. All implementations SHOULD be capable
 of receiving and minimally processing frames up to this size."

If PUSH_PROMISE has a 16K limit, the max frame size is still 64K,
however, any other frames besides DATA, HEADERS and PUSH_PROMISE
are only several octets at most.

Is it for the future extension not to change the frame length to 14bit?
If so, why the spec requires all implementations to support the 64K frame
 size only for the future extension?

Regards,

END_STREAM on PUSH_PROMISE

Just going through things... in the current HEAD, we say that
PUSH_PROMISE can contain a END_PUSH_PROMISE for use with
continuations. No other flags are defined. Do we need END_STREAM on
PUSH_PROMISE?

There are two approaches if we want to send a stream that has no
actual DATA, but includes a HEADERS and a PUSH_PROMISE.

1. We send a HEADERS then a PUSH_PROMISE with END_STREAM set... or

2. We send a HEADERS, a PUSH_PROMISE, and an empty DATA with length 0
and END_STREAM set.

Either approach works, it just needs to be clear.

Design: Adding ASSOCIATED_ONLY

https://github.com/http2/http2-spec/pull/144

This was a technical change brought up and discussed as part of the
"layering taskforce" breakout but was never discussed in the larger
interim discussions.

Essentially, this PR would add an "ASSOCIATED_ONLY" flag to PRIORITY
and RST_STREAM frames that would allow terminating and reprioritizing
promised streams as a group.

Sending PRIORITY(ASSOCIATED_ONLY) would ONLY set the priority for
associated streams, not the referenced stream.

Sending RST_STREAM(ASSOCIATED_ONLY) would terminate ONLY the
associated streams, not the referenced stream.

Without this, we would have to send PRIORITY and RST_STREAM for each
individual associated stream, which is obviously quite inefficient.

Fwd: Nit: Server-sent priority

Accidentally sent this only to Martin.

Looks like James and I had the same answer.

---------- Forwarded message ----------
From: Mike Belshe <mike-rQ7FgXjfSifQT0dZR+AlfA@public.gmane.org>
Date: Tue, Jun 18, 2013 at 5:09 PM
Subject: Re: Nit: Server-sent priority
To: Martin Thomson <martin.thomson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Tue, Jun 18, 2013 at 3:42 PM, Martin Thomson <martin.thomson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

We discussed the possibility that a server could send PRIORITY (either
in its own frame or attached to HEADERS).  The idea was that the
server could advise a client about the priority that it is applying,
which might be different to the priority that a client requested.

I am not sure how the client would use this information.

The intent of priority was to indicate what order you'd like the other side to process the streams.  If its a full-duplex stream (not likely HTTP), the server and client can each assign a different priority to the other side.

They're just independent.

 

This adds a challenge for clients: does the client now provide updated
priorities that are relative to the priorities that it sent
previously, or relative to the priority that the server has indicated?

Indeed confusing - more reason not to do this

 

e.g., client sends three requests, priority 7, 10 and 15.  Server
responds and indicates priorities of 3, 5 and 7.  If the client wants
to issue a new request that is higher priority than the lowest
priority existing request, does it indicate a priority of between 10
and 15?  Or does it indicate a priority of 6?

10< pri <15 

This editor wants to know.  I think that the easiest approach would be
to stipulate that the priorities spaces are independent and that
client priorities are only relative to client priorities.
Unfortunately, that means that I need to include the example above as
well.

 

I don't want to prohibit servers from sending priority, because I
believe that it could be useful for a client to understand how
priority is being applied.

I'm not sure how the client would use that information - dynamically adjust?  This seems like a non-use case.

Mike

Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

https://github.com/http2/http2-spec/issues/140

Currently, we have the FRAME_TOO_LARGE error code...

However, it's possible that a frame can be under-sized. For instance,
a PING frame with less than 8-bytes of payload. We don't have a good
symmetrical approach to handling both over, and undersized frames. One
suggestion is to remove FRAME_TOO_LARGE entirely and just use
PROTOCOL_ERROR but that loses value, I think. Having specific error
codes is a good thing at times. Changing to FRAME_SIZE_ERROR allows us
to deal easily with over and undersized frames symmetrically.

Nit: Server-sent priority

We discussed the possibility that a server could send PRIORITY (either
in its own frame or attached to HEADERS).  The idea was that the
server could advise a client about the priority that it is applying,
which might be different to the priority that a client requested.

This adds a challenge for clients: does the client now provide updated
priorities that are relative to the priorities that it sent
previously, or relative to the priority that the server has indicated?

e.g., client sends three requests, priority 7, 10 and 15.  Server
responds and indicates priorities of 3, 5 and 7.  If the client wants
to issue a new request that is higher priority than the lowest
priority existing request, does it indicate a priority of between 10
and 15?  Or does it indicate a priority of 6?

This editor wants to know.  I think that the easiest approach would be
to stipulate that the priorities spaces are independent and that
client priorities are only relative to client priorities.
Unfortunately, that means that I need to include the example above as
well.

I don't want to prohibit servers from sending priority, because I
believe that it could be useful for a client to understand how
priority is being applied.

GOAWAY(AND_DONT_COME_BACK)

Multiple Headers

Issue re. HTTP2 STREAM and HEADER block use same end bit polarity

This issue:

https://github.com/http2/http2-spec/issues/129

describes my concern that the polarity is reversed between STREAM FINAL
and HEADER CONTINUES which are both flag bits used to manage continuation.

I think this will introduce confusion to folks analyzing wire level bits
as well as reading code.

I do acknowledge the the current flag names match the sense of the 
polarity so the names probably should change.

Dave Morris

Until HTTP header when the representation will disappear in the future

Hi, 

I was wondering if people had already imagined a mechanism to warn about the decay, or the non persistence of
a URI. No bikeshed yet about the name let's call it "zardoz" instead of "Valid-until".

Let's say a document will be obsolete for legal reasons, contests, sunsetting Web sites or APIs, etc. after
midnight on June 24 and I want to say to user agent that it will be 410 Gone after this date and/or a temporary
redirect will be finished at a precise date (maintenance for example).

→ http HEAD http://example.org/

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=600
Content-Length: 34322
Content-Type: text/html; charset=utf-8
Date: Wed, 12 Jun 2013 05:36:14 GMT
Last-Modified: Tue, 11 Jun 2013 21:57:50 GMT
Zardoz: Wed, 24 Jun 2013 23:59:59 GMT

Is there already a way to do this that I would have missed. 
The semantics of Expire is not exactly the same.

--

-- 
Karl Dubost
http://www.la-grange.net/karl/