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

Top posting as my suggestions are generic.

If including this in HTML5 and not in some subsequent version of the 
specification is important to you, I would suggest two things:

1) Provide first hand descriptions of user requirements.  Don't simply 
describe second-hand a "twitter-style" service that hypothetically could 
make use of the proposal that you describe; actually get input from 
Twitter itself (Twitter clearly being an example here, substitute as 
required).  For best results, get a statement that they would make use 
of the feature if it were provided.  Ideally get them to provide 
quantification in any form you/they see fit as to what the value is.

2) Don't include anything in your proposal that isn't specifically in 
response to the requirements that you have gathered.  Background on 
this: if you identify 8 things in your proposal and somebody object to 
the 5th thing for whatever reason, the chairs will generally not attempt 
to create a proposal on your behalf that gerrymanders around that 
specific problem.  Instead, you are encouraged to work with others 
before hand to identify and address problems and build consensus before 
we get to the point of a survey.

- Sam Ruby

On 07/25/2012 10:44 AM, Cameron Jones wrote:
> On Sun, Jul 22, 2012 at 3:40 PM, Sam Ruby <> wrote:
>> Looking at the change proposal for 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 " 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 21:13:14 UTC