Content negotiation and CDNs about ri-usecases

[ShaneHudson]

For this Use Case it might be worth referencing RFC 2295 which provides a technical overview of content negotiation.

[marcoscaceres]

@ShaneHudson thanks for the link. We should probably also check out HTTPBis as it's more updated.

[marcoscaceres]

@ShaneHudson so, after thinking about it, I think it would be safer just to point to the HTTP spec.

[marcoscaceres]

FYI, I've rewritten one of the requirements:

The solution MUST NOT require server-side processing or HTTP content negotiation.

I'll start on the use case now.

[lilith]

Also, I'd like to bring up the eBooks/ePub use case. EPUB closely tracks (X)HTML development, and has historically avoided 'extending' HTML markup specifications, although it has been freer with CSS.

By nature, an offline HTML file/archive or EPUB book doesn't support HTTP negotiation. Most offline readers do not support javascript either.

However, they are both in a challenging position when it comes to images, as readers often only support one image format (until recently, only PNG was supported by many readers), and many variants are needed to support the variety of screen types (e-ink, LCD) and resolutions (Think Kindle/Nook on iPad 3 vs Android).

I know I'm describing two different use cases here (offline HTML and EPUB), but they do share a lot. A good solution to responsive images will be of great benefit to both situations.

[igrigorik]

• RFC 2295 has one major flaw: it imposes a huge latency penalty by requiring an extra list response in the workflow.
• User-Agent techniques are a dead-end, and cannot adapt to dynamic use cases
• Client-side techniques have similar penalty (or worse) as RFC 2295

A work-in-progress, Client-Hints: https://docs.google.com/document/d/1xCtGvPbvVLacg45MWdAlLBnuWa7sJM1cEk1lI6nv--c/edit#

I would relax the language for "MUST NOT require server-side processing". The server is the origin, and given more information, it can do intelligent things and work well with intermediate caches. Granted, the Client-Hints proposal is independent of, and not limited to responsive images use cases.

[ddemaree]

The key word here is "require". Maybe the language can be clearer in this respect, but the point here is that a solution that requires server-side processing without the possibility of client-side negotiation is significantly less useful for people who are less handy on the server side than you or I, or who lack the budget to scale a server-side solution the way Google or Adobe can.

I don't think this language precludes using the server where appropriate, as an enhancement over the baseline spec.

On Oct 25, 2012, at 1:43 PM, Ilya Grigorik [email protected] wrote:

RFC 2295 has one major flaw: it imposes a huge latency penalty by requiring an extra list response in the workflow. - User-Agent techniques are a dead-end, and cannot adapt to dynamic use cases
Client-side techniques have similar penalty (or worse) as RFC 2295
A work-in-progress, Client-Hints: https://docs.google.com/document/d/1xCtGvPbvVLacg45MWdAlLBnuWa7sJM1cEk1lI6nv--c/edit#

I would relax the language for "MUST NOT require server-side processing". The server is the origin, and given more information, it can do intelligent things and work well with intermediate caches. Granted, the Client-Hints proposal is independent of, and not limited to responsive images use cases.

—
Reply to this email directly or view it on GitHub.

[marcoscaceres]

Agreed, the wording could probably be a little better (and agree with @ddemaree). I'm open to suggestions.

[igrigorik]

@ddemaree I want to dispel the myth that only Google or Adobe would be able to do server-side adaption. Just like srcset defines a well-known "2x" filename, nothing stops us from defining multiple filenames (via a convention, a configuration flag, or similar), for other variables: name-lw.jpeg vs. name-hw.jpeg for low-bandwidth, vs high-bandwidth. (may not be the best example, but you get the point). These files can be created at build / design time, and live on the server side-by-side. Nothing new here.

Re, language: right, I'm with you guys. I just want to make sure that when people read these use cases, they don't rule out the server-side adaption entirely. If the server supports it - great. But I agree that it can't be a required component.

Perhaps something like: The solution MUST NOT require server-side processing, but server-side adaptation may be used where available through or [HTTP11] content negotiation, or similar techniques.

[Wilto]

The solution MUST NOT require server-side processing, but server-side adaptation may be used where available through or [HTTP11] content negotiation, or similar techniques.

That seems fair to me. Would it make sense to expand it to something like:

The solution MUST NOT require server-side processing or HTTP content negotiation, but SHOULD NOT preclude the use of server-side adaptation and content negotiation.

Spec-writing is way outside of my wheelhouse; I’m not sure if the “SHOULD NOT” is appropriate here—just throwing that one out there.

[marcoscaceres]

How about:

The solution MUST NOT require server-side processing to work. However, if required, server-side adaptation can still be done through [HTTP11] content negotiation or similar techniques.

@Wilto, pro tip: in spec land, you can't ever have a MUST followed by a SHOULD.

[Wilto]

See that? I learned something today.

The solution MUST NOT require server-side processing to work. However, if required, server-side adaptation can still be done through [HTTP11] content negotiation or similar techniques.

Sold.

[marcoscaceres]

Ok, added it to the spec. Have not committed it yet.

@ddemaree, sorry I have not actually been able to articulate a full use case section around this yet. We were prioritising the launch of responsiveimages.org and preparing for presenting at TPAC next week :( However, it might be sufficient to just have the requirement and not a full use case description: content negotiation is understood to be a cataclysmic failure.

[igrigorik]

@marcoscaceres @Wilto looks good, thanks for the quick turnaround!

[MattWilcox]

I am very glad to see the Content Negotiation in like this. And very glad to learn about Client Hints, those are what I've been wanting for a long while :)

[marcoscaceres]

As we added the requirement, I'm closing this bug. Please reopen if you think we need to add anything else.