W3C home > Mailing lists > Public > public-html@w3.org > July 2012

Re: Updating Change Proposals for ISSUE-195 form-http-req

From: Cameron Jones <cmhjones@gmail.com>
Date: Wed, 25 Jul 2012 15:44:46 +0100
Message-ID: <CALGrgeswuZRa_jwcB4+pcC9vgjNrPxopkSWi_RVi2HxmvofNTw@mail.gmail.com>
To: Sam Ruby <rubys@intertwingly.net>
Cc: "public-html@w3.org WG" <public-html@w3.org>
On Sun, Jul 22, 2012 at 3:40 PM, Sam Ruby <rubys@intertwingly.net> wrote:
>
> Looking at the change proposal for 195:
>
>   http://www.w3.org/wiki/User:Cjones/ISSUE-195
>
> ... it seems to me that some of the same considerations that apply to the
> two most recent decisions may apply here.  In particular I encourage you to
> look at at the first bullet in "Revisiting this Issue" in the decision for
> issue-205[1].
>

Thanks for the feedback, i will proceed to revise the change proposal
with more supporting evidence. I hope and intend for this to be the
last major revision based on satisfying the remaining concerns. With
this being the case, i would like to summarize the prospective changes
to ensure that everything is covered and to welcome any intermediate
discussion or commentary.


1. The documentation of explicit end-user use cases will be added to
each of the itemized changes. This will effectively provide a greater
level of detail into the proposal's changes which at present document
the use cases as abstract language definitions which are applicable on
a universal level and to the more generic actor. These use cases will
be documented following more of a "case study" methodology, consisting
of the following:

    * Twitter-style simple status service illustrating the use case
for container-resource method semantics in web services
    * OLTP engine using idempotent PUT for client-controlled
commercial transactions with protocol integrity
    * CSRF identity tokens using HTTP headers for protocol-level
service integration
    * Automated HTML generation tools requirements for providing user
interaction without the need\ability to generate imperative
programming sequences - ie javascript & XHR
    * Users operating within a non-javascript environment ability to
interact with web sites otherwise only available through XHR

If these use cases are targeted at the incorrect level or are
otherwise insufficient or inappropriate to satisfy the concerns
further clarification is appreciated.


2. The XHR and CORS section was added for the current revision,
however this was limited in scope to the specific concerns over the
additional HTTP methods. I will rework this section and document all
known security vulnerabilities within the client environment together
with the protections against potential attack vectors. This will
provide the set of security constraints for scrutiny on a case-by-case
basis. This set of constraints will include: HTTP Methods, HTTP
Headers, HTTP Authentication, XSS, and CSRF.


3. The details section has previously been questioned over turgid
detail and the ease for editorial staff to carry out the changes.
Without changing the method of specifying the details i don't see how
the set of change instructions can be made more specific, as such I am
prepared to author the details as "Exact spec text for the sections to
be changed" against the current working draft. I expect this to be
mostly limited to the reworking of "4.10.22.3 Form submission
algorithm". This should provide the necessary baseline from which the
changes can be reviewed on single pass without ambiguity.

Due to the overlap in functionality between HTML forms and XHR there
is a required degree of similarity between the two processes. I have
previously deferred explicit specification of the HTML process to XHR
however my approach now will be to define a self-contained process for
HTML and maintain effective synchronicity between the two by way of
the specification of HTTP. Due to the larger scope for HTML over XHR i
expect this to be less restrictive by normative specification and lean
more heavily on the use of implementation notes and non-normative
requirements. In future, i might expect for the synchronicity between
two specifications to become spun out and integrated into a single
spec or otherwise maintained by reference.

Any feedback on this approach is most welcome.


4. The open concern of implementer interest is one that i can not
resolve independently. As the major vendors all have representation
within the working group, i can only apply the same reasoning that the
group normally takes when there in the absence of correspondence; that
lack of objection should be given greater weight that lack of
approval. I, of course, naturally maintain open invitation to vendors
to participate in the process of review and specification over the
proposal and am particularly keen at this point for any form of
interest or opinion.


Based on the approach and changes outlined above, i would like to
propose the 29th of August for the date of completion. This should
leave suitable time for review, straw poll and any minor changes prior
to TPAC which might be a useful contingency if there should be any
contentions which F2F is better at working through as a way of
reaching consensus.


Thanks,
Cameron Jones
Received on Wednesday, 25 July 2012 14:45:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 July 2012 14:45:21 GMT