Re: Discussion of Blob URI Scheme for Binary Data Access | IETF

* Arun Ranganathan wrote:
>We'd welcome your feedback, including suggestions about embarking upon 
>an IETF standardization track for this protocol.

Well there are all sorts of problems with your proposal (bulleted lists
with half a dozen of items do not belong in an Abstract, you list RFC
1738 as normative reference but the document does not seem to be refer-
enced at all, you mention "Data URLs that do not have media-types" which
cannot exist because there is a default if no media type is given, you
have a section on "Creating and Revoking a Blob URI" that does not say
why you would want to "revoke" a "Blob URI", this appears to be a W3C
technical report, but the latest published version seems to be over six
months old, and the version before that came about a year after the
previous draft, even though the W3C requires publication every three
months, the text for 'readAsArrayBuffer' is the same as the text for
other methods except for easily missed details, and so on and so forth).

However, as far as the HTTPbis Working Group goes, I do not see what we
could offer as feedback. What do you think someone who knows everything
about HTTP but not much else should comment on? Could you list some of
the issues where you are unsure you've made the right decision? Things
you feel are not optimal, not elegant? Why aren't you using one of the
many existing schemes? I don't mean to be overly critical, it's just
that you are essentially asking for help with the document, and I don't
see how this community in particular could help. Some insight into how
you are thinking about this proposal in relation to HTTP would help.

Generally speaking, in the IETF you find people who like to solve what
problems they encounter. Telling people about the problems you've found
and what pain you are trying to address is likely to generate the most
useful feedback (or pointers where to get that feedback from). If I were
to write your mail, I would start out saying "This is the goal, these
are the problems, these solutions came to mind but didn't meet the mark
because of problems such and such, so the idea is to have this which
solves the problems so and so".

That would enable people to point out things you've missed, criticise
the design, understand where you are coming from, give them an idea what
work has been done and what still needs to be done. It would also give
an idea of whether you feel you are past that, meaning it might be best
to focus, say, on how the methods are named, or point out performance or
usability problems in dealing with large or streamed data sets. You may
also just be looking for, say, whether the design or the details are in
some way objectionable from a HTTP perspective. How about XMLHttpRequest
for that matter? Is that relevant? Do you want to know about how this
new scheme interacts with existing HTTP frameworks?

The point is that from your message, "we" do not have much of a way to
connect to your thinking about the proposal, so "we" would largely be
drawing a blank when thinking about what feedback to provide.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Friday, 13 May 2011 03:56:21 UTC