https://www.w3.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=CjonesW3C Wiki - User contributions [en]2024-03-29T14:11:31ZUser contributionsMediaWiki 1.41.0https://www.w3.org/wiki/index.php?title=User:Cjones&diff=85061User:Cjones2015-07-16T12:41:20Z<p>Cjones: /* Change Proposals */</p>
<hr />
<div>= Cameron Jones =<br />
<br />
Contact: [mailto:cmhjones@gmail.com cmhjones@gmail.com]<br />
<br />
== Change Proposals ==<br />
<br />
* ISSUE-183: Drop the &lt;time&gt; element [http://www.w3.org/wiki/User:Cjones/ISSUE-183]<br />
* ISSUE-184: Enhance the &lt;data&gt; element with a type system [http://www.w3.org/wiki/User:Cjones/ISSUE-184]<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/wiki/User:Cjones/ISSUE-195]<br />
* ISSUE-196: No change for User Agent HTTP response handling behaviour [http://www.w3.org/wiki/User:Cjones/ISSUE-196]</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-195&diff=60361User:Cjones/ISSUE-1952012-08-16T18:38:29Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-195: Enhance HTTP request generation from forms =<br />
<br />
== Summary ==<br />
<br />
This is the proposal for the enhancement of forms in integration with the HTTP protocol and the ability for forms to generate entire requests through declarative HTML markup, without requiring Javascript. This proposal includes the following set of changes:<br />
<br />
* Form can initiate any protocol request method<br />
* Submittable elements can bind to protocol action, headers or body request payload<br />
* Output element enabled for form submission allowing clients to send the results of UI calculations in a request<br />
* Declare HTTP authentication within forms enabling custom login\logout forms using standard input controls<br />
<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The HTML Working Group is chartered to deliver HTML5 as ''"A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web"''. With HTTP being the transfer protocol of the web and with forms being the semantic markup of protocol interaction for users, completing integration with the protocol is one of the core deliverables for HTML5 and one of the progressive enhancements to the language for the benefit of the largest numbers of users, authors and developers.<br />
<br />
The support for the additional HTTP methods "PUT" and "DELETE" was introduced in HTML5 to cater for the demand from authors to declare interaction with web services which leverage the guarantees and protections afforded to different method semantics. The initial specification of this functionality did not address the necessity to be able to control protocol mechanisms such as ETags for these methods to be useful. This resulted in the opening of a bug report questioning the removal of this functionality citing a lack of workable use cases.<br />
<br />
This proposal is the culmination of the subsequent research and development of the working group into the requirements and necessitive design of the solution as constrained by maintaining logical compatibility with HTML4 and with strict adherence to the specification of HTTP, HTTP Authentication and with reference to XmlHttpRequest which has enabled the benefits of protocol integration for the Javascript environment.<br />
<br />
=== Use Cases ===<br />
<br />
The primary use case supporting the enhancement of forms is to enable declarative capture and control of protocol request representations. The benefits of providing this support can be seen by examining the requirements of the different actors within HTML.<br />
<br />
The principal actor is the end-user who interacts with HTML through User Agent software which provides the environment for dereferencing URIs and rendering the retrieved representations. Users have a choice of agent software based on their host environment, abilities, or preference which includes the category of User Agent defined within the HTML conformance classes as "User agent with no scripting support". This category of User Agent is limited in its operational capacity, either by implementation or configuration, to only providing a static representation of HTML documents and only providing state transitions through the request of declarativly defined links or form requests. Users operating this class of agent software can only be serviced through the inclusion of declarative controls for defining HTTP protocol representations. Without this support these users would be unable to use web sites which utilize the additional HTTP methods initiated through HTML. <br />
<br />
User agent software may additionally be implemented, or configured through user preference, to restrict the use of HTTP cookies. This is a common configuration option by users who choose to operate an environment exhibiting greater security and privacy by means of the elimination of secondary functionality and the potential threats which these can incur. The impact of this is that these users are unable to be serviced with the use of HTTP cookies as a common means for implementing site login and session control. The HTTP protocol provides mechanisms for authentication through the use of specialized HTTP headers which are managed by the User Agent. This functionality is currently implemented within User Agents as native "popup" notification dialogs which request sensitive information and have proven to be difficult for users to trust due to the historic overuse of popups for advertising or other non-desirable user interaction. This has lead to the overwhelming use of HTTP cookies for authentication and session control as an application-defined protocol and implemented within the site's pages using standard form controls and styled within their user experience. The introduction of declarative controls for initiating HTTP authentication provides access support for users operating in non-cookie environments and provides web sites with the ability to utilize HTTP authentication without incurring a jarring user experience.<br />
<br />
The HTTP protocol includes the state changing methods PUT and DELETE which are defined as idempotent operations providing guarantees to their operational effect. The implementation of forms within HTML4 does not include these methods and so all state changing operations are implemented by applications through the POST method. The impact of this to end-users is that any state-changing operation they perform can not be intelligently interfaced by User Agents, this manifests itself currently within browsers through the idiosyncratic behavior when users navigate using browser back or forward buttons, or in web sites which provide transactions which may have unintended consequences if submitted multiple times, in these situations popups warn the uninformed user of potential hazards. These scenarios are avoided through the appropriate use of the idempotent HTTP methods which contain the relevant information for their effect to be predicted over time and frequency alleviating users from error conditions and having to make uninformed decisions arising from low level technical details. <br />
<br />
The use cases of HTML authors provide additional requirements on the specification of HTML and the constraints of perceived or practical authorability. With HTML being a declarative language it affords a programming language based on capturing and representing intent and is at a significantly higher level than that of Javascript and imperative programming languages which require a far greater level of intrinsic knowledge and syntactical expressional constraints. The ability for people with little or no programming experience to be able to author HTML documents with web site interaction without needing to know any Javascript is a significant advantage to producing functional and error-free applications and allows these users to learn or be taught HTML as a natural advancement from preliminary desktop publishing. The simplicity of declarative HTTP and MAILTO processing schemes affords these authors the ability to advance their abilities into the protocol level of interaction with web sites and internet operation. The exposure to this level of control, jumping the Javascript and imperative programming constraints, is a significant step for the advancement of the World Wide Web within educational institutions and alleviates the cognitive load which otherwise limits web programming to the technical elite.<br />
<br />
The simplicity of the computational requirements for the authorability of HTML not only serves human authoring and educational use cases but also the needs of automated document generation and service interaction. The predominant method for the production of HTML documents is through the use of server-side "templating" technologies which augment base HTML documents with additional processing instructions which, when combined with request input or database entries, provide dynamically generated HTML documents. The tools which provide this functionality are based on the processing and output of the HTML language and the greater functionality that can be represented within this language as declarative expressions represents a significant benefit to the ease of production of server-side HTML. The alternative of requiring Javascript for the declaration of protocol and service interaction has far limited tooling support, is more error prone, and requires an operational environment for testing the integrity of generated code. Compare this with HTML which can be statically analyzed for integrity and does not require the construction of complex working memory and sequential and combinatorial execution of programming statements.<br />
<br />
=== Form Method ===<br />
<br />
<br />
*The form @method attribute is extended to allow any value as the name of the HTTP request method, with the exception of the following list of explicitly prohibited blacklist methods: <br />
<br />
CONNECT, TRACE, TRACK<br />
<br />
<br />
This allows authors to declare user interaction with web services which use the different HTTP/1.1 methods to manipulate resources. The HTTP protocol includes the methods "PUT" and "DELETE" which are idempotent and impose guarantees that multiple identical requests will have the same effect as a single request. This protocol feature is the essential network programming paradigm of optimistic locking which solves the problem of coordinating resource modification in distributed systems which asynchronously alter remote state. As with any layered system, it is possible to replicate this functionality within a higher layer, however these implementations are application specific and need to be designed and implemented for each new application within the layer and forgoes the benefits that come with a lower-level implementation and the reduction of complexity of the layered deferment of responsibility.<br />
<br />
The extension of the @method attribute does not limit the values which may be entered to only those methods defined in HTTP/1.1 allowing extensions and new protocols to be integrated within HTML without need for additional specification. This benefits the HTML language by removing the need for the set of allowable methods to be controlled and administered by the working group and allows innovation to proceed unencumbered from the process of specification publication and implementation. This directly benefits the communities of users who have extended HTTP for additional use cases, for example the "PATCH" extension which is used for partial resource modification where an otherwise identical request would have a different consequence.<br />
<br />
The blacklist of prohibited methods is added as a security mechanism to protect users from initiating HTTP requests which are incompatible or insecure for a HTML client. The "TRACE" and "TRACK" methods are used in HTTP for debugging protocol requests and echo otherwise restricted protocol information back to the client as response content which is accessible from Javascript. <br />
<br />
=== Payload Binding ===<br />
<br />
<br />
*The @payload attribute is added to each of the submittable elements:<br />
<br />
button<br />
input<br />
keygen<br />
object<br />
select<br />
textarea<br />
<br />
*The @payload attribute consists of a set of enumerated values for targeting different areas of the generated request:<br />
<br />
_action<br />
_header<br />
_body<br />
<br />
<br />
This attribute enables declarative configuration of the entire request through any submittable element. Without this support the types of requests which are capable of being constructed by forms is limited to either exclusively binding all values to the action URI as a set of query parameters for GET requests, or binding all the values within the request's body for POST requests. This is a limitation of the declarative expressiveness of forms and the ability for authors to declare interaction with web services which utilize HTTP headers or alternate combinations of URI and body request configurations.<br />
<br />
The ability to configure HTTP headers is a primary requirement for supporting the semantics of the state changing idempotent HTTP methods. These methods use HTTP headers for communicating the version of the resource as an optimistic lock token for concurrency control. This provides in-built protocol protection for end users against the risk of concurrent modification which is an inherent problem for any stateless communication protocol.<br />
<br />
The design of the @payload attribute has been found thorough investigation of the requirements and analysis of the potential solutions. A number of alternatives were considered which initially proposed to deliver the goal of providing declarative HTTP headers, however all of which have failed to solve the issue and offer the kind of expressiveness and functionality as exhibited in the final design. Each of the following alternatives was considered and resolutely thrown out for being incapable of supporting a primary use case: <br />
<br />
*Form attributes for headers names<br />
**Too many and requires explicit specification<br />
<br />
*Form attribute @header-* <br />
**Not integrated with user input or other submittable elements<br />
<br />
*Input name="__header__"<br />
**Entire header name\value pair would need to be captured within the input @value attribute <br />
<br />
*Input type="header"<br />
**Can not capture different input types, eg: number, time, url <br />
<br />
The final solution uses a new attribute which is added to each of the submittable elements. This allows any submittable element to target any area of the request and especially benefits the requirements of web services which use unique tokens for session identification or validating the authenticity of requests, for example CSRF tokens. The implementations of these tokens can take the form of URI query parameters, HTTP headers, or encoded body parameters, however without adequate payload request binding the ability to implement these solutions invariably causes contentions in system design through the exclusivity of HTML4 request binding.<br />
<br />
The introduction of the @payload attribute has additionally been deliberated with the alternative potential of providing the additional functionality within the existing @target attribute on submission elements. At first there appears a good semantic fit between the attribute name and the 'targeting' of different areas of the request, and as the scope for @target is restricted to forms and 'submit' inputs\buttons for referring to reserved or named browsing contexts, there would appear to be no overlap in functionality. All that would be required is the extension of the @target attribute to allow the additional reserved payload names. However, as it would be valid for a submit button to both declare the target context of the response and configure the payload of the button name in the request, the attribute definition would need to be extended to a multi-value text attribute with the resulting additional complexity that this would introduce. For this reason, and to leave open scope for extension to either the @payload or @target attributes in future, the chosen implementation for this functionality is the new attribute.<br />
<br />
=== Submittable &lt;output&gt; ===<br />
<br />
<br />
*The &lt;output&gt; element is added as a submittable form element.<br />
<br />
<br />
The &lt;output&gt; element represents dynamic calculations over &lt;input&gt; and &lt;output&gt; values controlled by the client. These values must be available to be sent to the server otherwise there is a direct coupling between the client and server; the server would have to have pre-existing knowledge of the exact algorithm used by the request's client to be able to acquire the same result. This is brittle and does not cater for the scenario where there are multiple or 3rd party client implementations which communicate with a common web service.<br />
<br />
The results of <output> are also useful in constructing a value from multiple or complex input sources. The value may be programmatically defined and then bound to target the request payload, for example:<br />
<br />
<pre><br />
<form oninput="elements['VND.ExampleInc.foo'].value = a.value + '; ' + parseFloat(b.value)"><br />
<br />
<label>Text</label><br />
<input type="text" name="a"/><br />
<br />
<label>Range</label><br />
<input type="range" name="b" min="0" max="1" step="0.1"/><br />
<br />
<label>Result</label><br />
<output name="VND.ExampleInc.foo" payload="_header"/><br />
<br />
<button type="submit">Submit</button><br />
</form><br />
</pre><br />
<br />
In order to generate the following HTTP header from user input:<br />
<br />
<pre><br />
VND.ExampleInc.foo: SomeText; 0.1<br />
</pre><br />
<br />
=== HTTP Authentication ===<br />
<br />
<br />
*The form control fields "_user_" and "_password_" representative of the named parameters to the XHR "open()" method are added for declarative HTTP authentication using form inputs.<br />
<br />
*The "_logout_" form control field is added for clearing an origin's HTTP authentication on successful completion of the form request.<br />
<br />
<br />
HTTP Authentication has been traditionally provided within HTML browsers through native platform support whereby if a request is issued which requires authentication the browser initiates native UI controls allowing the user to enter their login credentials and resend the initial request. This has several drawbacks as the interface for supplying credentials is outside the control of the web site and can not be styled or customized which creates a jarring user experience and has proven to be difficult for users to understand and trust. Once a user has initiated HTTP authentication on a site there is currently no method available by either declarative or imperative programming for a site to clear the browser's authentication cache which is applied to requests to the site. This lack of 'logout' support leaves users with open authentication for the lifetime of their browser application denying an essential use case and potentially exposing the user to additional risk of CSRF attacks.<br />
<br />
The primary requirement for remedying these shortcomings and improving security on the web is for HTML to control the initiation and scope of authentication. The solution must allow for credentials to be supplied using form input controls to allow for sensitive data to be captured using password fields. The solution must also allow these credentials to be potentially captured and applied for any request, as these are the semantics of HTTP authentication as controlled through the application of HTTP headers and valid for inclusion on any request. <br />
<br />
The method for delivering this functionality is by extension of the set of form control fields to include the new reserved names outlined above. Form control fields are used within HTML to declare customizations to the form submission process applied by the browser. Existing control fields are "_charset_" and "_isindex_" which redefine the submission process by configuring the character encoding or form data set respectively. This behavior is aligned with the functionality required for supporting protocol authentication as a form submission customization and, as credential information is not sent in the payload of the request, using special input names is not restrictive and serves to protect authors against inadvertently leaking sensitive data.<br />
<br />
The "_logout_" form control field is also used to control the form submission process. This reserved name may be applied to an input control to declare that the browser should clear the origin's authentication cache on a successful response from the server. When constructing and sending the request the browser applies any existing authentication state within the request so that the server has knowledge of which user the request is from and can clean up any remote session-based state it may be retaining. This is strictly not required by the HTTP protocol or HTTP authentication which are stateless, however there are practical benefits to retaining some state across requests on a server and the request notification also serves to remove any session-style cookies from subsequent client requests. The authentication cache is only cleared by the browser on a successful response to cater for potential error conditions originating from either the client or the server and to allow the site to define the location and content of the response.<br />
<br />
=== Form Submission ===<br />
<br />
<br />
*The form submission process is defined by the resolved scheme of the form's action<br />
<br />
*The form action URI is constructed through applying all submission elements with resolved payload "_action" <br />
<br />
*The form header set is constructed through applying all submission elements with resolved payload "_header" <br />
<br />
*The form data set is constructed through applying all submission elements with resolved payload "_body" <br />
<br />
*The mailto scheme algorithm is upgraded to allow configuration of action, headers and body<br />
<br />
*The javascript and ftp schemes are not supported due to lack of use cases<br />
<br />
<br />
The form submission process is required to be updated in order to support the logic of the declarative controls. The existing process currently attempts to force all protocol interaction in forms to either a logical "GET" or "POST" operation. This exhibits the most basic support for any state-changing protocol in reducing the mode of operation into either 'read' or 'write' operations, however the only supported protocol which this can even apply to is HTTP. The current approach of defining a method-based switch over the submission process is flawed in its attempt to define a HTML-only protocol abstraction layer. <br />
<br />
The "mailto" and "data" schemes both serve a single purpose which is the capture and construction of a request representation. Due to the lack of expressiveness for controlling the form data set, the "mailto" scheme is defined to switch the construction set to configuring either the mailto headers or the body based on the resolved @method state. This switch has no semantic meaning and does not make sense when the method of operation remains the same. The "data" scheme is also defined with alternate operation based on the state of the @method attribute, this operation is defined as either a navigation to the action URI for a "GET" method, or as the construction of the URI from the form data set which the browsing context is then navigated to. The mode of operation for "GET" methods serves no purpose as the only form attribute used in the resulting request is the unmutated @action attribute.<br />
<br />
The schemes "javascript" and "ftp" both also suffer from this lack of functional capability. These two schemes only support the "GET" method and neither of them constructs any data set representing a request. The ability to navigate to ftp or javascript URIs is possible through standard HTML anchors which satisfy the use cases for their access.<br />
<br />
The form submission algorithm is therefore changed to be defined more naturally by the scheme of the resolved form @action URI. This eliminates the confusion arising from the re-purposing of an otherwise distinct attribute definition. This simplifies the process itself by keeping protocol specific behavior defined within an independent algorithm which is free to define the logic required.<br />
<br />
=== XHR, CSRF and CORS ===<br />
<br />
The design of HTML5 forms stems from the same requirements which spurred the creation of the XmlHttpRequest Javascript interface for providing access to the HTTP protocol. When XHR was introduced to the browser environment the background operation of the scripts together with DOM access and the shared 'ambient authority' of authentication and cookies within browsers combined to open new security vulnerabilities for normal web users. At the time, this resulted in a large amount of FUD around the causes of the vulnerabilities and the protections required to mitigate against these new risks.<br />
<br />
The Cross-Origin Resource Sharing (CORS) specification has been developed in answer to the need for the World Wide Web to operate the way it was designed. This allows any site to link to and define interaction with any other site on the web and to make that interaction available for users. The need and implementation of this are irrespective to the definition of HTML forms and this proposal does not introduce a requirement mandating the support of XHR, CORS, HTTP Authentication, HTTP Cookies or any other specification. <br />
<br />
The specification of HTML does not impose requirements on implementations to support other specifications or mandate the inclusion of secondary features. This may not be immediately obvious when the primary audience is the main browser vendors that implement their products as the combination of multiple web specifications and internet protocols which inter-operate to provide a highly integrated operational environment. However, the scope of HTML is limited by a separation of concerns and this separation serves to allow for the simplest implementation to be a conformant one and without assumptions as to how it operates or what purpose it serves.<br />
<br />
For example, we can look to the use cases of public access terminals to provide validation. These implementations provide a client environment for public access where user interaction is a potential threat from the perspective of the service provider. By implementing a simple HTML client which does not run Javascript, does not have multiple tabs, does not support HTTP authentication, does not support HTTP cookies, this provider is capable of supplying a product which is fully conformant with the HTML specification and guaranteed the level of support defined but without the additional risks and complexity involved with such a combined solution.<br />
<br />
It is for these reasons that this proposal does not introduce new dependencies or unduely constrain the required operation of implementations. Vendors are free to define the standards and specifications which their products support and are free to choose which combinations of these provide the environment for serving their target user base.<br />
<br />
=== Counter-Proposal Responses ===<br />
<br />
The following is the set of responses documenting the answers to concerns raised by the issue's counter proposal.<br />
<br />
==== Lack of Provided Use Cases ====<br />
<br />
''...does not give use cases for each HTTP verb it proposes to allow in method="" ''<br />
<br />
The ability to control request generation is defined to be unlimited in what methods may be used and how the payload is constructed. This retains the expressiveness of HTML as a language and affords to authors the lack of restriction imposed by the HTTP protocol. While certain combinations of methods, headers and body content may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of flexibility is what enables specifications to be the most widely applicable and of most use to the largest amounts of users and use-cases and fosters an environment where innovation is possible and possibility is realized.<br />
<br />
We can see the explicit need for supporting the additional HTTP verbs from both the stated demand of the community and the resulting workaround and hacks which have been implemented in order to circumvent their omission. These workarounds take the form of using a "X-HTTP-Method-Override" attribute as either a HTTP header or hidden form field which triggers the alternate processing semantics within the web service. As noted within the rationale above, while these workarounds allow for the methods to be triggered, they do so without support on the protocol level effectively eliminating their practical usefulness.<br />
<br />
''...but theoretical purity is at the bottom of our Priority of Constituencies. ''<br />
<br />
The main beneficiaries of these enhancements are end users, authors and developers who are protected and empowered with the exposure to the transfer protocol of the web for the technological benefits, guarantees and protections the protocol affords. This represents real practical gains over what is currently possible.<br />
<br />
The perception of puritanical motives for these enhancements is no doubt sourced from the many active debates arising from recent revisiting of the ReSTful architectural style which was used in the design of the World Wide Web. This debate has little to do with HTTP and is more the concerned with the application of the style itself to the architecture and design of systems implemented on top of the protocol. <br />
<br />
As we refer to the HTML Design Principles themselves, it should be noted that the changes proposed herein demand the attention and weight of highest order due to the costs and difficulties their omission would otherwise cause: <br />
<br />
''In case of conflict, consider users over authors over implementers over specifiers over theoretical <br />
''purity. In other words costs or difficulties to the user should be given more weight than costs to <br />
''authors; which in turn should be given more weight than costs to implementers; which should be given <br />
''more weight than costs to authors of the spec itself, which should be given more weight than those <br />
''proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for <br />
''multiple constituencies at once.''<br />
<br />
==== Complexity of Change ====<br />
<br />
''The Enhance HTTP request generation from forms Change Proposal describes a complex set of features to <br />
''be added to HTML forms. It's hard to get these details right; Gecko had an implementation of PUT and <br />
''DELETE for <form> that was pulled just before the release of Firefox 4 due to this.''<br />
<br />
The set of changes contained herein represent the results of critical review over the specification of forms from the expert domain knowledge of architects and designers of HTTP web services. While the changes included may appear to be complex, they represent the<br />
reduction of the problem down to the core set of requirements necessary for satisfying these needs. With the requirements for specification being defined by HTTP, there exists the clear and immutable set of constraints for specification to occur and for implementations to be tested. <br />
<br />
The implementation of PUT and DELETE within Gecko has been the source of validation from calls for the removal of these methods. If we look into the [https://bugzilla.mozilla.org/show_bug.cgi?id=583288 bug report] however we see that the broken implementation was around the handling of HTTP redirects, also affecting any requests generated from XHR. There is a misconception that there is additional complexity in handling requests based on what generated the request, this is a fallacy. It is equally possible for forms and XHR to generate identical requests and the resulting responses are mandated within HTTP to be processed identically by the UA as any identical representation would.<br />
<br />
The changes to the form submission algorithm represent the only source of complexity within this proposal, and that complexity is limited with impact only to browser implementers. The new form methods, payload attribute and authentication control fields are all simple element and attribute definitions which do not consist of confusing behavior changes or overt dependencies on sibling elements. On the contrary, the simplicity of the design allows the new element definitions to complement one another resulting in conceptually simple and powerful declarative expression.<br />
<br />
The complexity within the submission algorithm is solely based on the HTML4 implementation of HTTP request binding for GET and POST methods. This binding is based on the resolved form method to target the action or body of the request with form parameters. With the introduction of payload binding configuration this algorithm is naturally extended, however the need to maintain backwards compatibility with HTML4 documents and to support the default semantics of HTTP require the form's method to be used to define the default binding for elements which lack an explicit deceleration. This takes the form of providing a special form submission condition for implementations and represents the greatest complexity introduced by this proposal and that which is irreducible.<br />
<br />
==== Lack of UA Implementor Interest ====<br />
<br />
''A solicitation of UA implementor interest from the Editor has gone unanswered for a month. Moreover, the spec<br />
''allowed PUT and DELETE in <form method> for years. They were dropped after the failed Gecko implementation<br />
''mentioned above.''<br />
<br />
The solicitation for UA implementor interest was posed by the editor and remains unanswered. This not only shows a lack of positive interest but also a lack of negative objection and no conclusions can be drawn from such silence. Given that when PUT and DELETE were within the specification there were initial implementations happening within Gecko, this indicates that there is interest by some vendors to support these users.<br />
<br />
The design of these changes is modeled on existing operation available within XHR and does not introduce any new functionality not in this interface. For these changes to be implemented the form is logically required to be 'mapped' into the same data structure as provided through XHR. This is a simple and limited programmatic task and given the convergence of these two input structures into a single protocol call this is expected and designed such that implementations can refactor and combine these inputs into a single programming construct.<br />
<br />
== Details ==<br />
<br />
=== Form Method ===<br />
<br />
* Update the valid state for "method" and "formmethod" content attributes to be any value excluding the HTTP methods defined by the following enumerated blacklist:<br />
<br />
CONNECT, TRACE, TRACK<br />
<br />
=== Payload Binding ===<br />
<br />
* Add "payload" as a new content attribute to each of the submittable elements defined in section "4.10.2 Categories"<br />
<br />
* Add the restriction of state of the "payload" content attribute to one of the following enumerated values: <br />
<br />
_action, _header, _body<br />
<br />
=== Submittable <output> ===<br />
<br />
* Add the &lt;output&gt; element to the list of submittable elements and enable it for inclusion in the construction of the form request set<br />
<br />
=== HTTP Authentication ===<br />
<br />
* Add the following special values to the list of restricted values for form element's "name" attribute in section "4.10.19.1 Naming form controls":<br />
<br />
_user_, _password_, _logout_<br />
<br />
* Add the definition of the "_user_" special form control on a Text control as the value and behavior of the XHR authentication parameter "user"<br />
<br />
* Add the definition of the "_password_" special form control on a Password control as the value and behavior of the XHR authentication parameter "password"<br />
<br />
* Add the definition of the "_logout_" special form control as the value to require the UA to clear site authentication on successful response.<br />
<br />
=== Form Submission Process ===<br />
<br />
* Remove the definition of the FTP and Javascript schemes from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of these scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
==== Form Data Set Construction ====<br />
<br />
* Add the “disabled” content attribute to the &lt;object&gt; and &lt;output&gt; elements and retain its state and operation as defined for the other submittable elements where the value represent by the element is excluded from the set of submittable form elements.<br />
<br />
* Update the form submission algorithm by specifying the state of the "action" to be the resolved URL with the additional parameters to the process as the submittable form elements whose "payload" attribute is resolved to the value "_action" or with unset attribute and the resolved HTTP method state of HEAD, GET, OPTIONS or DELETE.<br />
<br />
* Update the form submission algorithm by specifying the state of the "request headers" to be the set of submittable form elements whose "payload" attribute is resolved to the value "_header".<br />
<br />
* Update the form submission algorithm by specifying the state of the "form data" to be the set of submittable form elements whose "payload" attribute is resolved to the value "_body" or with an unset attribute and the resolved HTTP method state of PUT, POST, PATCH or unknown method.<br />
<br />
* Update the form submission algorithm by removing the scheme method abstraction table and replacing it with a scheme switch to sections defining the specific set of processing instructions<br />
<br />
==== HTTP(S) Scheme Submission Process ====<br />
<br />
* Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:<br />
<br />
# For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters<br />
# For the set of elements resolved with the payload "_header" apply the set of name\value pairs as HTTP author request headers with the same definition as described in XHR<br />
# For the set of elements resolved with the payload "_body" encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described in XHR<br />
# If there exists a form element corresponding to the special control "_user_" or "_password_" then these values must be applied to the request as with the same definition described in XHR<br />
# Construct and send the request using the HTTP(S) method defined by the submitter element's resolved "method" attribute state.<br />
# If there exists a form element corresponding to the special control "_logout_" and the response to the request is a 2xx success code then the agent must clear the site's authentication cache for subsequent requests.<br />
<br />
==== Data Scheme Submission Process ====<br />
<br />
* Add the definition of the data scheme processing instruction set as defined by the following process:<br />
<br />
# For the set of elements with the payload attribute "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described by "Post to data:".<br />
<br />
==== Mailto Scheme Submission Process ====<br />
<br />
* Add the definition of the mailto scheme processing instruction set as defined by the following process:<br />
<br />
# For the set of elements with the payload "_action" encode the set of fields by concatenating them together using the semi-colon ";" deliminator and append to the action URI.<br />
# For the set of elements with the payload "_header" encode the set of fields using the "application/x-www-form-urlencoded" encoding algorithm and append to the action URI with the question mark "?" character.<br />
# For the set of elements with the payload "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply to the end of the action URI with the prefix of "body="<br />
# Navigate the target browsing context to destination represented by the action<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
==== Form Method ====<br />
<br />
* Declarative specification of HTTP web services within the HTML language<br />
* Enables HTTP web services for scriptless clients and environments<br />
* Simpler visible programming, comprehension, documentation and education of HTTP web services and forms<br />
* Correct use of HTTP without tunneling through the non-semantic and non-idempotent POST method<br />
* Greater functionality in form submission attributes on buttons for customizing the data set with alternate request parameters<br />
<br />
==== Payload Binding ====<br />
<br />
* Allows the flexibility to specify any and all aspects of the request for any method<br />
* Maintains backwards-compatibility with existing HTML4 forms and HTTP method conventions<br />
* Allows query parameters for PUT and POST for resource targeting and non-representational intent<br />
* Allows GET or other action methods to include embedded digital keys for capability-based security<br />
* &lt;input&gt; and &lt;output&gt; elements can define header fields configured using any input type, validation or calculation<br />
* Headers allow for complete request representations by including protocol or custom headers which are essential aspects of action and intent<br />
* Headers support the essential semantics of idempotent methods<br />
* Headers support additional response negotiation through techniques such as "Prefer" headers<br />
* Enables scope for further innovation over the protocol which is increasing using headers as a representational state mechanism<br />
* Use of underscore prefix "_" for payload states uses the familiar conventions of browser context targeting while also retaining scope for further specification possibly in integration with UriTemplates or other name-based templating technologies<br />
* Mailto forms can construct messages with multiple recipients and have full control over all email headers and the body contents without limitation from intent tunneling through HTTP methods names<br />
* All submittable elements have a “disabled” state allowing explicit exclusion of values used by documents for user communication or input capture from being mandatory in the request or generated "data:" representations<br />
<br />
==== Submittable &lt;output&gt; Element ====<br />
<br />
* Client-side calculations do not need to be dependent on identical server-side implementations which otherwise introduce client-server coupling<br />
* Calculations over user inputs can be applied to construct complex header values<br />
* Decouples input capture from data use or representation<br />
<br />
==== HTTP Authentication ====<br />
<br />
* Form control fields re-use existing conventions for triggering custom User Agent request-generation behavior <br />
* HTTP Authentication in forms bypasses the unfriendly browser popups and allows site controlled, familiar and flexible CSS user interfaces<br />
* Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache with server notification<br />
<br />
=== Negative Effects ===<br />
<br />
* The introduction of payload targeting introduces a more complex form request generation algorithm for implementors, however backward compatibility is maintained and there is explicit provisioning for the reduction of implementation code through refactoring<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance defined through the the application of changes in the "Details" section<br />
<br />
* HTTP Authentication is non-required conformance on implementations<br />
<br />
* FTP and Javascript schemes are non-required conformance form actions<br />
<br />
=== Risks ===<br />
<br />
* Additional HTTP methods introduce new security risks from non-script environments. As the new functionality exposed is currently available within XHR it does not introduce any new security risks that are not already available within scripted environments. As the new request generation features enable greater expression of requests, any new security risks would be limited to server processing, which is also already available to XHR contexts. As the responses from servers are still processed within a non-script environment there is no further risk introduced to the client with processing the response.<br />
<br />
* Forms may attempt to override User-Agent controlled headers. To mitigate this, the same black-listed headers may be applied by User Agents as with requests from XHR.<br />
<br />
* Nefarious scripts may alter the state of <output> element's value violating the calculations the server was expecting to be applied. Since the nefarious script already has access to DOM the vulnerabilities would not be limited to this and as such are a secondary attack vector resulting from a prior security breach.<br />
<br />
* Existing documents may use the special form control names introduced with this proposal. This may risk unexpected behavior being triggered by the User Agent prior to the request being sent or post response. This should be mitigated by implementers by restricting the application of new form control fields to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.<br />
<br />
== Acknowledgements ==<br />
<br />
Acknowledgements and thanks go to the following people for their efforts which have contributed to this proposal: <br />
<br />
*Julian Reschke<br />
*Mike Amundsen<br />
*Dave Kok<br />
*Ian Hickson<br />
*Anne Van Kesteren<br />
*Ted O'Connor<br />
*HTML WG Chairs: Sam Ruby, Paul Cotton &amp; Maciej Stachowiak<br />
<br />
== References ==<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/html/wg/tracker/issues/195]<br />
<br />
* XMLHttpRequest [http://www.w3.org/TR/XMLHttpRequest]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.txt]<br />
<br />
* HTTP Authentication: Basic and Digest Access Authentication [http://www.ietf.org/rfc/rfc2617.txt]<br />
<br />
* Gecko Bug 583288 - Authorize PUT and DELETE methods for form submission [https://bugzilla.mozilla.org/show_bug.cgi?id=583288]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-195&diff=60360User:Cjones/ISSUE-1952012-08-16T16:59:03Z<p>Cjones: Updated Change Proposal for WG Survey</p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-195: Enhance HTTP request generation from forms =<br />
<br />
== Summary ==<br />
<br />
This is the proposal for the enhancement of forms in integration with the HTTP protocol and the ability for forms to generate entire requests through declarative HTML markup, without requiring Javascript. This proposal includes the following set of changes:<br />
<br />
* Form can initiate any protocol request method<br />
* Submittable elements can bind to protocol action, headers or body request payload<br />
* Output element enabled for form submission allowing clients to send the results of UI calculations in a request<br />
* Declare HTTP authentication within forms enabling custom login\logout forms using standard input controls<br />
<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The HTML Working Group is chartered to deliver HTML5 as ''"A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web"''. With HTTP being the transfer protocol of the web and with forms being the semantic markup of protocol interaction for users, completing integration with the protocol is one of the core deliverables for HTML5 and one of the progressive enhancements to the language for the benefit of the largest numbers of users, authors and developers.<br />
<br />
The support for the additional HTTP methods "PUT" and "DELETE" was introduced in HTML5 to cater for the demand from authors to declare interaction with web services which leverage the guarantees and protections afforded to different method semantics. The initial specification of this functionality did not address the necessity to be able to control protocol mechanisms such as ETags for these methods to be useful. This resulted in the opening of a bug report questioning the removal of this functionality citing a lack of workable use cases.<br />
<br />
This proposal is the culmination of the subsequent research and development of the working group into the requirements and necessitive design of the solution as constrained by maintaining logical compatibility with HTML4 and with strict adherence to the specification of HTTP, HTTP Authentication and with reference to XmlHttpRequest which has enabled the benefits of protocol integration for the Javascript environment.<br />
<br />
=== Use Cases ===<br />
<br />
The primary use case supporting the enhancement of forms is to enable declarative capture and control of protocol request representations. The benefits of providing this support can be seen by examining the requirements of the different actors within HTML.<br />
<br />
The principal actor is the end-user who interacts with HTML through User Agent software which provides the environment for dereferencing URIs and rendering the retrieved representations. Users have a choice of agent software based on their host environment, abilities, or preference which includes the category of User Agent defined within the HTML conformance classes as "User agent with no scripting support". This category of User Agent is limited in its operational capacity, either by implementation or configuration, to only providing a static representation of HTML documents and only providing state transitions through the request of declarativly defined links or form requests. Users operating this class of agent software can only be serviced through the inclusion of declarative controls for defining HTTP protocol representations. Without this support these users would be unable to use web sites which utilize the additional HTTP methods initiated through HTML. <br />
<br />
User agent software may additionally be implemented, or configured through user preference, to restrict the use of HTTP cookies. This is a common configuration option by users who choose to operate an environment exhibiting greater security and privacy by means of the elimination of secondary functionality and the potential threats which these can incur. The impact of this is that these users are unable to be serviced with the use of HTTP cookies as a common means for implementing site login and session control. The HTTP protocol provides mechanisms for authentication through the use of specialized HTTP headers which are managed by the User Agent. This functionality is currently implemented within User Agents as native "popup" notification dialogs which request sensitive information and have proven to be difficult for users to trust due to the historic overuse of popups for advertising or other non-desirable user interaction. This has lead to the overwhelming use of HTTP cookies for authentication and session control as an application-defined protocol and implemented within the site's pages using standard form controls and styled within their user experience. The introduction of declarative controls for initiating HTTP authentication provides access support for users operating in non-cookie environments and provides web sites with the ability to utilize HTTP authentication without incurring a jarring user experience.<br />
<br />
The HTTP protocol includes the state changing methods PUT and DELETE which are defined as idempotent operations providing guarantees to their operational effect. The implementation of forms within HTML4 does not include these methods and so all state changing operations are implemented by applications through the POST method. The impact of this to end-users is that any state-changing operation they perform can not be intelligently interfaced by User Agents, this manifests itself currently within browsers through the idiosyncratic behavior when users navigate using browser back or forward buttons, or in web sites which provide transactions which may have unintended consequences if submitted multiple times, in these situations popups warn the uninformed user of potential hazards. These scenarios are avoided through the appropriate use of the idempotent HTTP methods which contain the relevant information for their effect to be predicted over time and frequency alleviating users from error conditions and having to make uninformed decisions arising from low level technical details. <br />
<br />
The use cases of HTML authors provide additional requirements on the specification of HTML and the constraints of perceived or practical authorability. With HTML being a declarative language it affords a programming language based on capturing and representing intent and is at a significantly higher level than that of Javascript and imperative programming languages which require a far greater level of intrinsic knowledge and syntactical expressional constraints. The ability for people with little or no programming experience to be able to author HTML documents with web site interaction without needing to know any Javascript is a significant advantage to producing functional and error-free applications and allows these users to learn or be taught HTML as a natural advancement from preliminary desktop publishing. The simplicity of declarative HTTP and MAILTO processing schemes affords these authors the ability to advance their abilities into the protocol level of interaction with web sites and internet operation. The exposure to this level of control, jumping the Javascript and imperative programming constraints, is a significant step for the advancement of the World Wide Web within educational institutions and alleviates the cognitive load which otherwise limits web programming to the technical elite.<br />
<br />
The simplicity of the computational requirements for the authorability of HTML not only serves human authoring and educational use cases but also the needs of automated document generation and service interaction. The predominant method for the production of HTML documents is through the use of server-side "templating" technologies which augment base HTML documents with additional processing instructions which, when combined with request input or database entries, provide dynamically generated HTML documents. The tools which provide this functionality are based on the processing and output of the HTML language and the greater functionality that can be represented within this language as declarative expressions represents a significant benefit to the ease of production of server-side HTML. The alternative of requiring Javascript for the declaration of protocol and service interaction has far limited tooling support, is more error prone, and requires an operational environment for testing the integrity of generated code. Compare this with HTML which can be statically analyzed for integrity and does not require the construction of complex working memory and sequential and combinatorial execution of programming statements.<br />
<br />
=== Form Method ===<br />
<br />
<br />
*The form @method attribute is extended to allow any value as the name of the HTTP request method, with the exception of the following list of explicitly prohibited blacklist methods: <br />
<br />
CONNECT, TRACE, TRACK<br />
<br />
<br />
This allows authors to declare user interaction with web services which use the different HTTP/1.1 methods to manipulate resources. The HTTP protocol includes the methods "PUT" and "DELETE" which are idempotent and impose guarantees that multiple identical requests will have the same effect as a single request. This protocol feature is the essential network programming paradigm of optimistic locking which solves the problem of coordinating resource modification in distributed systems which asynchronously alter remote state. As with any layered system, it is possible to replicate this functionality within a higher layer, however these implementations are application specific and need to be designed and implemented for each new application within the layer and forgoes the benefits that come with a lower-level implementation and the reduction of complexity of the layered deferment of responsibility.<br />
<br />
The extension of the @method attribute does not limit the values which may be entered to only those methods defined in HTTP/1.1 allowing extensions and new protocols to be integrated within HTML without need for additional specification. This benefits the HTML language by removing the need for the set of allowable methods to be controlled and administered by the working group and allows innovation to proceed unencumbered from the process of specification publication and implementation. This directly benefits the communities of users who have extended HTTP for additional use cases, for example the "PATCH" extension which is used for partial resource modification where an otherwise identical request would have a different consequence.<br />
<br />
The blacklist of prohibited methods is added as a security mechanism to protect users from initiating HTTP requests which are incompatible or insecure for a HTML client. The "TRACE" and "TRACK" methods are used in HTTP for debugging protocol requests and echo otherwise restricted protocol information back to the client as response content which is accessible from Javascript. <br />
<br />
=== Payload Binding ===<br />
<br />
<br />
*The @payload attribute is added to each of the submittable elements:<br />
<br />
button<br />
input<br />
keygen<br />
object<br />
select<br />
textarea<br />
<br />
*The @payload attribute consists of a set of enumerated values for targeting different areas of the generated request:<br />
<br />
_action<br />
_header<br />
_body<br />
<br />
<br />
This attribute enables declarative configuration of the entire request through any submittable element. Without this support the types of requests which are capable of being constructed by forms is limited to either exclusively binding all values to the action URI as a set of query parameters for GET requests, or binding all the values within the request's body for POST requests. This is a limitation of the declarative expressiveness of forms and the ability for authors to declare interaction with web services which utilize HTTP headers or alternate combinations of URI and body request configurations.<br />
<br />
The ability to configure HTTP headers is a primary requirement for supporting the semantics of the state changing idempotent HTTP methods. These methods use HTTP headers for communicating the version of the resource as an optimistic lock token for concurrency control. This provides in-built protocol protection for end users against the risk of concurrent modification which is an inherent problem for any stateless communication protocol.<br />
<br />
The design of the @payload attribute has been found thorough investigation of the requirements and analysis of the potential solutions. A number of alternatives were considered which initially proposed to deliver the goal of providing declarative HTTP headers, however all of which have failed to solve the issue and offer the kind of expressiveness and functionality as exhibited in the final design. Each of the following alternatives was considered and resolutely thrown out for being incapable of supporting a primary use case: <br />
<br />
*Form attributes for headers names<br />
**Too many and requires explicit specification<br />
<br />
*Form attribute @header-* <br />
**Not integrated with user input or other submittable elements<br />
<br />
*Input name="__header__"<br />
**Entire header name\value pair would need to be captured within the input @value attribute <br />
<br />
*Input type="header"<br />
**Can not capture different input types, eg: number, time, url <br />
<br />
The final solution uses a new attribute which is added to each of the submittable elements. This allows any submittable element to target any area of the request and especially benefits the requirements of web services which use unique tokens for session identification or validating the authenticity of requests, for example CSRF tokens. The implementations of these tokens can take the form of URI query parameters, HTTP headers, or encoded body parameters, however without adequate payload request binding the ability to implement these solutions invariably causes contentions in system design through the exclusivity of HTML4 request binding.<br />
<br />
The introduction of the @payload attribute has additionally been deliberated with the alternative potential of providing the additional functionality within the existing @target attribute on submission elements. At first there appears a good semantic fit between the attribute name and the 'targeting' of different areas of the request, and as the scope for @target is restricted to forms and 'submit' inputs\buttons for referring to reserved or named browsing contexts, there would appear to be no overlap in functionality. All that would be required is the extension of the @target attribute to allow the additional reserved payload names. However, as it would be valid for a submit button to both declare the target context of the response and configure the payload of the button name in the request, the attribute definition would need to be extended to a multi-value text attribute with the resulting additional complexity that this would introduce. For this reason, and to leave open scope for extension to either the @payload or @target attributes in future, the chosen implementation for this functionality is the new attribute.<br />
<br />
=== Submittable &lt;output&gt; ===<br />
<br />
<br />
*The &lt;output&gt; element is added as a submittable form element.<br />
<br />
<br />
The &lt;output&gt; element represents dynamic calculations over &lt;input&gt; and &lt;output&gt; values controlled by the client. These values must be available to be sent to the server otherwise there is a direct coupling between the client and server; the server would have to have pre-existing knowledge of the exact algorithm used by the request's client to be able to acquire the same result. This is brittle and does not cater for the scenario where there are multiple or 3rd party client implementations which communicate with a common web service.<br />
<br />
The results of <output> are also useful in constructing a value from multiple or complex input sources. The value may be programmatically defined and then bound to target the request payload, for example:<br />
<br />
<pre><br />
<form oninput="elements['VND.ExampleInc.foo'].value = a.value + '; ' + parseFloat(b.value)"><br />
<br />
<label>Text</label><br />
<input type="text" name="a"/><br />
<br />
<label>Range</label><br />
<input type="range" name="b" min="0" max="1" step="0.1"/><br />
<br />
<label>Result</label><br />
<output name="VND.ExampleInc.foo" payload="_header"/><br />
<br />
<button type="submit">Submit</button><br />
</form><br />
</pre><br />
<br />
In order to generate the following HTTP header from user input:<br />
<br />
<pre><br />
VND.ExampleInc.foo: SomeText; 0.1<br />
</pre><br />
<br />
=== HTTP Authentication ===<br />
<br />
<br />
*The form control fields "_user_" and "_password_" representative of the named parameters to the XHR "open()" method are added for declarative HTTP authentication using form inputs.<br />
<br />
*The "_logout_" form control field is added for clearing an origin's HTTP authentication on successful completion of the form request.<br />
<br />
<br />
HTTP Authentication has been traditionally provided within HTML browsers through native platform support whereby if a request is issued which requires authentication the browser initiates native UI controls allowing the user to enter their login credentials and resend the initial request. This has several drawbacks as the interface for supplying credentials is outside the control of the web site and can not be styled or customized which creates a jarring user experience and has proven to be difficult for users to understand and trust. Once a user has initiated HTTP authentication on a site there is currently no method available by either declarative or imperative programming for a site to clear the browser's authentication cache which is applied to requests to the site. This lack of 'logout' support leaves users with open authentication for the lifetime of their browser application denying an essential use case and potentially exposing the user to additional risk of CSRF attacks.<br />
<br />
The primary requirement for remedying these shortcomings and improving security on the web is for HTML to control the initiation and scope of authentication. The solution must allow for credentials to be supplied using form input controls to allow for sensitive data to be captured using password fields. The solution must also allow these credentials to be potentially captured and applied for any request, as these are the semantics of HTTP authentication as controlled through the application of HTTP headers and valid for inclusion on any request. <br />
<br />
The method for delivering this functionality is by extension of the set of form control fields to include the new reserved names outlined above. Form control fields are used within HTML to declare customizations to the form submission process applied by the browser. Existing control fields are "_charset_" and "_isindex_" which redefine the submission process by configuring the character encoding or form data set respectively. This behavior is aligned with the functionality required for supporting protocol authentication as a form submission customization and, as credential information is not sent in the payload of the request, using special input names is not restrictive and serves to protect authors against inadvertently leaking sensitive data.<br />
<br />
The "_logout_" form control field is also used to control the form submission process. This reserved name may be applied to an input control to declare that the browser should clear the origin's authentication cache on a successful response from the server. When constructing and sending the request the browser applies any existing authentication state within the request so that the server has knowledge of which user the request is from and can clean up any remote session-based state it may be retaining. This is strictly not required by the HTTP protocol or HTTP authentication which are stateless, however there are practical benefits to retaining some state across requests on a server and the request notification also serves to remove any session-style cookies from subsequent client requests. The authentication cache is only cleared by the browser on a successful response to cater for potential error conditions originating from either the client or the server and to allow the site to define the location and content of the response.<br />
<br />
=== Form Submission ===<br />
<br />
<br />
*The form submission process is defined by the resolved scheme of the form's action<br />
<br />
*The form action URI is constructed through applying all submission elements with resolved payload "_action" <br />
<br />
*The form header set is constructed through applying all submission elements with resolved payload "_header" <br />
<br />
*The form data set is constructed through applying all submission elements with resolved payload "_body" <br />
<br />
*The mailto scheme algorithm is upgraded to allow configuration of action, headers and body<br />
<br />
*The javascript and ftp schemes are not supported due to lack of use cases<br />
<br />
<br />
The form submission process is required to be updated in order to support the logic of the declarative controls. The existing process currently attempts to force all protocol interaction in forms to either a logical "GET" or "POST" operation. This exhibits the most basic support for any state-changing protocol in reducing the mode of operation into either 'read' or 'write' operations, however the only supported protocol which this can even apply to is HTTP. The current approach of defining a method-based switch over the submission process is flawed in its attempt to define a HTML-only protocol abstraction layer. <br />
<br />
The "mailto" and "data" schemes both serve a single purpose which is the capture and construction of a request representation. Due to the lack of expressiveness for controlling the form data set, the "mailto" scheme is defined to switch the construction set to configuring either the mailto headers or the body based on the resolved @method state. This switch has no semantic meaning and does not make sense when the method of operation remains the same. The "data" scheme is also defined with alternate operation based on the state of the @method attribute, this operation is defined as either a navigation to the action URI for a "GET" method, or as the construction of the URI from the form data set which the browsing context is then navigated to. The mode of operation for "GET" methods serves no purpose as the only form attribute used in the resulting request is the unmutated @action attribute.<br />
<br />
The schemes "javascript" and "ftp" both also suffer from this lack of functional capability. These two schemes only support the "GET" method and neither of them constructs any data set representing a request. The ability to navigate to ftp or Javascript URIs is possible through standard HTML anchors which satisfy the use cases for their access.<br />
<br />
The form submission algorithm is therefore changed to be defined more naturally by the scheme of the resolved form @action URI. This eliminates the confusion arising from the re-purposing of an otherwise distinct attribute definition. This simplifies the process itself by keeping protocol specific behavior defined within an independent algorithm which is free to define the logic required.<br />
<br />
=== XHR, CSRF and CORS ===<br />
<br />
The design and of HTML5 forms stems from the same requirements which spurred the creation of the XmlHttpRequest Javascript interface for providing access to the HTTP protocol. When XHR was introduced to the browser environment the background operation of the scripts together with DOM access and the shared 'ambient authority' of authentication and cookies within browsers combined to open new security vulnerabilities for normal web users. At the time, this resulted in a large amount of FUD around the causes of the vulnerabilities and the protections required to mitigate against these new risks.<br />
<br />
The Cross-Origin Resource Sharing (CORS) specification has been developed in answer to the need for the World Wide Web to operate the way it was designed. This allows any site to link to and define interaction with any other site on the web and to make that interaction available for users. The need and implementation of this are irrespective to the definition of HTML forms and this proposal does not introduce a requirement mandating the support of XHR, CORS, HTTP Authentication, HTTP Cookies or any other specification. <br />
<br />
The specification of HTML does not impose requirements on implementations to support other specifications or mandate the inclusion of secondary features. This may not be immediately obvious when the primary audience is the main browser vendors which implement their products as the combination of multiple web specifications and internet protocols which inter-operate to provide a highly integrated operational environment. However, the scope of HTML is limited by a separation of concerns and this separation serves to allow for the simplest implementation to be a conformant one and without assumptions as to how it operates or what purpose it serves.<br />
<br />
For example, we can look to the use cases of public access terminals to provide validation. These implementations provide a client environment for public access where user interaction is a potential threat from the perspective of the service provider. By implementing a simple HTML client which does not run Javascript, does not have multiple tabs, does not support HTTP authentication, does not support HTTP cookies, this provider is capable of supplying a product which is fully conformant with the HTML specification and guaranteed the level of support defined but without the additional risks and complexity involved with such a combined solution.<br />
<br />
It is for these reasons that this proposal does not introduce new dependencies or unduely constrain the required operation of implementations. Vendors are free to define the standards and specifications which their products support and are free to choose which combinations of these provide the environment for serving their target user base.<br />
<br />
=== Counter-Proposal Responses ===<br />
<br />
The following is the set of responses documenting the answers to concerns raised by the issue's counter proposal.<br />
<br />
==== Lack of Provided Use Cases ====<br />
<br />
''...does not give use cases for each HTTP verb it proposes to allow in method="" ''<br />
<br />
The ability to control request generation is defined to be unlimited in what methods may be used and how the payload is constructed. This retains the expressiveness of HTML as a language and affords to authors the lack of restriction imposed by the HTTP protocol. While certain combinations of methods, headers and body content may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of flexibility is what enables specifications to be the most widely applicable and of most use to the largest amounts of users and use-cases and fosters an environment where innovation is possible and possibility is realized.<br />
<br />
We can see the explicit need for supporting the additional HTTP verbs from both the stated demand of the community and the resulting workaround and hacks which have been implemented in order to circumvent their omission. These workarounds take the form of using a "X-HTTP-Method-Override" attribute as either a HTTP header or hidden form field which triggers the alternate processing semantics within the web service. As noted within the rationale above, while these workarounds allow for the methods to be triggered, they do so without support on the protocol level effectively eliminating their practical usefulness.<br />
<br />
''...but theoretical purity is at the bottom of our Priority of Constituencies. ''<br />
<br />
The main beneficiaries of these enhancements are end users, authors and developers who are protected and empowered with the exposure to the transfer protocol of the web for the technological benefits, guarantees and protections the protocol affords. This represents real practical gains over what is currently possible.<br />
<br />
The perception of puritanical motives for these enhancements is no doubt sourced from the many active debates arising from recent revisiting of the ReSTful architectural style which was used in the design of the World Wide Web. This debate has little to do with HTTP and is more the concerned with the application of the style itself to the architecture and design of systems implemented on top of the protocol. <br />
<br />
As we refer to the HTML Design Principles themselves, it should be noted that the changes proposed herein demand the attention and weight of highest order due to the costs and difficulties their omission would otherwise cause: <br />
<br />
''In case of conflict, consider users over authors over implementers over specifiers over theoretical <br />
''purity. In other words costs or difficulties to the user should be given more weight than costs to <br />
''authors; which in turn should be given more weight than costs to implementers; which should be given <br />
''more weight than costs to authors of the spec itself, which should be given more weight than those <br />
''proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for <br />
''multiple constituencies at once.''<br />
<br />
==== Complexity of Change ====<br />
<br />
''The Enhance HTTP request generation from forms Change Proposal describes a complex set of features to <br />
''be added to HTML forms. It's hard to get these details right; Gecko had an implementation of PUT and <br />
''DELETE for <form> that was pulled just before the release of Firefox 4 due to this.''<br />
<br />
The set of changes contained herein represent the results of critical review over the specification of forms from the expert domain knowledge of architects and designers of HTTP web services. While the changes included may appear to be complex, they represent the<br />
reduction of the problem down to the core set of requirements necessary for satisfying these needs. With the requirements for specification being defined by HTTP, there exists the clear and immutable set of constraints for specification to occur and for implementations to be tested. <br />
<br />
The implementation of PUT and DELETE within Gecko has been the source of validation from calls for the removal of these methods. If we look into the [https://bugzilla.mozilla.org/show_bug.cgi?id=583288 bug report] however we see that the broken implementation was around the handling of HTTP redirects, also affecting any requests generated from XHR. There is a misconception that there is additional complexity in handling requests based on what generated the request, this is a fallacy. It is equally possible for forms and XHR to generate identical requests and the resulting responses are mandated within HTTP to be processed identically by the UA as any identical representation would.<br />
<br />
The changes to the form submission algorithm represent the only source of complexity within this proposal, and that complexity is limited with impact only to browser implementers. The new form methods, payload attribute and authentication control fields are all simple element and attribute definitions which do not consist of confusing behavior changes or overt dependencies on sibling elements. On the contrary, the simplicity of the design allows the new element definitions to complement one another resulting in conceptually simple and powerful declarative expression.<br />
<br />
The complexity within the submission algorithm is solely based on the HTML4 implementation of HTTP request binding for GET and POST methods. This binding is based on the resolved form method to target the action or body of the request with form parameters. With the introduction of payload binding configuration this algorithm is naturally extended, however the need to maintain backwards compatibility with HTML4 documents and to support the default semantics of HTTP require the form's method to be used to define the default binding for elements which lack an explicit deceleration. This takes the form of providing a special form submission condition for implementations and represents the greatest complexity introduced by this proposal and that which is irreducible.<br />
<br />
==== Lack of UA Implementor Interest ====<br />
<br />
''A solicitation of UA implementor interest from the Editor has gone unanswered for a month. Moreover, the spec<br />
''allowed PUT and DELETE in <form method> for years. They were dropped after the failed Gecko implementation<br />
''mentioned above.''<br />
<br />
The solicitation for UA implementor interest was posed by the editor and remains unanswered. This not only shows a lack of positive interest but also a lack of negative objection and no conclusions can be drawn from such silence. Given that when PUT and DELETE were within the specification there were initial implementations happening within Gecko, this indicates that there is interest by some vendors to support these users.<br />
<br />
The design of these changes is modeled on existing operation available within XHR and does not introduce any new functionality not in this interface. For these changes to be implemented the form is logically required to be 'mapped' into the same data structure as provided through XHR. This is a simple and limited programmatic task and given the convergence of these two input structures into a single protocol call this is expected and designed such that implementations can refactor and combine these inputs into a single programming construct.<br />
<br />
== Details ==<br />
<br />
=== Form Method ===<br />
<br />
* Update the valid state for "method" and "formmethod" content attributes to be any value excluding the HTTP methods defined by the following enumerated blacklist:<br />
<br />
CONNECT, TRACE, TRACK<br />
<br />
=== Payload Binding ===<br />
<br />
* Add "payload" as a new content attribute to each of the submittable elements defined in section "4.10.2 Categories"<br />
<br />
* Add the restriction of state of the "payload" content attribute to one of the following enumerated values: <br />
<br />
_action, _header, _body<br />
<br />
=== Submittable <output> ===<br />
<br />
* Add the &lt;output&gt; element to the list of submittable elements and enable it for inclusion in the construction of the form request set<br />
<br />
=== HTTP Authentication ===<br />
<br />
* Add the following special values to the list of restricted values for form element's "name" attribute in section "4.10.19.1 Naming form controls":<br />
<br />
_user_, _password_, _logout_<br />
<br />
* Add the definition of the "_user_" special form control on a Text control as the value and behavior of the XHR authentication parameter "user"<br />
<br />
* Add the definition of the "_password_" special form control on a Password control as the value and behavior of the XHR authentication parameter "password"<br />
<br />
* Add the definition of the "_logout_" special form control as the value to require the UA to clear site authentication on successful response.<br />
<br />
=== Form Submission Process ===<br />
<br />
* Remove the definition of the FTP and Javascript schemes from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of these scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
==== Form Data Set Construction ====<br />
<br />
* Add the “disabled” content attribute to the &lt;object&gt; and &lt;output&gt; elements and retain its state and operation as defined for the other submittable elements where the value represent by the element is excluded from the set of submittable form elements.<br />
<br />
* Update the form submission algorithm by specifying the state of the "action" to be the resolved URL with the additional parameters to the process as the submittable form elements whose "payload" attribute is resolved to the value "_action" or with unset attribute and the resolved HTTP method state of HEAD, GET, OPTIONS or DELETE.<br />
<br />
* Update the form submission algorithm by specifying the state of the "request headers" to be the set of submittable form elements whose "payload" attribute is resolved to the value "_header".<br />
<br />
* Update the form submission algorithm by specifying the state of the "form data" to be the set of submittable form elements whose "payload" attribute is resolved to the value "_body" or with an unset attribute and the resolved HTTP method state of PUT, POST, PATCH or unknown method.<br />
<br />
* Update the form submission algorithm by removing the scheme method abstraction table and replacing it with a scheme switch to sections defining the specific set of processing instructions<br />
<br />
==== HTTP(S) Scheme Submission Process ====<br />
<br />
* Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:<br />
<br />
# For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters<br />
# For the set of elements resolved with the payload "_header" apply the set of name\value pairs as HTTP author request headers with the same definition as described in XHR<br />
# For the set of elements resolved with the payload "_body" encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described in XHR<br />
# If there exists a form element corresponding to the special control "_user_" or "_password_" then these values must be applied to the request as with the same definition described in XHR<br />
# Construct and send the request using the HTTP(S) method defined by the submitter element's resolved "method" attribute state.<br />
# If there exists a form element corresponding to the special control "_logout_" and the response to the request is a 2xx success code then the agent must clear the site's authentication cache for subsequent requests.<br />
<br />
==== Data Scheme Submission Process ====<br />
<br />
* Add the definition of the data scheme processing instruction set as defined by the following process:<br />
<br />
# For the set of elements with the payload attribute "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described by "Post to data:".<br />
<br />
==== Mailto Scheme Submission Process ====<br />
<br />
* Add the definition of the mailto scheme processing instruction set as defined by the following process:<br />
<br />
# For the set of elements with the payload "_action" encode the set of fields by concatenating them together using the semi-colon ";" deliminator and append to the action URI.<br />
# For the set of elements with the payload "_header" encode the set of fields using the "application/x-www-form-urlencoded" encoding algorithm and append to the action URI with the question mark "?" character.<br />
# For the set of elements with the payload "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply to the end of the action URI with the prefix of "body="<br />
# Navigate the target browsing context to destination represented by the action<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
==== Form Method ====<br />
<br />
* Declarative specification of HTTP web services within the HTML language<br />
* Enables HTTP web services for scriptless clients and environments<br />
* Simpler visible programming, comprehension, documentation and education of HTTP web services and forms<br />
* Correct use of HTTP without tunneling through the non-semantic and non-idempotent POST method<br />
* Greater functionality in form submission attributes on buttons for customizing the data set with alternate request parameters<br />
<br />
==== Payload Binding ====<br />
<br />
* Allows the flexibility to specify any and all aspects of the request for any method<br />
* Maintains backwards-compatibility with existing HTML4 forms and HTTP method conventions<br />
* Allows query parameters for PUT and POST for resource targeting and non-representational intent<br />
* Allows GET or other action methods to include embedded digital keys for capability-based security<br />
* &lt;input&gt; and &lt;output&gt; elements can define header fields configured using any input type, validation or calculation<br />
* Headers allow for complete request representations by including protocol or custom headers which are essential aspects of action and intent<br />
* Headers support the essential semantics of idempotent methods<br />
* Headers support additional response negotiation through techniques such as "Prefer" headers<br />
* Enables scope for further innovation over the protocol which is increasing using headers as a representational state mechanism<br />
* Use of underscore prefix "_" for payload states uses the familiar conventions of browser context targeting while also retaining scope for further specification possibly in integration with UriTemplates or other name-based templating technologies<br />
* Mailto forms can construct messages with multiple recipients and have full control over all email headers and the body contents without limitation from intent tunneling through HTTP methods names<br />
* All submittable elements have a “disabled” state allowing explicit exclusion of values used by documents for user communication or input capture from being mandatory in the request or generated "data:" representations<br />
<br />
==== Submittable &lt;output&gt; Element ====<br />
<br />
* Client-side calculations do not need to be dependent on identical server-side implementations which otherwise introduce client-server coupling<br />
* Calculations over user inputs can be applied to construct complex header values<br />
* Decouples input capture from data use or representation<br />
<br />
==== HTTP Authentication ====<br />
<br />
* Form control fields re-use existing conventions for triggering custom User Agent request-generation behavior <br />
* HTTP Authentication in forms bypasses the unfriendly browser popups and allows site controlled, familiar and flexible CSS user interfaces<br />
* Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache with server notification<br />
<br />
=== Negative Effects ===<br />
<br />
* The introduction of payload targeting introduces a more complex form request generation algorithm for implementors, however backward compatibility is maintained and there is explicit provisioning for the reduction of implementation code through refactoring<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance defined through the the application of changes in the "Details" section<br />
<br />
* HTTP Authentication is non-required conformance on implementations<br />
<br />
* FTP and Javascript schemes are non-required conformance form actions<br />
<br />
=== Risks ===<br />
<br />
* Additional HTTP methods introduce new security risks from non-script environments. As the new functionality exposed is currently available within XHR it does not introduce any new security risks that are not already available within scripted environments. As the new request generation features enable greater expression of requests, any new security risks would be limited to server processing, which is also already available to XHR contexts. As the responses from servers are still processed within a non-script environment there is no further risk introduced to the client with processing the response.<br />
<br />
* Forms may attempt to override User-Agent controlled headers. To mitigate this, the same black-listed headers may be applied by User Agents as with requests from XHR.<br />
<br />
* Nefarious scripts may alter the state of <output> element's value violating the calculations the server was expecting to be applied. Since the nefarious script already has access to DOM the vulnerabilities would not be limited to this and as such are a secondary attack vector resulting from a prior security breach.<br />
<br />
* Existing documents may use the special form control names introduced with this proposal. This may risk unexpected behavior being triggered by the User Agent prior to the request being sent or post response. This should be mitigated by implementers by restricting the application of new form control fields to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.<br />
<br />
== Acknowledgements ==<br />
<br />
Acknowledgements and thanks go to the following people for their efforts which have contributed to this proposal: <br />
<br />
*Julian Reschke<br />
*Mike Amundsen<br />
*Dave Kok<br />
*Ian Hickson<br />
*Anne Van Kesteren<br />
*Ted O'Connor<br />
*HTML WG Chairs: Sam Ruby, Paul Cotton &amp; Maciej Stachowiak<br />
<br />
== References ==<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/html/wg/tracker/issues/195]<br />
<br />
* XMLHttpRequest [http://www.w3.org/TR/XMLHttpRequest]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.txt]<br />
<br />
* HTTP Authentication: Basic and Digest Access Authentication [http://www.ietf.org/rfc/rfc2617.txt]<br />
<br />
* Gecko Bug 583288 - Authorize PUT and DELETE methods for form submission [https://bugzilla.mozilla.org/show_bug.cgi?id=583288]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-195&diff=59803User:Cjones/ISSUE-1952012-06-27T16:33:18Z<p>Cjones: Updated Change Proposal with Review from HTML Chairs</p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-195: Enhance HTTP request generation from forms =<br />
<br />
== Summary ==<br />
<br />
This is the proposal for the enhancement of forms in integration with the HTTP protocol and the ability for forms to generate entire requests through declarative HTML markup, without requiring javascript. This proposal includes the following set of changes:<br />
<br />
* Form can initiate any protocol request method<br />
* Submittable elements can bind to protocol action, headers or body request payload<br />
* Output element enabled for form submission allowing clients to send the results of UI calculations in a request<br />
* Declare HTTP authentication within forms enabling custom login\logout forms using standard input controls <br />
* Declare asynchronous UI requests enabling single-page 'webapp' style documents for code-on-demand clients<br />
<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The HTML Working Group is chartered to deliver HTML5 as ''"A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web"''. With HTTP being the transfer protocol of the web and with forms being the semantic markup of protocol interaction for users, completing integration with the protocol is one of the core deliverables for HTML5 and one of the progressive enhancements to the language which will the benefit of the largest numbers of users, authors and developers.<br />
<br />
The support for the additional HTTP methods "PUT" and "DELETE" was introduced in HTML5 to cater for the demand from authors to declare interaction with web services which leverge the guarentees and protections affored to different method semantics. The initial specification of this functionality did not address the necessity to be able to control protocol mechanisms such as ETags for these methods to be useful. This resulted in the opening of a bug report questioning the removal of this functionality citing a lack of workable use cases.<br />
<br />
This proposal is the culmination of the subsequent research and development of the working group into the requirements and necessary design of the solution as constrained by maintaining logical compatibility with HTML4 and with strict adherence to the specification of HTTP, HTTP Authentication and with reference to XmlHttpRequest which has enabled the benefits of protocol integration for the javascript environment.<br />
<br />
=== Form Method ===<br />
<br />
<br />
*The form @method attribute is extended to allow any value as the name of the HTTP request method, with the exception of the following list of explicitly prohibited blacklist methods: <br />
<br />
CONNECT, TRACE, TRACK<br />
<br />
<br />
This allows authors to declare user interaction with web services which use the different HTTP/1.1 methods to manipulate resources. The HTTP protocol includes the methods "PUT" and "DELETE" which are idempotent and impose guarantees that multiple identical requests will have the same effect as a single request. This protocol feature is the essential network programming paradigm of optimistic locking which solves the problem of coordinating resource modification in distributed systems which asynchronously alter remote state. As with any layered system, it is possible to replicate this functionality within a higher layer, however these implementations are application specific and need to be designed and implemented for each new application within the layer and forgoes the benefits that come with a lower-level implementation and the reduction of complexity of the layered deferment of responsibility.<br />
<br />
The extension of the @method attribute does not limit the values which may be entered to only those methods defined in HTTP/1.1 allowing extensions and new protocols to be integrated within HTML without need for additional specification. This benefits the HTML language by removing the need for the set of allowable methods to be controlled and administered by the working group and allows innovation to proceed unencumbered from the process of specification publication and implementation. This directly benefits the communities of users who have extended HTTP for additional use cases, for example the "PATCH" extension which is used for partial resource modification where an otherwise identical request would have a different consequence.<br />
<br />
The blacklist of prohibited methods is added as a security mechanism to protect users from initiating HTTP requests which are incompatible or insecure for a HTML client. The "TRACE" and "TRACK" methods are used in HTTP for debugging protocol requests and echo otherwise restricted protocol information back to the client as response content which is accessible from javascript. <br />
<br />
=== Payload Binding ===<br />
<br />
<br />
*The @payload attribute is added to each of the submittable elements:<br />
<br />
button<br />
input<br />
keygen<br />
object<br />
select<br />
textarea<br />
<br />
*The @payload attribute consists of a set of enumerated values for targeting different areas of the generated request:<br />
<br />
_action<br />
_header<br />
_body<br />
<br />
<br />
This attribute enables declarative configuration of the entire request through any submittable element. Without this support the types of requests which are capable of being constructed by forms is limited to either exclusively binding all values to the action URI as a set of query parameters for GET requests, or binding all the values within the request's body for POST requests. This is a limitation of the declarative expressiveness of forms and the ability for authors to declare interaction with web services which utilize HTTP headers or alternate combinations of URI and body request configurations.<br />
<br />
The ability to configure HTTP headers is a primary requirement for supporting the semantics of the state changing idempotent HTTP methods. These methods use HTTP headers for communicating the version of the resource as an optimistic lock token for concurrency control. This provides in-built protocol protection for end users against the risk of concurrent modification which is an inherent problem for any stateless communication protocol.<br />
<br />
The design of the @payload attribute has been found thorough investigation of the requirements and analysis of the potential solutions. A number of alternatives were considered which initially proposed to deliver the goal of providing declarative HTTP headers, however all of which have failed to solve the issue and offer the kind of expressiveness and functionality as exhibited in the final design. Each of the following alternatives was considered and resolutely thrown out for being incapable of supporting a primary use case: <br />
<br />
*Form attributes for headers names<br />
**Too many and requires explicit specification<br />
<br />
*Form attribute @header-* <br />
**Not integrated with user input or other submittable elements<br />
<br />
*Input name="__header__"<br />
**Entire header name\value pair would need to be captured within the input @value attribute <br />
<br />
*Input type="header"<br />
**Can not capture different input types, eg: number, time, url <br />
<br />
The final solution uses a new attribute which is added to each of the submittable elements. This allows any submittable element to target any area of the request and especially benefits the requirements of web services which use unique tokens for session identification or validating the authenticity of requests, for example CSRF tokens. The implementations of these tokens can take the form of URI query parameters, HTTP headers, or encoded body parameters, however without adequate payload request binding the ability to implement these solutions invariably causes contentions in system design through the exclusivity of HTML4 request binding.<br />
<br />
The introduction of the @payload attribute has additionally been deliberated with the alternative potential of providing the additional functionality within the existing @target attribute on submission elements. At first there appears a good semantic fit between the attribute name and the 'targeting' of different areas of the request, and as the scope for @target is restricted to forms and 'submit' inputs\buttons for referring to reserved or named browsing contexts, there would appear to be no overlap in functionality. All that would be required is the extension of the @target attribute to allow the additional reserved payload names. However, as it would be valid for a submit button to both declare the target context of the response and configure the payload of the button name in the request, the attribute definition would need to be extended to a multi-value text attribute with the resulting additional complexity that this would introduce. For this reason, and to leave open scope for extension to either the @payload or @target attributes in future, the chosen implementation for this functionality is the new attribute.<br />
<br />
=== Submittable &lt;output&gt; ===<br />
<br />
<br />
*The &lt;output&gt; element is added as a submittable form element.<br />
<br />
<br />
The &lt;output&gt; element represents dynamic calculations over &lt;input&gt; and &lt;output&gt; values controlled by the client. These values must be available to be sent to the server otherwise there is a direct coupling between the client and server; the server would have to have pre-existing knowledge of the exact algorithm used by the request's client to be able to acquire the same result. This is brittle and does not cater for the scenario where there are multiple or 3rd party client implementations which communicate with a common web service.<br />
<br />
The results of <output> are also useful in constructing a value from multiple or complex input sources. The value may be programmatically defined and then bound to target the request payload, for example:<br />
<br />
<pre><br />
<form oninput="elements['VND.ExampleInc.foo'].value = a.value + '; ' + parseFloat(b.value)"><br />
<br />
<label>Text</label><br />
<input type="text" name="a"/><br />
<br />
<label>Range</label><br />
<input type="range" name="b" min="0" max="1" step="0.1"/><br />
<br />
<label>Result</label><br />
<output name="VND.ExampleInc.foo" payload="_header"/><br />
<br />
<button type="submit">Submit</button><br />
</form><br />
</pre><br />
<br />
In order to generate the following HTTP header from user input:<br />
<br />
<pre><br />
VND.ExampleInc.foo: SomeText; 0.1<br />
</pre><br />
<br />
=== HTTP Authentication ===<br />
<br />
<br />
*The form control fields "_user_" and "_password_" representative of the named parameters to the XHR "open()" method are added for declarative HTTP authentication using form inputs.<br />
<br />
*The "_logout_" form control field is added for clearing an origin's HTTP authentication on successful completion of the form request.<br />
<br />
<br />
HTTP Authentication has been traditionally provided within HTML browsers through native platform support whereby if a request is issued which requires authentication the browser initiates native UI controls allowing the user to enter their login credentials and resend the initial request. This has several drawbacks to not only require 2 requests to satisfy the intent but also the interface for supplying credentials is outside the control of the web site and can not be styled or customized which creates a jarring user experience and has proven to be difficult for users to understand and trust. Once a user has initiated HTTP authentication on a site there is currently no method available by either declarative or imperative programming for a site to clear the browser's authentication cache which is applied to requests to the site. This lack of 'logout' support leaves users with open authentication for the lifetime of their browser application denying an essential use case and potentially exposing the user to additional risk of CSRF attacks.<br />
<br />
The primary requirement for remedying these shortcomings and improving security on the web is for HTML to control the initiation and scope of authentication. The solution must allow for credentials to be supplied using form input controls to allow for sensitive data to be captured using password fields. The solution must also allow these credentials to be potentially captured and applied for any request, as these are the semantics of HTTP authentication as controlled through the application of HTTP headers and valid for inclusion on any request. <br />
<br />
The method for delivering this functionality is by extension of the set of form control fields to include the new reserved names outlined above. Form control fields are used within HTML to declare customizations to the form submission process applied by the browser. Existing control fields are "_charset_" and "_isindex_" which redefine the submission process by configuring the character encoding or form data set respectively. This behavior is aligned with the functionality required for supporting protocol authentication as a form submission customization and, as credential information is not sent in the payload of the request, using special input names is not restrictive and serves to protect authors against inadvertently leaking sensitive data.<br />
<br />
The "_logout_" form control field is also used to control the form submission process. This reserved name may be applied to an input control to declare that the browser should clear the origin's authentication cache on a successful response from the server. When constructing and sending the request the browser applies any existing authentication state within the request so that the server has knowledge of which user the request is from and can clean up any remote session-based state it may be retaining. This is strictly not required by the HTTP protocol or HTTP authentication which are stateless, however there are practical benefits to retaining some state across requests on a server and the request notification also serves to remove any session-style cookies from subsequent client requests. The authentication cache is only cleared by the browser on a successful response to cater for potential error conditions originating from either the client or the server and to allow the site to define the location and content of the response.<br />
<br />
=== Asynchronous Requests ===<br />
<br />
<br />
*The “async” boolean attribute is added to &lt;form&gt;, &lt;input&gt; and &lt;button&gt; elements for toggling between synchronous and asynchronous UI form submission. <br />
<br />
<br />
The addition of the "async" submission form attribute is functionality currently available to XHR scripting and allows AJAX style requests to be declared from HTML markup. The default operation is retained as a synchronous UI operation where the request's response is processed and rendered within the targeted browsing context. Asynchronous operations are processed within a background thread by the browser and the response is passed to the target context through calling the "onresponse" event with the result. The event adapter can then update the browsing context's DOM with the nature of the response without causing document refresh or location change.<br />
<br />
This affords to HTML documents the ability to declare structural page controls within the document yet to have the kind of user interfaces which would otherwise have to be transcribed through javascript and XHR.<br />
<br />
=== Form Submission ===<br />
<br />
<br />
*The form submission process is defined by the resolved scheme of the form's action<br />
<br />
*The form action URI is constructed through applying all submission elements with resolved payload "_action" <br />
<br />
*The form header set is constructed through applying all submission elements with resolved payload "_header" <br />
<br />
*The form data set is constructed through applying all submission elements with resolved payload "_body" <br />
<br />
*The mailto scheme algorithm is upgraded to allow configuration of action, headers and body<br />
<br />
*The javascript and ftp schemes are not supported due to lack of use cases<br />
<br />
<br />
The form submission process is required to be updated in order to support the logic of the declerative controls. The existing process currently attempts to force all protocol interaction in forms to either a logical "GET" or "POST" operation. This exhibits the most basic support for any state-changing protocol in reducing the mode of operation into either 'read' or 'write' operations, however the only supported protocol which this can even apply to is HTTP. The current approach of defining a method-based switch over the submission process is flawed in its attempt to define a HTML-only protocol abstraction layer. <br />
<br />
The "mailto" and "data" schemes both serve a single purpose which is the capture and construction of a request representation. Due to the lack of expressiveness for controlling the form data set, the "mailto" scheme is defined to switch the construction set to configuring either the mailto headers or the body based on the resolved @method state. This switch has no semantic meaning and does not make sense when the method of operation remains the same. The "data" scheme is also defined with alternate operation based on the state of the @method attribute, this operation is defined as either a navigation to the action URI for a "GET" method, or as the construction of the URI from the form data set which the browsing context is then navigated to. The mode of operation for "GET" methods serves no purpose as the only form attribute used in the resulting request is the unmutated @action attribute. <br />
<br />
The schemes "javascript" and "ftp" both also suffer from this lack of functional capability. These two schemes only support the "GET" method and neither of them constructs any data set representing a request. The ability to navigate to ftp or javascript URIs is possible through standard HTML anchors which satisfy the use cases for their access.<br />
<br />
The form submission algorithm is therefore changed to be defined more naturally by the scheme of the resolved form @action URI. This eliminates the confusion arising from the re-purposing of an otherwise distinct attribute definition. This simplifies the process itself by keeping protocol specific behavior defined within an independent algorithm which is free to define the logic required.<br />
<br />
=== XHR, CSRF and CORS ===<br />
<br />
The design and of HTML5 forms stems from the same requirements which spurred the creation of the XmlHttpRequest javascript interface for providing access to the HTTP protocol. When XHR was introduced to the browser environment the background operation of the scripts together with DOM access and the shared 'ambient authority' of authentication and cookies within browsers combined to open new security vulnerabilities for normal web users. At the time, this resulted in a large amount of FUD around the causes of the vulnerabilities and the protections required to mitigate against these new risks.<br />
<br />
One of the erroneous judgements at the time was that different HTTP methods are more or less secure than others. As PUT and DELETE are state changing methods, and as they were not previously available within the environment, the were incorrectly categorized as "unsafe" for the web and have since been treated with skepticism and concern arising from this initial uncertainty. The POST method is also a state-changing method and arguable more "unsafe" from the perspective of the protocol due to the lack of resource state protections and the ability for a single intent to be applied multiple times due to network or user error. <br />
<br />
The vulnerability of Cross Site Request Forgery (CSRF) was identified which allowed 3rd party sites to use the 'ambient authority' available within a user's browser to impersonate user intent and initiate nefarious requests for the purposes of violating user privacy and resource security. As the primary threat is with communication with non-origin sites, yet because GET and POST requests are unrestricted in terms of origin, a half-baked restriction is imposed limiting other methods with a same-origin policy. This does nothing to protect end users as they are still fully susceptible to attacks which use POST or even GET methods to steal user data. The protocol method is irrespective from the goals or capability of a hacker to transmit state from one machine to another. <br />
<br />
Regardless, the Cross-Origin Resource Sharing (CORS) specification has been developed in answer to the need for the World Wide Web to operate the way it was designed. This allows any site to link to and define interaction with any other site on the web and to make that interaction available for users. The need and implementation of this are irrespective to the definition of HTML forms and this proposal does not introduce a requirement mandating the support of XHR, CORS, HTTP Authentication, Cookies or any other specification. <br />
<br />
The specification of HTML does not impose requirements on implementations to support other specifications or mandate the inclusion of secondary features. This may not be immediately obvious when the primary audience is the main browser vendors which implement their products as the combination of multiple web specifications and internet protocols which inter-operate to provide a highly integrated operational environment. However, the scope of HTML is limited by a separation of concerns and this separation serves to allow for the simplest implementation to be a conformant one and without assumptions as to how it operates or who it is for.<br />
<br />
For example, we can look to the use cases of public access terminals to provide validation of this postulation. These implementations provide a client environment for public access where user interaction is a potential threat from the perspective of the service provider. By implementing a simple HTML client which does not run javascript, does not have multiple tabs, does not support HTTP authentication, does not support HTTP cookies, this provider is capable of supplying a product which is fully conformant with the HTML specification and guaranteed the level of support defined but without the additional risks and complexity involved with such a combined solution.<br />
<br />
It is for these reasons that this proposal does not introduce new dependencies or unduely constrain the required operation of implementations. Vendors are free to define the standards and specifications which their products support and are free to choose which combinations of these provide the environment for serving their target user base.<br />
<br />
=== Counter-Proposal Responses ===<br />
<br />
The following is the set of responses documenting the answers to concerns raised by the issue's counter proposal.<br />
<br />
==== Lack of Provided Use Cases ====<br />
<br />
''...does not give use cases for each HTTP verb it proposes to allow in method="" ''<br />
<br />
The ability to control request generation is defined to be unlimited in what methods may be used and how the payload is constructed. This retains the expressiveness of HTML as a language and affords to authors the lack of restriction imposed by the HTTP protocol. While certain combinations of methods, headers and body content may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of flexibility is what enables specifications to be the most widely applicable and of most use to the largest amounts of users and use-cases and fosters an environment where innovation is possible and possibility is realized.<br />
<br />
We can see the explicit need for supporting the additional HTTP verbs from both the stated demand of the community and the resulting workaround and hacks which have been implemented in order to circumvent their omission. These workarounds take the form of using a "X-HTTP-Method-Override" attribute as either a HTTP header or hidden form field which triggers the alternate processing semantics within the web service. As noted within the rationale above, while these workarounds allow for the methods to be triggered, they do so without support on the protocol level effectively eliminating their practical usefulness.<br />
<br />
''...but theoretical purity is at the bottom of our Priority of Constituencies. ''<br />
<br />
The main beneficiaries of these enhancements are end users, authors and developers who are empowered with the exposure to the transfer protocol of the web for the technological benefits, guarantees and protections the protocol affords. This represents real practical gains over what is currently possible.<br />
<br />
The perception of puritanical motives for these enhancements is no doubt sourced from the many active debates arising from recent revisiting of the ReSTful architectural style which was used in the design of World Wide Web. This debate has little to do with HTTP and is more the concerned with the application of the style itself to the architecture and design of systems implemented on top of the protocol. <br />
<br />
As we refer to the HTML Design Principles themselves, it should be noted that the changes proposed herein demand the attention and weight of highest order due to the costs and difficulties their omission would otherwise cause: <br />
<br />
''In case of conflict, consider users over authors over implementers over specifiers over theoretical <br />
''purity. In other words costs or difficulties to the user should be given more weight than costs to <br />
''authors; which in turn should be given more weight than costs to implementers; which should be given <br />
''more weight than costs to authors of the spec itself, which should be given more weight than those <br />
''proposing changes for theoretical reasons alone. Of course, it is preferred to make things better for <br />
''multiple constituencies at once.''<br />
<br />
==== Complexity of Change ====<br />
<br />
''The Enhance HTTP request generation from forms Change Proposal describes a complex set of features to <br />
''be added to HTML forms. It's hard to get these details right; Gecko had an implementation of PUT and <br />
''DELETE for <form> that was pulled just before the release of Firefox 4 due to this.''<br />
<br />
The set of changes contained herein represent the results of critical review over the specification of forms from the expert domain knowledge of architects and designers of HTTP web services. While the changes included may appear to be complex, they represent the<br />
reduction of the problem down to the core set of requirements necessary for satisfying these needs. With the requirements for specification being defined by HTTP, there exists the clear and immutable set of constraints for specification to occur and for implementations to be tested. <br />
<br />
The implementation of PUT and DELETE within Gecko has been the source of validation from calls for the removal of these methods. If we look into the [https://bugzilla.mozilla.org/show_bug.cgi?id=583288 bug report] however we see that the broken implementation was around the handling of HTTP redirects, also affecting any requests generated from XHR. There is a misconception that there is additional complexity in handling requests based on what generated the request, this is a fallacy. It is equally possible for forms and XHR to generate identical requests and the resulting responses are mandated within HTTP to be processed identically by the UA as any identical representation would.<br />
<br />
The changes to the form submission algorithm represent the only source of complexity within this proposal, and that complexity is limited with impact only to browser implementers. The new form methods, payload attribute and authentication control fields are all simple element and attribute definitions which do not consist of confusing behavior changes or overt dependencies on sibling elements. On the contrary, the simplicity of the design allows the new element definitions to complement one another resulting in conceptually simple and powerful declarative expression.<br />
<br />
The complexity within the submission algorithm is solely based on the HTML4 implementation of HTTP request binding for GET and POST methods. This binding is based on the resolved form method to target the action or body of the request with form parameters. With the introduction of payload binding configuration this algorithm is naturally extended, however the need to maintain backwards compatibility with HTML4 documents and to support the default semantics of HTTP require the form's method to be used to define the default binding for elements which lack an explicit deceleration. This takes the form of providing a special form submission condition for implementations and represents the greatest complexity introduced by this proposal and that which is irreducible.<br />
<br />
==== Lack of UA Implementor Interest ====<br />
<br />
''A solicitation of UA implementor interest from the Editor has gone unanswered for a month. Moreover, the spec<br />
''allowed PUT and DELETE in <form method> for years. They were dropped after the failed Gecko implementation<br />
''mentioned above.''<br />
<br />
The solicitation for UA implementor interest was posed by the editor and remains unanswered. This not only shows a lack of positive interest but also a lack of negative objection and no conclusions can be drawn from silence. Given that when PUT and DELETE were within the specification there were initial implementations happening within Gecko, this would seem to indicate that there is interest by some vendors to support these users.<br />
<br />
The design of these changes is modeled on existing operation available within XHR and does not introduce any new functionality not in this interface. For these changes to be implemented the form is logically required to be 'mapped' into the same data structure as provided through XHR. This is a simple and limited programmatic task and given the convergence of these two input structures into a single protocol call this is expected and designed such that implementations can refactor and combine these inputs into a single programming construct.<br />
<br />
== Details ==<br />
<br />
=== Form Method ===<br />
<br />
* Update the valid state for "method" and "formmethod" content attributes to be any value excluding the HTTP methods defined by the following enumerated blacklist:<br />
<br />
CONNECT, TRACE, TRACK<br />
<br />
=== Payload Binding ===<br />
<br />
* Add "payload" as a new content attribute to each of the submittable elements defined in section "4.10.2 Categories"<br />
<br />
* Add the restriction of state of the "payload" content attribute to one of the following enumerated values: <br />
<br />
_action, _header, _body<br />
<br />
=== Submittable <output> ===<br />
<br />
* Add the &lt;output&gt; element to the list of submittable elements and enable it for inclusion in the construction of the form request set<br />
<br />
=== HTTP Authentication ===<br />
<br />
* Add the following special values to the list of restricted values for form element's "name" attribute in section "4.10.19.1 Naming form controls":<br />
<br />
_user_, _password_, _logout_<br />
<br />
* Add the definition of the "_user_" special form control on a Text control as the value and behavior of the XHR authentication parameter "user"<br />
<br />
* Add the definition of the "_password_" special form control on a Password control as the value and behavior of the XHR authentication parameter "password"<br />
<br />
* Add the definition of the "_logout_" special form control as the value to require the UA to clear site authentication on successful response.<br />
<br />
=== Asynchronous Requests ===<br />
<br />
* Add “async” as a new boolean content attribute for form submission with a default state of false to each of the submission elements:<br />
<br />
form, button, input<br />
<br />
* Add the "onresponse" event type which is triggered by receiving the request's response containing event data representing the response<br />
<br />
=== Form Submission Process ===<br />
<br />
* Remove the definition of the FTP and javascript schemes from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of these scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
==== Form Data Set Construction ====<br />
<br />
* Add the “disabled” content attribute to the &lt;object&gt; and &lt;output&gt; elements and retain its state and operation as defined for the other submittable elements where the value represent by the element is excluded from the set of submittable form elements.<br />
<br />
* Update the form submission algorithm by specifying the state of the "action" to be the resolved URL with the additional parameters to the process as the submittable form elements whose "payload" attribute is resolved to the value "_action" or with unset attribute and the resolved HTTP method state of HEAD, GET, OPTIONS or DELETE.<br />
<br />
* Update the form submission algorithm by specifying the state of the "request headers" to be the set of submittable form elements whose "payload" attribute is resolved to the value "_header".<br />
<br />
* Update the form submission algorithm by specifying the state of the "form data" to be the set of submittable form elements whose "payload" attribute is resolved to the value "_body" or with an unset attribute and the resolved HTTP method state of PUT, POST, PATCH or unknown method.<br />
<br />
* Update the form submission algorithm by removing the scheme method abstraction table and replacing it with a scheme switch to sections defining the specific set of processing instructions<br />
<br />
==== HTTP(S) Scheme Submission Process ====<br />
<br />
* Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:<br />
<br />
# For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters<br />
# For the set of elements resolved with the payload "_header" apply the set of name\value pairs as HTTP author request headers with the same definition as described in XHR<br />
# For the set of elements resolved with the payload "_body" encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described in XHR<br />
# If there exists a form element corresponding to the special control "_user_" or "_password_" then these values must be applied to the request as with the same definition described in XHR<br />
# Construct the request using the HTTP(S) method defined by the submitter element's resolved "method" attribute state.<br />
# Send the constructed request as either a synchronous or asynchronous request as defined by the submitter element's resolved "async" attribute state.<br />
# If there exists a form element corresponding to the special control "_logout_" and the response to the request is a 2xx success code then the agent must clear the site's authentication cache for subsequent requests.<br />
<br />
==== Data Scheme Submission Process ====<br />
<br />
* Add the definition of the data scheme processing instruction set as defined by the following process:<br />
<br />
# For the set of elements with the payload attribute "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described by "Post to data:".<br />
<br />
==== Mailto Scheme Submission Process ====<br />
<br />
* Add the definition of the mailto scheme processing instruction set as defined by the following process:<br />
<br />
# For the set of elements with the payload "_action" encode the set of fields by concatenating them together using the semi-colon ";" deliminator and append to the action URI.<br />
# For the set of elements with the payload "_header" encode the set of fields using the "application/x-www-form-urlencoded" encoding algorithm and append to the action URI with the question mark "?" character.<br />
# For the set of elements with the payload "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply to the end of the action URI with the prefix of "body="<br />
# Navigate the target browsing context to destination represented by the action<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
==== Form Method ====<br />
<br />
* Declarative specification of HTTP web services within the HTML language<br />
* Enables HTTP web services for scriptless clients and environments<br />
* Simpler visible programming, comprehension, documentation and education of HTTP web services and forms<br />
* Correct use of HTTP without tunneling through the non-semantic and non-idempotent POST method<br />
* Greater functionality in form submission attributes on buttons for customizing the data set with alternate request parameters<br />
<br />
==== Payload Binding ====<br />
<br />
* Allows the flexibility to specify any and all aspects of the request for any method<br />
* Maintains backwards-compatibility with existing HTML4 forms and HTTP method conventions<br />
* Allows query parameters for PUT and POST for resource targeting and non-representational intent<br />
* Allows GET or other action methods to include embedded digital keys for capability-based security<br />
* &lt;input&gt; and &lt;output&gt; elements can define header fields configured using any input type, validation or calculation<br />
* Headers allow for complete request representations by including protocol or custom headers which are essential aspects of action and intent<br />
* Headers support the essential semantics of idempotent methods<br />
* Headers support additional response negotiation through techniques such as "Prefer" headers<br />
* Enables scope for further innovation over the protocol which is increasing using headers as a representational state mechanism<br />
* Use of underscore prefix "_" for payload states uses the familiar conventions of browser context targeting while also retaining scope for further specification possibly in integration with UriTemplates or other name-based templating technologies<br />
* Mailto forms can construct messages with multiple recipients and have full control over all email headers and the body contents without limitation from intent tunneling through HTTP methods names<br />
* All submittable elements have a “disabled” state allowing explicit exclusion of values used by documents for user communication or input capture from being mandatory in the request or generated "data:" representations<br />
<br />
==== Submittable &lt;output&gt; Element ====<br />
<br />
* Client-side calculations do not need to be dependent on identical server-side implementations which otherwise introduce client-server coupling<br />
* Calculations over user inputs can be applied to construct complex header values<br />
* Decouples input capture from data use or representation<br />
<br />
==== HTTP Authentication ====<br />
<br />
* Form control fields re-use existing conventions for triggering custom User Agent request-generation behavior <br />
* HTTP Authentication in forms bypasses the unfriendly browser popups and allows site controlled, familiar and flexible CSS user interfaces<br />
* Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache with server notification<br />
<br />
==== Async Submission Attribute ====<br />
<br />
* Asynchronous requests enable rich 'webapp' style documents without imposing procedural construction or limits to scriptless client environments<br />
<br />
=== Negative Effects ===<br />
<br />
* The introduction of payload targeting introduces a more complex form request generation algorithm for implementors, however backward compatibility is maintained and there is explicit provisioning for the reduction if implementation code through refactoring<br />
<br />
* Asynchronous operation introduces potential confusion for authors on the request\response cycle and a document as a representation not an application. However the additional functionality is required for the functions of a 'webapp' and an increasing common usage pattern within modern sites<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance defined through the the application of changes in the "Details" section<br />
<br />
* HTTP Authentication is non-required conformance on implementations<br />
<br />
* Asynchronous requests are non-required conformance on implementations<br />
<br />
* FTP and javascript schemes are non-required conformance form actions<br />
<br />
=== Risks ===<br />
<br />
* Additional HTTP methods introduce new security risks from non-script environments. As the new functionality exposed is currently available within XHR it does not introduce any new security risks that are not already available within scripted environments. As the new request generation features enable greater expression of requests, any new security risks would be limited to server processing, which is also already available to XHR contexts. As the responses from servers are still processed within a non-script environment there is no further risk introduced to the client with processing the response.<br />
<br />
* Forms may attempt to override User-Agent controlled headers. To mitigate this, the same black-listed headers may be applied by User Agents as with requests from XHR.<br />
<br />
* Nefarious scripts may alter the state of <output> element's value violating the calculations the server was expecting to be applied. Since the nefarious script already has access to DOM the vulnerabilities would not be limited to this and as such are a secondary attack vector resulting from a prior security breach.<br />
<br />
* Existing documents may use the special form control names introduced with this proposal. This may risk unexpected behavior being triggered by the User Agent prior to the request being sent or post response. This should be mitigated by implementers by restricting the application of new form control fields to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.<br />
<br />
== Acknowledgements ==<br />
<br />
Acknowledgements and thanks go to the following people for their efforts which have contributed to this proposal: <br />
<br />
*Julian Reschke<br />
*Mike Amundsen<br />
*Dave Kok<br />
*Ian Hickson<br />
*Anne Van Kesteren<br />
*Ted O'Connor<br />
*HTML WG Chairs: Sam Ruby, Paul Cotton &amp; Maciej Stachowiak<br />
<br />
== References ==<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/html/wg/tracker/issues/195]<br />
<br />
* XMLHttpRequest [http://www.w3.org/TR/XMLHttpRequest]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.txt]<br />
<br />
* HTTP Authentication: Basic and Digest Access Authentication [http://www.ietf.org/rfc/rfc2617.txt]<br />
<br />
* Gecko Bug 583288 - Authorize PUT and DELETE methods for form submission [https://bugzilla.mozilla.org/show_bug.cgi?id=583288]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-184&diff=58908User:Cjones/ISSUE-1842012-05-11T22:28:48Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
= Change Proposal for ISSUE-184: Enhance the &lt;data&gt; element with a type system =<br />
<br />
== Summary ==<br />
<br />
This is a supplementary proposal for the resolution of ISSUE-184 which defines the addition of the &lt;data&gt; element.<br />
<br />
This proposal enhances the &lt;data&gt; element with a "type" attribute for discriminating the class of data represented by the value attribute or the contained element contents.<br />
<br />
The valid values for the "type" attribute are an enumerated set of keywords initially relating to a sub-set of the values currently accepted for the &lt;input&gt; element.<br />
<br />
This proposal also includes the addition of the "type" attribute to the &lt;output&gt; element for "typed" values to be represented by this element in order to provide style formatting across elements in a predictable and complementary manner.<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The addition of the &lt;data&gt; element allows for the semantic markup of machine readable data. The definition of this element only contains the "value" attribute in addition to the set of global element attributes. This exhibits a lack of definition as to what the &lt;data&gt; element represents and how it can be interpreted or should be used.<br />
<br />
=== Type Definition ===<br />
<br />
The contents of the &lt;data&gt; element is a text-format representation of the machine readable data. While this text could be parsable it is highly ambiguous and can not be used to definitely acquire the value or type of data.<br />
<br />
The "value" attribute of the &lt;data&gt; element is the text-encoded representation of the data information, however there are numerous types of data represented by the &lt;data&gt; element and there is significant scope for overlap within text-encodings. This leaves the problem of what the value represents and how to use it.<br />
<br />
The "type" attribute solves this problem by providing the necessary definition to the value in order that it can be converted into a binary representation for machine processing.<br />
<br />
=== Value Integrity ===<br />
<br />
The addition of a type attribute for data values introduces a set of constraints over the valid values that the element may represent. This provides the ability for the value to be restricted to a known data type which can be enforced within the HTML client. This provides the benefit that data values can be used programatically in a safe manner where data can be accessed without having to handle invalid values or manipulate encodings. <br />
<br />
=== Value Formatting ===<br />
<br />
The value of the &lt;data&gt; element is required to be displayed to the user as part of the HTML document rendering. The &lt;data&gt; element caters for customization through the ability for an author to declare the text content of an element and for that value to be the text which is displayed to the user. This process is orchistrated by the HTML client which, in the absence of text content, will process the label by direct substitution of the data value. <br />
<br />
With the addition of a type attribute, this process can be enhanced to allow the client to render the value to a format defined through the type discriminator and the element's resolved locale. This allows for HTML documents to be created for both machine readability and client-localization for the automated translation into formats that adhere to the cultural conventions of the user. This support is currently only afforded to &lt;input&gt; elements and otherwise results in semi-translation within a HTML document which is confusing and error prone for users.<br />
<br />
=== Input &amp; Output Elements ===<br />
<br />
From the introduction of a set of type-classes into the HTML vocabulary, the scope for the application of these types can naturally be extended to the other data-related elements &lt;input&gt; and &lt;output&gt;. These elements represent the means for user-interaction over data and are subject to the same requirements of data integrity and format representation.<br />
<br />
The &lt;output&gt; element additionally benifits from this extension as it can be explicity tied to &lt;input&gt; element value's and their modification events. This process is enhanced through the addition of the type system as it allows for the values to be restricted or converted into specific types and for this to be constrained and controlled within the HTML client. <br />
<br />
== Details ==<br />
<br />
# Add the "type" attribute to the &lt;data&gt; and &lt;output&gt; elements<br />
# Define the valid states for the "type" attribute for these elements as a set of enumerated values based a sub-set of valid states for the &lt;input&gt; element: text, tel, url, email, datetime, date, month, week, time, datetime-local, number, range, color<br />
# Define the default type for elements with un-set or unknown type attribute as 'text' state<br />
# Define the value of the element as the resolution of its value through the application of the corresponding HTML microsyntax<br />
# Define the rendering algortithm for <data> elements with text content as the direct substitution of the state of the IDL 'textContent' attribute.<br />
# Define the rendering algortithm for <data> elements without text content as the substitution of the state of the 'value' attribute after conversion through the application of the element's resolved locale to the formatting rules defined in the Unicode Common Locale Data Repository (CLDR).<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* Data is annotated with specific known types<br />
<br />
* Data can be accessed using simple DOM functions<br />
<br />
* Consumers are protected from invalid values or needing to manipulate text encodings<br />
<br />
* Allows for automatic user agent substitution of formatting of data values with client-side localization<br />
<br />
* The &lt;output&gt; element may perform automatic transliteration of data type values from &lt;input&gt; values with restriction and validation<br />
<br />
* Allows for greater specificity and control over the denominations of date and time information currently afforded to the &lt;time&gt; element and its proposed extensions<br />
<br />
=== Negative Effects ===<br />
<br />
* Introduces a value type which is independent of the external declaration of data markup technologies, however since all values are currently interpreted as text this offers an additional level of validation and integrity available prior to external data interpretation<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance as specified in the changes described in "Details" section<br />
<br />
=== Risks ===<br />
<br />
* As the addition of new features and the application of as type system as value restriction over value expression the risks of introducing this feature set is limited to future development and deployments<br />
<br />
== References ==<br />
<br />
* ISSUE-184: Add a data element [http://www.w3.org/html/wg/tracker/issues/184]<br />
<br />
* Tantekelik's propsal for ISSUE-184 [http://www.w3.org/wiki/User:Tantekelik/data_element]<br />
<br />
* Unicode Common Locale Data Repository (CLDR) [http://cldr.unicode.org/]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-184&diff=58907User:Cjones/ISSUE-1842012-05-11T22:04:23Z<p>Cjones: Updated with changes in response to chair review</p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
= Change Proposal for ISSUE-184: Enhance the &lt;data&gt; element with a type system =<br />
<br />
== Summary ==<br />
<br />
This is a supplementary proposal for the resolution of ISSUE-184 which defines the addition of the &lt;data&gt; element.<br />
<br />
This proposal enhances the &lt;data&gt; element with a "type" attribute for discriminating the class of data represented by the value attribute or the contained element contents.<br />
<br />
The valid values for the "type" attribute are an enumerated set of keywords initially relating to a sub-set of the values currently accepted for the &lt;input&gt; element.<br />
<br />
This proposal also includes the addition of the "type" attribute to the &lt;output&gt; element for "typed" values to be represented by this element in order to provide style formatting across elements in a predictable and complementary manner.<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The addition of the &lt;data&gt; element allows for the semantic markup of machine readable data. The definition of this element only contains the "value" attribute in addition to the set of global element attributes. This exhibits a lack of definition as to what the &lt;data&gt; element represents and how it can be interpreted or should be used.<br />
<br />
=== Type Definition ===<br />
<br />
The contents of the &lt;data&gt; element is a text-format representation of the machine readable data. While this text could be parsable it is highly ambiguous and can not be used to definitely acquire the value or type of data.<br />
<br />
The "value" attribute of the &lt;data&gt; element is the text-encoded representation of the data information, however there are numerous types of data represented by the &lt;data&gt; element and there is significant scope for overlap within text-encodings. This leaves the problem of what the value represents and how to use it.<br />
<br />
The "type" attribute solves this problem by providing the necessary definition to the value in order that it can be converted into a binary representation for machine processing.<br />
<br />
=== Value Integrity ===<br />
<br />
The addition of a type attribute for data values introduces a set of constraints over the valid values that the element may represent. This provides the ability for the value to be restricted to a known data type which can be enforced within the HTML client. This provides the benefit that data values can be used programatically in a safe manner where data can be accessed without having to handle invalid values or manipulate encodings. <br />
<br />
=== Value Formatting ===<br />
<br />
The value of the &lt;data&gt; element is required to be displayed to the user as part of the HTML document rendering. The &lt;data&gt; element caters for customization through the ability for an author to declare the text content of an element and for that value to be the text which is displayed to the user. This process is orchistrated by the HTML client which, in the absence of text content, will process the label by direct substitution of the data value. <br />
<br />
With the addition of a type attribute, this process can be enhanced to allow the client to render the value to a format defined through the type discriminator and the element's resolved locale. This allows for HTML documents to be created for both machine readability and client-localization for the automated translation into formats that adhere to the cultural conventions of the user. This support is currently only afforded to &lt;input&gt; elements and otherwise results in semi-translation within a HTML document which is confusing and error prone for users.<br />
<br />
=== Input &amp; Output Elements ===<br />
<br />
From the introduction of a set of type-classes into the HTML vocabulary, the scope for the application of these types can naturally be extended to the other data-related elements &lt;input&gt; and &lt;output&gt;. These elements represent the means for user-interaction over data and are subject to the same requirements of data integrity and format representation.<br />
<br />
The &lt;output&gt; element additionally benifits from this extension as it can be explicity tied to &lt;input&gt; element value's and their modification events. This process is enhanced through the addition of the type system as it allows for the values to be restricted or converted into specific types and for this to be constrained and controlled within the HTML client. <br />
<br />
== Details ==<br />
<br />
# Add the "type" attribute to the &lt;data&gt; and &lt;output&gt; elements<br />
# Define the valid states for the "type" attribute for these elements as a set of enumerated values based a sub-set of valid states for the &lt;input&gt; element: text, tel, url, email, datetime, date, month, week, time, datetime-local, number, range, color<br />
# Define the default type for elements with un-set or unknown type attribute as 'text' state<br />
# Define the value of the element as the resolution of its value through the application of the corresponding HTML microsyntax<br />
# Define the rendering algortithm for <data> elements with text content as the direct substitution of the state of the IDL 'textContent' attribute.<br />
# Define the rendering algortithm for <data> elements without text content as the substitution of the state of the 'value' attribute after conversion through the application of the element's resolved locale to the formatting rules defined in the Unicode Common Locale Data Repository (CLDR).<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* The &lt;data&gt; element allows authors to markup machine readable information<br />
<br />
* The "type" attribute allows for automatic user agent substitution of formatting of data values with client-side localization<br />
<br />
* The contents of the &lt;data&gt; element allows for a label-override for specific value representation<br />
<br />
* The &lt;output&gt; element may perform automatic transliteration of data type values from &lt;input&gt; values with restriction and validation<br />
* Allows for greater specificity and control over the denominations of date and time information currently afforded to the &lt;time&gt; element and its proposed extensions<br />
<br />
* Simplifies implementations by introducing a type system across elements protecting otherwise text-only data from invalid values and the resulting benefits that type guarantees have for scripting and value-consumers<br />
<br />
=== Negative Effects ===<br />
<br />
* Introduces a value type which is independent of the external declaration of data markup technologies, however since all values are currently interpreted as text this offers an additional level of validation and integrity available prior to external data interpretation<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance as specified in the changes described in "Details" section<br />
<br />
=== Risks ===<br />
<br />
* As the addition of new features and the application of as type system as value restriction over value expression the risks of introducing this feature set is limited to future development and deployments<br />
<br />
== References ==<br />
<br />
* ISSUE-184: Add a data element [http://www.w3.org/html/wg/tracker/issues/184]<br />
<br />
* Tantekelik's propsal for ISSUE-184 [http://www.w3.org/wiki/User:Tantekelik/data_element]<br />
<br />
* Unicode Common Locale Data Repository (CLDR) [http://cldr.unicode.org/]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-183&diff=57817User:Cjones/ISSUE-1832012-04-11T20:24:04Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= Change Proposal for ISSUE-183: Drop the &lt;time&gt; element =<br />
<br />
== Summary ==<br />
<br />
This is a counter-proposal to the enhancement of the &lt;time&gt; element advocated for resolution of ISSUE-183.<br />
<br />
This proposal recommends the removal of the &lt;time&gt; element from HTML5 through the addition of the &lt;data&gt; element as its replacement with a "type" attribute for discrimination over values as proposed in the supplementary proposal for the resolution of ISSUE-184 [5].<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rationale for this proposal examines the definition of the &lt;time&gt; element in its ability to represent date and time information and compares this with the alternate solution of a generic &lt;data&gt; element. <br />
<br />
=== Element Granularity ===<br />
<br />
The &lt;time&gt; and &lt;data&gt; elements represent the semantic markup of machine readable information on alternate levels of graduation. <br />
<br />
The &lt;data&gt; element is a generic element which is semantically capable of representing any type of primitive or elementary data within documents and provides this capability in a universal manner which is irrespective of the type of data. This primitive data is able to be compounded into complex data types through the application of data markup technologies.<br />
<br />
The &lt;time&gt; element is semantically targeted at a lower level of granularity with the explicit restriction of its capacity to representing only date and time information. This satisfies the immediate requirement for this ability, however by targeting semantic tags at this level the future considerations of new and additional data types is both unaddressed yet the semantic precedence is set to promote the addition of new elements as the solution.<br />
<br />
There are a number of new data types which are not representable at present for which there has been requirement to cater for, including: "location", "color", "currency", "telephone", "number" etc. The implementation of these using the approach applied to date and time information with new elements would represent a significant addition to the specification with the only benefit being to authors who find semantic element names more memorable than semantic attribute names. This is due to all of these elements sharing the same identical use case and purpose which is for marking up elementary machine-readable data.<br />
<br />
The means for marking up data using a &lt;data&gt; element represents a scalable solution to this problem by allowing for new data types to be added without the need for them to be defined and implemented through the specification of new elements and satisfies the use case succinctly with a single element fit for purpose.<br />
<br />
=== Discrimination of Denominations ===<br />
<br />
The &lt;time&gt; element consists of an attribute definition "datetime" which holds the machine-readable data value and the contents of the element, if present, is defined to be the label. The specification of &lt;time&gt; allows for numerous denominations (year, month, date, etc) to be represented within this element however the means for defining the denomination of this value is defined through the syntax of the "datetime" attribute. <br />
<br />
This has the impact that the denomination of the date\time value can not be simply identified and must be resolved through the resolution of HTML microsyntax. <br />
<br />
This affects document generation systems which are unable to work direct with standard machine readable encodings and must mutate these encodings by applying the microsyntax rules instead of using the simpler and less error prone approach of an enumerated type discriminator for denoting the denomination over date\time encodings. <br />
<br />
This also affects document consumers or scripts which are unable to lookup dates and times within a document by enumerated discriminator and instead must resolve these manually through the application of the HTML microsyntax algorithm.<br />
<br />
The approach used by &lt;time&gt; is divergent from that used within the &lt;input&gt; element and its use of type discrimination through enumerated attribute values. This represents a conceptual overloading of syntactical implementation which complicates the HTML model and does not leverage the opportunity for a reduction in conceptual complexity.<br />
<br />
The lack of type discrimination within &lt;time&gt; also represents a limitation in the flexibility of the potential denominations as type resolution is deferred to the encoding syntax. This places a direct correlation between the flexibility of the encoding to the distinction of type limiting the potential for satisfying future requirements and resulting in certain date and time values being unrepresentable within the element. For example, this can be seen through the lack of ability of the &lt;time&gt; element and its microsyntax from being able to represent abstract dates and times due to them being unrepresentable and inextensible in the microsyntax.<br />
<br />
This problem is not encountered in the implementation of &lt;data&gt; with a type discriminator attribute which, in addition to supporting all the date and time denominations currently afforded to &lt;time&gt; and &lt;input&gt;, also leaves scope for the extension of new denominations using newly defined discriminations and allows for denominations to be marked up and looked up through simple enumerated values.<br />
<br />
=== Duplication of Declarative Functionality (DRY Principle) ===<br />
<br />
The addition of the &lt;data&gt; element provides the necessary method to markup machine readable data within HTML documents. This renders the &lt;time&gt; element obsolete by means of duplication of declarative functionality as all types and values which can be encoded within &lt;time&gt; can also be encoded within &lt;data&gt;.<br />
<br />
The proposal for retaining &lt;time&gt; does not specify for &lt;data&gt; to be omitted, so as &lt;data&gt; is capable of representing all date\time types and values, the inclusion of both methods will invariably result in both being used by authors due to confusion arising from duplication and\or due the simplicity of programatically generating all data types using a single element construct. <br />
<br />
This is expected to be encountered in documents produced for proprietary machine consumption where priority is given to the simplicity of internal application communication over 3rd party consumption and standards compliance.<br />
<br />
=== Data Rendering with Localization and Formatting ===<br />
<br />
The use case for the addition of &lt;time&gt;, and by extension &lt;data&gt;, is that of data representation within documents. This requirement not only represents the ability for data values to be encoded and consumed but also for them to be interfaced by the browser. <br />
<br />
The interfacing over data, like form fields, is relatively under specified at present due to the deferment to implementation which provides the necessary exploration and definition for specification and design. The requirements for this are evident through the extrapolation from the needs of authors and users to represent and restrict variation required for serving the user base encompassing all countries, languages and preference.<br />
<br />
The means for delivering this functionality is dependent on a number of factors which are represented with markup - the data value, the locale\language and author customization or configuration.<br />
<br />
The complexity in delivering this functionality is due to the intersection between the otherwise distinct separation between model and style within HTML and CSS. <br />
<br />
This proposal does not provide a solution herein, however the use of &lt;data&gt; instead of &lt;time&gt; represents a simplification of the problem through the limitation of scope to a single element instead of being dispersed across multiple element definitions. In addition, the synchronicity between the implementation of discrimination type attributes in &lt;data&gt; and &lt;input&gt; elements provides the means to define a universal solution across synonymous data-driven elements which share an identical type system with localization and formatting declarations for external stylesheet customization.<br />
<br />
<br />
== Details ==<br />
<br />
# Remove the &lt;time&gt; element and all associated attributes<br />
# Apply the changes required by extending the &lt;data&gt; element with a type attribute from the supplementary proposal to ISSUE-184 [5]<br />
# Define the valid states for the &lt;data&gt; element "type" attribute for date and time types as: year, month, week, date, time, datetime, datetime-local<br />
# Define the machine readable value of a &lt;data&gt; element with a date\time type as the value derived through the application of the corresponding HTML microsyntax in section ''2.5.5 Dates and times''.<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* The method for marking up data information is simple, generic and universal<br />
* The expressiveness of the <time> element is retained<br />
* The ability to extend the markup of date\time information is available<br />
* HTML is not bloated with numerous elements all for the same use case and purpose<br />
* Automated document generation machines can generate data markup using a single method in standard ISO date\time encodings instead of manipulating encodings for denomination identification through the HTML microsyntax <br />
* Scripts and document consumers can lookup value denominations by enumerated discriminator instead of introspecting using the application of HTML microsyntax<br />
* The negative impacts of violating DRY principals are eliminated<br />
* The development of localization and CSS style and formatting rules for data is not imposed with divergent elements and undue complexity<br />
<br />
=== Negative Effects ===<br />
<br />
* Experimental uses of &lt;time&gt; are rendered obsolete and require updating. Since these authors are ahead of the curve they are aware of the potential that changes may occur. The upgrade path is simple requiring only substitution of element name and may encourage these authors to extend their support of &lt;data&gt; to more use cases improving the corpus of machine readable data on the web.<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* &lt;time&gt; is non-conformant element<br />
* Conformance Class Changes required to support the addition of the &lt;data&gt; element and a "type" discriminator attribute [5]<br />
<br />
=== Risks ===<br />
<br />
* None identified<br />
<br />
== References ==<br />
<br />
* ISSUE-183: Enhance and simplify the time element [http://www.w3.org/html/wg/tracker/issues/183]<br />
<br />
* Tantek's propsal for ISSUE-183 [http://www.w3.org/wiki/User:Tantekelik/time_element]<br />
<br />
* ISSUE-184: Add a data element [http://www.w3.org/html/wg/tracker/issues/184]<br />
<br />
* Tantek's propsal for ISSUE-184 [http://www.w3.org/wiki/User:Tantekelik/data_element]<br />
<br />
* CJones' supplementary counter-proposal for ISSUE-184 [http://www.w3.org/wiki/User:Cjones/ISSUE-184]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-183&diff=57815User:Cjones/ISSUE-1832012-04-11T20:14:41Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= Change Proposal for ISSUE-183: Drop the &lt;time&gt; element =<br />
<br />
== Summary ==<br />
<br />
This is a counter-proposal to the enhancement of the &lt;time&gt; element advocated for resolution of ISSUE-183.<br />
<br />
This proposal recommends the removal of the &lt;time&gt; element from HTML5 through the addition of the &lt;data&gt; element as its replacement with a "type" attribute for discrimination over values as proposed in the supplementary proposal for the resolution of ISSUE-184 [5].<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rationale for this proposal examines the definition of the &lt;time&gt; element in its ability to represent date and time information and compares this with the alternate solution of a generic &lt;data&gt; element. <br />
<br />
=== Element Granularity ===<br />
<br />
The &lt;time&gt; and &lt;data&gt; elements represent the semantic markup of machine readable information on alternate levels of graduation. <br />
<br />
The &lt;data&gt; element is a generic element which is semantically capable of representing any type of primitive or elementary data within documents and provides this capability in a universal manner which is irrespective of the type of data. This primitive data is able to be compounded into complex data types through the application of data markup technologies.<br />
<br />
The &lt;time&gt; element is semantically targeted at a lower level of granularity with the explicit restriction of its capacity to representing only date and time information. This satisfies the immediate requirement for this ability, however by targeting semantic tags at this level the future considerations of new and additional data types is both unaddressed yet the semantic precedence is set to promote the addition of new elements as the solution.<br />
<br />
There are a number of new data types which are not representable at present for which there has been requirement to cater for, including: "location", "color", "currency", "telephone", "number" etc. The implementation of these using the approach applied to date and time information with new elements would represent a significant addition to the specification with the only benefit being to authors who find semantic element names more memorable than semantic attribute names. This is due to all of these elements sharing the same identical use case and purpose which is for marking up elementary machine-readable data.<br />
<br />
The means for marking up data using a &lt;data&gt; element represents a scalable solution to this problem by allowing for new data types to be added without the need for them to be defined and implemented through the specification of new elements and satisfies the use case succinctly with a single element fit for purpose.<br />
<br />
=== Discrimination of Denominations ===<br />
<br />
The &lt;time&gt; element consists of an attribute definition "datetime" which holds the machine-readable data value and the contents of the element, if present, is defined to be the label. The specification of &lt;time&gt; allows for numerous denominations (year, month, date, etc) to be represented within this element however the means for defining the denomination of this value is defined through the syntax of the "datetime" attribute. <br />
<br />
This has the impact that the denomination of the date\time value can not be simply identified and must be resolved through the resolution of HTML microsyntax. <br />
<br />
This affects document generation systems which are unable to work direct with standard machine readable encodings and must mutate these encodings by applying the microsyntax rules instead of using the simpler and less error prone approach of an enumerated type discriminator for denoting the denomination over date\time encodings. <br />
<br />
This also affects document consumers or scripts which are unable to lookup dates and times within a document by enumerated discriminator and instead must resolve these manually through the application of the HTML microsyntax algorithm.<br />
<br />
The approach used by &lt;time&gt; is divergent from that used within the &lt;input&gt; element and its use of type discrimination through enumerated attribute values. This represents a conceptual overloading of syntactical implementation which complicates the HTML model and does not leverage the opportunity for a reduction in conceptual complexity.<br />
<br />
The lack of type discrimination within &lt;time&gt; also represents a limitation in the flexibility of the potential denominations as type resolution is deferred to the encoding syntax. This places a direct correlation between the flexibility of the encoding to the distinction of type limiting the potential for satisfying future requirements and resulting in certain date and time values being unrepresentable within the element. For example, this can be seen through the lack of ability of the &lt;time&gt; element and its microsyntax from being able to represent abstract dates and times due to them being unrepresentable and inextensible in the microsyntax.<br />
<br />
This problem is not encountered in the implementation of &lt;data&gt; with a type discriminator attribute which, in addition to supporting all the date and time denominations currently afforded to &lt;time&gt; and &lt;input&gt;, also leaves scope for the extension of new denominations using newly defined discriminations and allows for denominations to be marked up and looked up through simple enumerated values.<br />
<br />
=== Duplication of Declarative Functionality (DRY Principle) ===<br />
<br />
The addition of the &lt;data&gt; element provides the necessary method to markup machine readable data within HTML documents. This renders the &lt;time&gt; element obsolete by means of duplication of declarative functionality as all types and values which can be encoded within &lt;time&gt; can also be encoded within &lt;data&gt;.<br />
<br />
The proposal for retaining &lt;time&gt; does not specify for &lt;data&gt; to be omitted, so as &lt;data&gt; is capable of representing all date\time types and values, the inclusion of both methods will invariably result in both being used by authors due to confusion arising from duplication and\or due the simplicity of programatically generating all data types using a single element construct. <br />
<br />
This is expected to be encountered in documents produced for proprietary machine consumption where priority is given to the simplicity of internal application communication over 3rd party consumption and standards compliance.<br />
<br />
=== Data Rendering with Localization and Formatting ===<br />
<br />
The use case for the addition of &lt;time&gt;, and by extension &lt;data&gt;, is that of data representation within documents. This requirement not only represents the ability for data values to be encoded and consumed but also for them to be interfaced by the browser. <br />
<br />
The interfacing over data, like form fields, is relatively under specified at present due to the deferment to implementation which provides the necessary exploration and definition for specification and design. The requirements for this are evident through the extrapolation from the needs of authors and users to represent and restrict variation required for serving the user base encompassing all countries, languages and preference.<br />
<br />
The means for delivering this functionality is dependent on a number of factors which are represented with markup - the data value, the locale\language and author customization or configuration.<br />
<br />
The complexity in delivering this functionality is due to the intersection between the otherwise distinct separation between model and style within HTML and CSS. <br />
<br />
This proposal does not provide a solution herein, however the use of &lt;data&gt; instead of &lt;time&gt; represents a simplification of the problem through the limitation of scope to a single element instead of being dispersed across multiple element definitions. In addition, the synchronicity between the implementation of discrimination type attributes in &lt;data&gt; and &lt;input&gt; elements provides the means to define a universal solution across synonymous data-driven elements which share an identical type system with localization and formatting declarations for external stylesheet customization.<br />
<br />
<br />
== Details ==<br />
<br />
# Remove the &lt;time&gt; element and all associated attributes<br />
# Apply the changes required by extending the &lt;data&gt; element with a type attribute from the supplementary proposal to ISSUE-184 [5]<br />
# Define the valid states for the &lt;data&gt; element "type" attribute for date and time types as: year, month, week, date, time, datetime, datetime-local<br />
# Define the machine readable value of a &lt;data&gt; element with a date\time type as the value derived through the application of the corresponding HTML microsyntax in section ''2.5.5 Dates and times''.<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* The method for marking up data information is simple, generic and universal<br />
* The expressiveness of the <time> element is retained<br />
* The ability to extend the markup of date\time information is available<br />
* HTML is not bloated with numerous elements all for the same use case and purpose<br />
* Automated document generation machines can generate data markup using a single method in standard ISO date\time encodings instead of manipulating encodings for denomination identification through the HTML microsyntax <br />
* Scripts and document consumers can lookup value denominations by enumerated discriminator instead of introspecting using the application of HTML microsyntax<br />
* The negative impacts of violating DRY principals are eliminated<br />
* The development of localization and CSS style and formatting rules for data is not imposed with divergent elements and undue complexity restricting the ability for defining a universal method<br />
<br />
=== Negative Effects ===<br />
<br />
* Experimental uses of &lt;time&gt; are rendered obsolete and require updating. Since these authors are ahead of the curve they are aware of the potential that changes may occur. The upgrade path is simple requiring only substitution of element name and may encourage these authors to extend their support of &lt;data&gt; to more use cases improving the corpus of machine readable data on the web.<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* &lt;time&gt; is non-conformant element<br />
* Conformance Class Changes required to support the addition of the &lt;data&gt; element and a "type" discriminator attribute [5]<br />
<br />
=== Risks ===<br />
<br />
* None identified<br />
<br />
== References ==<br />
<br />
* ISSUE-183: Enhance and simplify the time element [http://www.w3.org/html/wg/tracker/issues/183]<br />
<br />
* Tantek's propsal for ISSUE-183 [http://www.w3.org/wiki/User:Tantekelik/time_element]<br />
<br />
* ISSUE-184: Add a data element [http://www.w3.org/html/wg/tracker/issues/184]<br />
<br />
* Tantek's propsal for ISSUE-184 [http://www.w3.org/wiki/User:Tantekelik/data_element]<br />
<br />
* CJones' supplementary counter-proposal for ISSUE-184 [http://www.w3.org/wiki/User:Cjones/ISSUE-184]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-183&diff=57813User:Cjones/ISSUE-1832012-04-11T20:04:20Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= Change Proposal for ISSUE-183: Drop the &lt;time&gt; element =<br />
<br />
== Summary ==<br />
<br />
This is a counter-proposal to the enhancement of the &lt;time&gt; element advocated for resolution of ISSUE-183.<br />
<br />
This proposal recommends the removal of the &lt;time&gt; element from HTML5 through the addition of the &lt;data&gt; element as its replacement with a "type" attribute for discrimination over values as proposed in the supplementary proposal for the resolution of ISSUE-184 [5].<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rationale for this proposal examines the definition of the &lt;time&gt; element in its ability to represent date and time information and compares this with the alternate solution of a generic &lt;data&gt; element. <br />
<br />
=== Element Granularity ===<br />
<br />
The &lt;time&gt; and &lt;data&gt; elements represent the semantic markup of machine readable information on alternate levels of graduation. <br />
<br />
The &lt;data&gt; element is a generic element which is semantically capable of representing any type of primitive or elementary data within documents and provides this capability in a universal manner which is irrespective of the type of data. This primitive data is able to be compounded into complex data types through the application of data markup technologies.<br />
<br />
The &lt;time&gt; element is semantically targeted at a lower level of granularity with the explicit restriction of its capacity to representing only date and time information. This satisfies the immediate requirement for this ability, however by targeting semantic tags at this level the future considerations of new and additional data types is both unaddressed yet the semantic precedence is set to promote the addition of new elements as the solution.<br />
<br />
There are a number of new data types which are not representable at present for which there has been requirement to cater for, including: "location", "color", "currency", "telephone", "number" etc. The implementation of these using the approach applied to date and time information with new elements would represent a significant addition to the specification with the only benefit being to authors who find semantic element names more memorable than semantic attribute names. This is due to all of these elements sharing the same identical use case and purpose which is for marking up elementary machine-readable data.<br />
<br />
The means for marking up data using a &lt;data&gt; element represents a scalable solution to this problem by allowing for new data types to be added without the need for them to be defined and implemented through the specification of new elements and satisfies the use case succinctly with a single element fit for purpose.<br />
<br />
=== Discrimination of Denominations ===<br />
<br />
The &lt;time&gt; element consists of an attribute definition "datetime" which holds the machine-readable data value and the contents of the element, if present, is defined to be the label. The specification of &lt;time&gt; allows for numerous denominations (year, month, date, etc) to be represented within this element however the means for defining the denomination of this value is defined through the syntax of the "datetime" attribute. <br />
<br />
This has the impact that the denomination of the date\time value can not be simply identified and must be resolved through the resolution of HTML microsyntax. <br />
<br />
This affects document generation systems which are unable to work direct with standard machine readable encodings and must mutate these encodings by applying the microsyntax rules instead of using the simpler and less error prone approach of an enumerated type discriminator for denoting the denomination over date\time encodings. <br />
<br />
This also affects document consumers or scripts which are unable to lookup dates and times within a document by enumerated discriminator and instead must resolve these manually through the application of the HTML microsyntax algorithm.<br />
<br />
The approach used by &lt;time&gt; is divergent from that used within the &lt;input&gt; element and its use of type discrimination through enumerated attribute values. This represents a conceptual overloading of syntactical implementation which complicates the HTML model and does not leverage the opportunity for a reduction in conceptual complexity.<br />
<br />
The lack of type discrimination within &lt;time&gt; also represents a limitation in the flexibility of the potential denominations as type resolution is deferred to the encoding syntax. This places a direct correlation between the flexibility of the encoding to the distinction of type limiting the potential for satisfying future requirements and resulting in certain date and time values being unrepresentable within the element. For example, this can be seen through the lack of ability of the &lt;time&gt; element and its microsyntax from being able to represent abstract dates and times due to them being unrepresentable and inextensible in the microsyntax.<br />
<br />
This problem is not encountered in the implementation of &lt;data&gt; with a type discriminator attribute which, in addition to supporting all the date and time denominations currently afforded to &lt;time&gt; and &lt;input&gt;, also leaves scope for the extension of new denominations using newly defined discriminations and allows for denominations to be marked up and looked up through simple enumerated values.<br />
<br />
=== Duplication of Declarative Functionality (DRY Principle) ===<br />
<br />
The addition of the &lt;data&gt; element provides the necessary method to markup machine readable data within HTML documents. This renders the &lt;time&gt; element obsolete by means of duplication of declarative functionality as all types and values which can be encoded within &lt;time&gt; can also be encoded within &lt;data&gt;.<br />
<br />
The proposal for retaining &lt;time&gt; does not specify for &lt;data&gt; to be omitted, so as &lt;data&gt; is capable of representing all date\time types and values, the inclusion of both methods will invariably result in both being used by authors due to confusion arising from duplication and\or due the simplicity of programatically generating all data types using a single element construct. <br />
<br />
This is expected to be encountered in documents produced for proprietary machine consumption where priority is given to the simplicity of internal application communication over 3rd party consumption and standards compliance.<br />
<br />
=== Data Rendering with Localization and Formatting ===<br />
<br />
The use case for the addition of &lt;time&gt;, and by extension &lt;data&gt;, is that of data representation within documents. This requirement not only represents the ability for data values to be encoded and consumed but also for them to be interfaced by the browser. <br />
<br />
The interfacing over data, like form fields, is relatively under specified at present due to the deferment to implementation which provides the necessary exploration and definition for specification and design. The requirements for this are evident through the extrapolation from the needs of authors and users to represent and restrict variation required for serving a user base encompassing all countries, languages and preference.<br />
<br />
The means for delivering this functionality is dependent on a number of factors which are represented with markup - the data value, the locale\language and author customization or configuration.<br />
<br />
The complexity in delivering this functionality is due to the intersection between the otherwise distinct separation between model and style within HTML and CSS. <br />
<br />
This proposal does not provide a solution herein, however the use of &lt;data&gt; instead of &lt;time&gt; represents a simplification of the problem through the limitation of scope to a single element instead of being dispersed across multiple element definitions. In addition, the synchronicity between the implementation of discrimination type attributes in &lt;data&gt; and &lt;input&gt; elements provides the means to define and deliver a solution which is universal across synonymous data-driven elements which share an identical type system with localization and formatting declarations for external stylesheet customization.<br />
<br />
<br />
== Details ==<br />
<br />
# Remove the &lt;time&gt; element and all associated attributes<br />
# Apply the changes required by extending the &lt;data&gt; element with a type attribute from the supplementary proposal to ISSUE-184 [5]<br />
# Define the valid states for the &lt;data&gt; element "type" attribute for date and time types as: year, month, week, date, time, datetime, datetime-local<br />
# Define the machine readable value of a &lt;data&gt; element with a date\time type as the value derived through the application of the corresponding HTML microsyntax in section ''2.5.5 Dates and times''.<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* The method for marking up data information is simple, generic and universal<br />
* The expressiveness of the <time> element is retained<br />
* The ability to extend the markup of date\time information is available<br />
* HTML is not bloated with numerous elements all targeting the same use case and purpose<br />
* Automated document generation machines can generate data markup using a single method and standard ISO date\time encodings instead of needing to manipulate the encoding for denomination identification through the HTML microsyntax <br />
* Scripts and document consumers can lookup value denominations by enumerated discriminator instead of requiring introspection through the application of HTML microsyntax<br />
* The negative impacts of violating DRY principals are eliminated<br />
* The development of localization and CSS style and formatting rules for data is not imposed with divergent elements and undue complexity restricting the ability for defining a universal method<br />
<br />
=== Negative Effects ===<br />
<br />
* Experimental uses of &lt;time&gt; are rendered obsolete and require updating. Since these authors are ahead of the curve they are aware of the potential that changes may occur. The upgrade path is simple requiring only substitution of element name and may encourage these authors to extend their support of &lt;data&gt; to more use cases improving the corpus of machine readable data on the web.<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* &lt;time&gt; is non-conformant element<br />
* Conformance Class Changes required to support the addition of the &lt;data&gt; element and a "type" discriminator attribute [5]<br />
<br />
=== Risks ===<br />
<br />
* None identified<br />
<br />
== References ==<br />
<br />
* ISSUE-183: Enhance and simplify the time element [http://www.w3.org/html/wg/tracker/issues/183]<br />
<br />
* Tantek's propsal for ISSUE-183 [http://www.w3.org/wiki/User:Tantekelik/time_element]<br />
<br />
* ISSUE-184: Add a data element [http://www.w3.org/html/wg/tracker/issues/184]<br />
<br />
* Tantek's propsal for ISSUE-184 [http://www.w3.org/wiki/User:Tantekelik/data_element]<br />
<br />
* CJones' supplementary counter-proposal for ISSUE-184 [http://www.w3.org/wiki/User:Cjones/ISSUE-184]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-183&diff=57803User:Cjones/ISSUE-1832012-04-11T15:57:53Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= Change Proposal for ISSUE-183: Drop the &lt;time&gt; element =<br />
<br />
== Summary ==<br />
<br />
This is a counter-proposal to the enhancement of the &lt;time&gt; element advocated for resolution of ISSUE-183.<br />
<br />
This proposal recommends the removal of the &lt;time&gt; element from HTML5 through the addition of the &lt;data&gt; element as its replacement with a "type" attribute for discrimination over values as proposed in the supplementary proposal for the resolution of ISSUE-184 [5].<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rationale for this proposal examines the definition of the &lt;time&gt; element in its ability to represent date and time information and compares this with the alternate solution of a generic &lt;data&gt; element. <br />
<br />
=== Element Granularity ===<br />
<br />
The &lt;time&gt; and &lt;data&gt; elements represent the semantic markup of machine readable information on alternate levels of graduation. <br />
<br />
The &lt;data&gt; element is a generic element which is semantically capable of representing any type of primitive or elementary data within documents and provides this capability in a universal manner which is irrespective of the type of data. This primitive data is able to be compounded into complex data types through the application of data markup technologies.<br />
<br />
The &lt;time&gt; element is semantically targeted at a lower level of granularity with the explicit restriction of its capacity to representing only date and time information. This satisfies the immediate requirement for this ability, however by targeting semantic tags at this level the future considerations of new and additional data types is both unaddressed yet the semantic precedence is set to promote the addition of new elements as the solution.<br />
<br />
There are a number of new data types which are not representable at present for which there has been requirement to cater for, including: "location", "color", "currency", "telephone", "number" etc. The implementation of these using the approach applied to date and time information with new elements would represent a significant addition to the specification with the only benefit being to authors who find semantic element names more memorable than semantic attribute names. This is due to all of these elements sharing the same identical use case and purpose which is for marking up elementary machine-readable data.<br />
<br />
The means for marking up data using a &lt;data&gt; element represents a scalable solution to this problem by allowing for new data types to be added without the need for them to be defined and implemented through the specification of new elements and satisfies the use case succinctly with a single element fit for purpose.<br />
<br />
=== Discrimination of Denominations ===<br />
<br />
The &lt;time&gt; element consists of an attribute definition "datetime" which holds the machine-readable data value and the contents of the element, if present, is defined to be the label. The specification of &lt;time&gt; allows for numerous denominations (year, month, date, etc) to be represented within this element however the means for defining the denomination of this value is defined through the syntax of the "datetime" attribute. <br />
<br />
This has the impact that the denomination of the date\time value can not be simply identified and must be resolved through the resolution of HTML microsyntax. <br />
<br />
This affects document generation systems which are unable to work direct with standard machine readable encodings and must mutate these encodings by applying the microsyntax rules instead of using the simpler and less error prone approach of an enumerated type discriminator for denoting the denomination over date\time encodings. <br />
<br />
This also affects document consumers or scripts which are also unable to lookup dates and times within a document by enumerated discriminator and instead must resolve these manually through the application of the HTML microsyntax algorithm.<br />
<br />
The approach used by &lt;time&gt; is divergent from that used within the &lt;input&gt; element and its use of type discrimination through enumerated attribute values. This represents a conceptual overloading of syntactical implementation which complicates the HTML model and does not leverage the opportunity for a reduction in conceptual complexity.<br />
<br />
The lack of type discrimination within &lt;time&gt; also represents a limitation in the flexibility of the potential denominations as type resolution is deferred to the encoding syntax. This places a direct correlation between the flexibility of the encoding to the distinction of type limiting the potential for satisfying future requirements and resulting in certain date and time values being unrepresentable within the element. For example, this can be seen through the lack of ability of the &lt;time&gt; element and its microsyntax from being able to represent abstract dates and times due to them being unrepresentable and inextensible in the microsyntax.<br />
<br />
This problem is not encountered in the implementation of &lt;data&gt; with a type discriminator attribute which, in addition to supporting all the date and time denominations currently afforded to &lt;time&gt; and &lt;input&gt;, also leaves scope for the extension of new denominations using newly defined discriminations and allows for denominations to be marked up and looked up through simple enumerated values.<br />
<br />
=== Duplication of Declarative Functionality (DRY Principle) ===<br />
<br />
The addition of the &lt;data&gt; element provides the necessary method to markup machine readable data within HTML documents. This renders the &lt;time&gt; element obsolete by means of duplication of declarative functionality as all types and values which can be encoded within &lt;time&gt; can also be encoded within &lt;data&gt;.<br />
<br />
The proposal for retaining &lt;time&gt; does not specify for &lt;data&gt; to be omitted, and as &lt;data&gt; is capable of representing all date\time types and values, the inclusion of both methods will invariably result in both being used by authors due to confusion arising form duplication and\or due the simplicity of programatically generating all data types using a single element construct. <br />
<br />
This is expected to be encountered especially in the case of documents produced for proprietary machine consumption where priority is given to the simplicity of internal application communication over 3rd party public consumption and standards compliance.<br />
<br />
=== Data Rendering with Localization and Formatting ===<br />
<br />
The use case for the addition of &lt;time&gt;, and by extension &lt;data&gt;, is that of data representation within documents. This requirement not only represents the ability for data values to be encoded and consumed but also for those values to be interfaced by the browser. <br />
<br />
The interfacing over data, like form fields, is relatively under specified at present due to the lack of implementation which would otherwise provide the necessary exploration and implication for specification and design. The requirements for this however are self evident through the extrapolation from the needs of authors and users to both represent and restrict the variation which is required for serving a user base which encompasses all countries, languages and preference.<br />
<br />
The means for delivering this functionality is dependent on a number of factors which are represented with markup - the data value, the locale\language and author customization or configuration.<br />
<br />
The complexity in delivering this functionality is due to the intersection between the otherwise distinct separation between model and style within HTML and CSS. <br />
<br />
While this proposal does not address this with a solution forthwith, the use of &lt;data&gt; instead of &lt;time&gt; represents a simplification of the problem through the limitation of scope to a single element instead of being dispersed across multiple element definitions. In addition, the synchronicity between the implementation of discrimination type attributes in &lt;data&gt; and &lt;input&gt; elements provides the means to define and deliver a solution which is universal across synonymous data-driven elements which share an identical type system with localization and formatting declarations for external stylesheet customization.<br />
<br />
<br />
== Details ==<br />
<br />
# Remove the &lt;time&gt; element and all associated attributes<br />
# Apply the changes required by extending the &lt;data&gt; element with a type attribute from the supplementary proposal to ISSUE-184 [5]<br />
# Define the valid states for the &lt;data&gt; element "type" attribute for date and time types as: year, month, week, date, time, datetime, datetime-local<br />
# Define the machine readable value of a &lt;data&gt; element with a date\time type as the value derived through the application of the corresponding HTML microsyntax in section ''2.5.5 Dates and times''.<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* The method for marking up data information is simple, generic and universal<br />
* The expressiveness of the <time> element is retained<br />
* The ability to extend the markup of date\time information is available<br />
* HTML is not bloated with numerous elements all targeting the same use case and purpose<br />
* Automated document generation machines can generate data markup using a single method and standard ISO date\time encodings instead of needing to manipulate the encoding for denomination identification through the HTML microsyntax <br />
* Scripts and document consumers can lookup value denominations by enumerated discriminator instead of requiring introspection through the application of HTML microsyntax<br />
* The negative impacts of violating DRY principals are eliminated<br />
* The development of localization and CSS style and formatting rules for data is not imposed with divergent elements and undue complexity restricting the ability for defining a universal method<br />
<br />
=== Negative Effects ===<br />
<br />
* Experimental uses of &lt;time&gt; are rendered obsolete and require updating. Since these authors are ahead of the curve they are aware of the potential that changes may occur. The upgrade path is simple requiring only substitution of element name and may encourage these authors to extend their support of &lt;data&gt; to more use cases improving the corpus of machine readable data on the web.<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* &lt;time&gt; is non-conformant element<br />
* Conformance Class Changes required to support the addition of the &lt;data&gt; element and a "type" discriminator attribute [5]<br />
<br />
=== Risks ===<br />
<br />
* None identified<br />
<br />
== References ==<br />
<br />
* ISSUE-183: Enhance and simplify the time element [http://www.w3.org/html/wg/tracker/issues/183]<br />
<br />
* Tantek's propsal for ISSUE-183 [http://www.w3.org/wiki/User:Tantekelik/time_element]<br />
<br />
* ISSUE-184: Add a data element [http://www.w3.org/html/wg/tracker/issues/184]<br />
<br />
* Tantek's propsal for ISSUE-184 [http://www.w3.org/wiki/User:Tantekelik/data_element]<br />
<br />
* CJones' supplementary counter-proposal for ISSUE-184 [http://www.w3.org/wiki/User:Cjones/ISSUE-184]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-183&diff=57802User:Cjones/ISSUE-1832012-04-11T15:51:10Z<p>Cjones: Updated Change Proposal with Review from HTML Chairs</p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= Change Proposal for ISSUE-183: Drop the &lt;time&gt; element =<br />
<br />
== Summary ==<br />
<br />
This is a counter-proposal to the enhancement of the &lt;time&gt; element advocated for resolution of ISSUE-183.<br />
<br />
This proposal recommends the removal of the &lt;time&gt; element from HTML5 through the addition of the &lt;data&gt; element as its replacement with a "type" attribute for discrimination over values as proposed in the supplementary proposal for the resolution of ISSUE-184 [5].<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rationale for this proposal examines the definition of the &lt;time&gt; element in its ability to represent date and time information and compares this with the alternate solution of a generic &lt;data&gt; element. <br />
<br />
=== Element Granularity ===<br />
<br />
The &lt;time&gt; and &lt;data&gt; elements represent the semantic markup of machine readable information on alternate levels of graduation. <br />
<br />
The &lt;data&gt; element is a generic element which is semantically capable of representing any type of primitive or elementary data within documents and provides this capability in a universal manner which is irrespective of the type of data. This primitive data is able to be compounded into complex data types through the application of data markup technologies.<br />
<br />
The &lt;time&gt; element is semantically targeted at a lower level of granularity with the explicit restriction of its capacity to representing only date and time information. This satisfies the immediate requirement for this ability, however by targeting semantic tags at this level the future considerations of new and additional data types is both unaddressed yet the semantic precedence is set to promote the addition of new elements as the solution.<br />
<br />
There are a number of new data types which are not representable at present for which there has been requirement to cater for, including: "location", "color", "currency", "telephone", "number", "unit" etc. The implementation of these using the approach applied to date and time information with new elements would represent a significant addition to the specification with the only benefit being to authors who find semantic element names more memorable than semantic attribute names. This is due to all of these elements sharing the same identical use case and purpose which is for marking up elementary machine-readable data.<br />
<br />
The means for marking up data using a &lt;data&gt; element represents a scalable solution to this problem by allowing for new data types to be added without the need for them to be defined and implemented through the specification of new elements and satisfies the use case succinctly with a single element fit for purpose.<br />
<br />
=== Discrimination of Denominations ===<br />
<br />
The &lt;time&gt; element consists of an attribute definition "datetime" which holds the machine-readable data value and the contents of the element, if present, is defined to be the label. The specification of &lt;time&gt; allows for numerous denominations (year, month, date, etc) to be represented within this element however the means for defining the denomination of this value is defined through the syntax of the "datetime" attribute. <br />
<br />
This has the impact that the denomination of the date\time value can not be simply identified and must be resolved through the resolution of HTML microsyntax. <br />
<br />
This affects document generation systems which are unable to work direct with standard machine readable encodings and must mutate these encodings by applying the microsyntax rules instead of using the simpler and less error prone approach of an enumerated type discriminator for denoting the denomination over date\time encodings. <br />
<br />
This also affects document consumers or scripts which are also unable to lookup dates and times within a document by enumerated discriminator and instead must resolve these manually through the application of the HTML microsyntax algorithm.<br />
<br />
The approach used by &lt;time&gt; is divergent from that used within the &lt;input&gt; element and its use of type discrimination through enumerated attribute values. This represents a conceptual overloading of syntactical implementation which complicates the HTML model and does not leverage the opportunity for a reduction in conceptual complexity.<br />
<br />
The lack of type discrimination within &lt;time&gt; also represents a limitation in the flexibility of the potential denominations as type resolution is deferred to the encoding syntax. This places a direct correlation between the flexibility of the encoding to the distinction of type limiting the potential for satisfying future requirements and resulting in certain date and time values being unrepresentable within the element. For example, this can be seen through the lack of ability of the &lt;time&gt; element and its microsyntax from being able to represent abstract dates and times due to them being unrepresentable and inextensible in the microsyntax.<br />
<br />
This problem is not encountered in the implementation of &lt;data&gt; with a type discriminator attribute which, in addition to supporting all the date and time denominations currently afforded to &lt;time&gt; and &lt;input&gt;, also leaves scope for the extension of new denominations using newly defined discriminations and allows for denominations to be marked up and looked up through simple enumerated values.<br />
<br />
=== Duplication of Declarative Functionality (DRY Principle) ===<br />
<br />
The addition of the &lt;data&gt; element provides the necessary method to markup machine readable data within HTML documents. This renders the &lt;time&gt; element obsolete by means of duplication of declarative functionality as all types and values which can be encoded within &lt;time&gt; can also be encoded within &lt;data&gt;.<br />
<br />
The proposal for retaining &lt;time&gt; does not specify for &lt;data&gt; to be omitted, and as &lt;data&gt; is capable of representing all date\time types and values, the inclusion of both methods will invariably result in both being used by authors due to confusion arising form duplication and\or due the simplicity of programatically generating all data types using a single element construct. <br />
<br />
This is expected to be encountered especially in the case of documents produced for proprietary machine consumption where priority is given to the simplicity of internal application communication over 3rd party public consumption and standards compliance.<br />
<br />
=== Data Rendering with Localization and Formatting ===<br />
<br />
The use case for the addition of &lt;time&gt;, and by extension &lt;data&gt;, is that of data representation within documents. This requirement not only represents the ability for data values to be encoded and consumed but also for those values to be interfaced by the browser. <br />
<br />
The interfacing over data, like form fields, is relatively under specified at present due to the lack of implementation which would otherwise provide the necessary exploration and implication for specification and design. The requirements for this however are self evident through the extrapolation from the needs of authors and users to both represent and restrict the variation which is required for serving a user base which encompasses all countries, languages and preference.<br />
<br />
The means for delivering this functionality is dependent on a number of factors which are represented with markup - the data value, the locale\language and author customization or configuration.<br />
<br />
The complexity in delivering this functionality is due to the intersection between the otherwise distinct separation between model and style within HTML and CSS. <br />
<br />
While this proposal does not address this with a solution directly, the use of &lt;data&gt; instead of &lt;time&gt; represents a simplification of the problem through the limitation of scope to a single element instead of being dispersed across multiple element definitions. In addition, the synchronicity between the implementation of discrimination type attributes in &lt;data&gt; and &lt;input&gt; elements provides the means to define and deliver a solution which is universal across synonymous data-driven elements which share an identical type system with localization and formatting declarations for external stylesheet customization.<br />
<br />
<br />
== Details ==<br />
<br />
# Remove the &lt;time&gt; element and all associated attributes<br />
# Apply the changes required by extending the &lt;data&gt; element with a type attribute from the supplementary proposal to ISSUE-184 [5]<br />
# Define the valid states for the &lt;data&gt; element "type" attribute for date and time types as: year, month, week, date, time, datetime, datetime-local<br />
# Define the machine readable value of a &lt;data&gt; element with a date\time type as the value derived through the application of the corresponding HTML microsyntax in section ''2.5.5 Dates and times''.<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* The method for marking up data information is simple, generic and universal<br />
* The expressiveness of the <time> element is retained<br />
* The ability to extend the markup of date\time information is available<br />
* HTML is not bloated with numerous elements all targeting the same use case and purpose<br />
* Automated document generation machines can generate data markup using a single method and standard ISO date\time encodings instead of needing to manipulate the encoding for denomination identification through the HTML microsyntax <br />
* Scripts and document consumers can lookup value denominations by enumerated discriminator instead of requiring introspection through the application of HTML microsyntax<br />
* The negative impacts of violating DRY principals are eliminated<br />
* The development of localization and CSS style and formatting rules for data is not imposed with divergent elements and undue complexity restricting the ability for defining a universal method<br />
<br />
=== Negative Effects ===<br />
<br />
* Experimental uses of &lt;time&gt; are rendered obsolete and require updating. Since these authors are ahead of the curve they are aware of the potential that changes may occur. The upgrade path is simple requiring only substitution of element name and may encourage these authors to extend their support of &lt;data&gt; to more use cases improving the corpus of machine readable data on the web.<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* &lt;time&gt; is non-conformant element<br />
* Conformance Class Changes required to support the addition of the &lt;data&gt; element and a "type" discriminator attribute [5]<br />
<br />
=== Risks ===<br />
<br />
* None identified<br />
<br />
== References ==<br />
<br />
* ISSUE-183: Enhance and simplify the time element [http://www.w3.org/html/wg/tracker/issues/183]<br />
<br />
* Tantek's propsal for ISSUE-183 [http://www.w3.org/wiki/User:Tantekelik/time_element]<br />
<br />
* ISSUE-184: Add a data element [http://www.w3.org/html/wg/tracker/issues/184]<br />
<br />
* Tantek's propsal for ISSUE-184 [http://www.w3.org/wiki/User:Tantekelik/data_element]<br />
<br />
* CJones' supplementary counter-proposal for ISSUE-184 [http://www.w3.org/wiki/User:Cjones/ISSUE-184]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-195&diff=57312User:Cjones/ISSUE-1952012-03-22T16:13:51Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-195: Enhance HTTP request generation from forms =<br />
<br />
== Summary ==<br />
<br />
This proposal is for the enhancement of HTML forms in complete integration with the HTTP protocol and the ability to generate entire requests through declarative HTML markup in the absence of scripting support. This proposal leverages the maturity of the XHR specification by exposing the additional functionality afforded through javascript direct to declarative HTML code.<br />
<br />
The first requirement of this proposal is to extend the supported HTTP methods by extending the specification of the form method attribute to allow any value for the generated request. In order to protect the user from exposing client-controlled information to the DOM, and to alleviate the client from handling CONNECT operations, the method attribute restricts the allowed values to exclude the blacklist of prohibited methods:<br />
<br />
CONNECT, TRACE, TRACK<br />
<br />
The second requirement of this proposal is the introduction of declarative authoring of HTTP headers within form fields. This is essential to the extension of methods due to their required semantics for the control of ETags and representation versioning. The approach for introducing this functionality is by means of addition of a "payload" attribute to be included on submittable elements:<br />
<br />
button<br />
input<br />
keygen<br />
object<br />
select<br />
textarea<br />
<br />
The attribute consists of a set of enumerated values for targeting different areas of the generated request:<br />
<br />
_action<br />
_header<br />
_body<br />
<br />
The third extension to the specification is the addition of form control fields representative of the named parameters to the XHR "open()" method to be treated in the same manner for controlling the operation of the form request. The "_logout_" field represents a control for initiating a site-by-site clearing of authentication information on successful completion of the request:<br />
<br />
_user_<br />
_password_<br />
_logout_<br />
<br />
The forth extension to the specification is the addition of the &lt;output&gt; element as a submittable element. This element is currently capable of representing calculations over &lt;input&gt; and &lt;output&gt; values and the result of these calculations should be available for payload binding or to be sent as part of a request body to avoid the same calculations being duplicated by the request processor.<br />
<br />
The final extension to the specification is the addition of an “async” boolean attribute for form submission. This attribute is added to &lt;form&gt;, &lt;input&gt; and &lt;button&gt; elements for defining the mode of submission of the form request either as a synchronous or asynchronous user interface operation.<br />
<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rational for these enhancements can initially be explained by exploring the role of HTML within the suite of technologies comprising the World Wide Web, namely URIs for identification, HTTP for communication and HTML for declaration. <br />
<br />
The first highlight is that this is a trinity of technologies which exists in a state of symbiosis. This is explicitly evident within the shared acronyms of HTML and HTTP, and is self-evident in the understanding of these technologies with regards to their communication and representation of Resources and the means to identify them by URIs.<br />
<br />
This irreducible system has proven itself through its successful global deployment and universal adoption, however there is a limitation of the system in the ability of self-description within HyperText and this omission limits the overall effectiveness.<br />
<br />
The declaration aspects of the system within HTML have been reduced to a level of 'read' and 'write' operations with all other operations being 'tunneled' through these. While this is sufficient in achieving a system which can function it precludes the system from its full potential.<br />
<br />
The main beneficiaries of these enhancements are not end users directly, but the community of authors, developers and implementers who will be empowered with the exposure to the transfer protocol for the technological benefits that come with having access to the entire feature set. This pays dividends in productivity, understanding, and innovation that come from the ability to interact with complete protocol features.<br />
<br />
The application of the ability to control request generation is defined to be unlimited in what methods may be used, what aspect of the payload may be targeted and from which method they may be used with. This retains the expressiveness of HTML as a language and affords to authors the lack of restriction imposed by the HTTP protocol. While certain combinations of methods, headers and bodies may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of openness is what enables specifications to be the most widely applicable and of most use to the largest amounts of users and use-cases and fosters an environment where innovation is possible and possibility is realized.<br />
<br />
The additional functionality exposed in this set of enhancements is the ability for declarative authoring of HTTP Authentication through forms. This represents a significant advancement for the web in the native support for web sites to use these authentication methods over the proliferation of 'session' based cookie schemes which is the predominant security hole exposed through agent software. The application of HTTP authentication with TLS\SSL transport-level security provides a session-less authentication and authorization mechanism with capability to be used on sites with the most heavy security requirements.<br />
<br />
The "_logout_" form control field is a method for form-based control of in-site HTTP authentication credentials. As with other form control fields it is used to initiate custom browser controlled behaviour over the handling of form requests. A form configured with this control field will construct and send a HTTP request to the URI constructed through the action attribute retaining the existing HTTP Authentication headers in its cache. This request is used to indicate to the server that the limit of authentication has ended and the user has requested to be 'logged out'. On a successful response from the server, the UA will clear the cache for the origin thereby completing the logout process. The ability to control the HTTP authentication cache is currently unavailable in browsers through any means and represents an unacceptable security hole in the adoption of HTTP authentication.<br />
<br />
The addition of the "async" submission form attribute is functionality currently available to XHR scripting and allows AJAX style requests from declarative HTML controls. Combined with the ability for form requests to target different browsing contexts this leads to innovation in the development of rich 'webapp' style HTML documents and additional enablement of frames for such purposes. The "onresponse" event type is added to enable declarative script handling of the responses and data in-line.<br />
<br />
In summary, the changes proposed herein represent the progressive enhancement to HTML forms as initially proposed by HTML5 and already available albeit in the much less accessible manner of XHR and scripted client environments. This set of changes radically open up the expressiveness of the language with the exposure of preexisting functionality which has reached the level of maturity for universal adoption.<br />
<br />
== Details ==<br />
<br />
* Update the valid state for "method" and "formmethod" content attributes to be any value excluding those defined by the following enumerated blacklist:<br />
<br />
CONNECT, TRACE, TRACK<br />
<br />
* Add "payload" as a new content attribute to each of the submittable elements defined in section "4.10.2 Categories"<br />
<br />
* Add the restriction of state of the "payload" content attribute to one of the following enumerated values: <br />
<br />
_action, _header, _body<br />
<br />
* Add the following special values to the list of restricted values for form element's "name" attribute in section "4.10.19.1 Naming form controls":<br />
<br />
_user_, _password_, _logout_<br />
<br />
* Add the definition of the "_user_" special form control on a Text control as the value and behaviour of the XHR authentication parameter "user"<br />
<br />
* Add the definition of the "_password_" special form control on a Password control as the value and behaviour of the XHR authentication parameter "password"<br />
<br />
* Add the definition of the "_logout_" special form control on a Hidden control as the value to require the UA to clear site authentication on successful response.<br />
<br />
* Add “async” as a new boolean content attribute for form submission with a default state of false to each of the submission elements:<br />
<br />
form, button, input<br />
<br />
* Add the “disabled” content attribute to the &lt;object&gt; and &lt;output&gt; elements and retain its state and operation as defined for the other submittable elements where the value represent by the element is excluded from the set of submittable form elements.<br />
<br />
* Update the form submission algorithm by specifying the state of the "action" to be the resolved URL with the additional parameters to the process as the submittable form elements whose "payload" attribute is resolved to the value "_action"<br />
<br />
* Update the form submission algorithm by specifying the state of the "request headers" to be the set of submittable form elements whose "payload" attribute is resolved to the value "_header".<br />
<br />
* Update the form submission algorithm by specifying the state of the "form data" to be the set of submittable form elements whose "payload" attribute is resolved to the value "_body".<br />
<br />
* Update the form submission algorithm by removing the method table and replacing it with a scheme switch to sections defining a scheme-specific set of processing instructions<br />
<br />
* Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:<br />
<br />
# Let the definition of resolution of the set of elements with payload "_action" be those that have their attribute set to "_action" or with unset attribute and the resolved method state of HEAD, GET, OPTIONS or DELETE.<br />
# For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters<br />
# Let the definition of resolution of the set of elements with payload "_header" be those that have their attribute set to "_header"<br />
# For the set of elements resolved with the payload "_header" apply the set of name\value pairs as HTTP author request headers with the same definition as described in XHR<br />
# Let the definition of resolution of the set of elements with payload "_body" be those that have their attribute set to "_body" or with an unset attribute and the resolved method state of PUT, POST, PATCH or custom method.<br />
# For the set of elements resolved with the payload "_body" encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described in XHR<br />
# If there exists a form element corresponding to the special control "_user_" or "_password_" then these values must be applied to the request as with the same definition described in XHR<br />
# Construct the request using the HTTP(S) method defined by the submitter element's resolved "method" attribute state.<br />
# Send the constructed request as either a synchronous or asynchronous request as defined by the submitter element's resolved "async" attribute state.<br />
# If there exists a form element corresponding to the special control "_logout_" and the response to the request is a 2xx success code then the agent must clear the site's authentication cache for subsequent requests.<br />
<br />
* Remove the definition of the FTP scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Remove the definition of the javascript scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Add the definition of the data scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload attribute "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described by "Post to data:".<br />
<br />
* Add the definition of the mailto scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload "_action" encode the set of fields by concatenating them together using the semi-colon ";" deliminator and append to the action URI.<br />
# For the set of elements with the payload "_header" encode the set of fields using the "application/x-www-form-urlencoded" encoding algorithm and append to the action URI with the question mark "?" character.<br />
# For the set of elements with the payload "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply to the end of the action URI with the prefix of "body="<br />
# Navigate the target browsing context to destination represented by the action<br />
<br />
* Add the "onresponse" event type which is triggered by receiving the request's response containing event data representing the response<br />
<br />
* Add the &lt;output&gt; element to the list of submittable elements and enable it for inclusion in the construction of the form request set<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
==== Form Methods ====<br />
<br />
* Declarative specification of HTTP web services within the HTML language<br />
* Enables HTTP web services for scriptless clients and environments<br />
* Simpler visible programming, explanation, documentation and education of HTTP web services and forms<br />
* Correct use of HTTP without tunneling through the non-semantic and non-idempotent POST method<br />
* Greater functionality in form submission attributes on buttons for customizing the data set with alternate request parameters<br />
<br />
==== Form Headers ====<br />
<br />
* Headers allow for complete request representations by including protocol or custom headers which are essential aspects of action and intent<br />
* Headers support the essential semantics of idempotent methods<br />
* Headers support additional response negotiation through techniques such as "Prefer" headers<br />
* Enables scope for further innovation over the protocol which is increasing using headers as a representational state mechanism<br />
<br />
==== Payload Attribute ====<br />
<br />
* Allows the flexibility to specify any and all aspects of the request for any method<br />
* Maintains backwards-compatibility with existing HTML4 forms and HTTP method conventions<br />
* Allows query parameters for PUT and POST for resource targeting and non-representational intent<br />
* Allows GET or other action methods to include embedded digital keys for capability-based security<br />
* &lt;input&gt; and &lt;output&gt; elements can define header fields configured using any input type, validation or calculation<br />
* Use of underscore prefix "_" for payload states uses the familiar conventions of browser context targeting while also retaining scope for further specification possibly in integration with UriTemplates or other name-based templating technologies<br />
* Mailto forms can construct messages with multiple recipients and have full control over all email headers and the body contents without limitation from intent tunneling through HTTP methods<br />
* All submittable elements have a “disabled” state allowing explicit exclusion of values used by documents for user communication or input capture from being mandatory in the request or generated "data:" representations<br />
<br />
==== Form Control Fields ====<br />
<br />
* Form control fields re-use existing conventions for triggering custom User Agent request-generation behaviour <br />
* HTTP Authentication in forms bypasses the unfriendly browser popups and allows site controlled, familiar and flexible CSS user interfaces<br />
* Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache with server notification<br />
<br />
==== Submittable &lt;output&gt; Element ====<br />
<br />
* Client-side calculations do not need to be dependent on identical server-side implementations which otherwise introduce client-server coupling<br />
* Calculations over user inputs can be applied to construct complex header values<br />
* Decouples input capture from data use or representation<br />
<br />
==== Async Submission Attribute ====<br />
<br />
* Asynchronous requests enable rich 'webapp' style documents without imposing procedural construction or limits to scriptless clients<br />
<br />
=== Negative Effects ===<br />
<br />
* The introduction of payload targeting introduces a more complex form request generation algorithm, however backward compatibility is maintained<br />
<br />
* Introduces greater reference to XHR specification<br />
<br />
* Introduces greater requirements on implementations<br />
<br />
* Asynchronous operation introduces potential confusion for authors on the request\response cycle and a document as a representation not an application. However the additional functionality is required for the functions of a 'webapp'<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance defined through the the application of changes in the "Details" section<br />
<br />
* HTTP Authentication is non-required conformance on implementations<br />
<br />
* Asynchronous requests are non-required conformance on implementations<br />
<br />
* FTP and javascript schemes are non-required conformance form actions<br />
<br />
=== Risks ===<br />
<br />
* Additional HTTP methods introduce new security risks from non-script environments. As the new functionality exposed is currently available within XHR it does not introduce any new security risks that are not already available within scripted environments. As the new request generation features enable greater expression of requests, any new security risks would be limited to server processing which is also already available to XHR contexts. As the responses from servers are still processed within a non-script environment there is no further risk introduced to the client with processing the response.<br />
<br />
* Forms may attempt to override User-Agent controlled headers. To mitigate this, the same black-listed headers may be applied by User Agents as with requests from XHR.<br />
<br />
* Nefarious scripts may alter the state of <output> element's value violating the calculations the server was expecting to be applied. Since the nefarious script already has access to DOM the vulnerabilities would not be limited to this and as such are a secondary attack vector resulting from a prior security breach.<br />
<br />
* Existing documents may use the special form control names introduced with this proposal. This may risk unexpected behaviour being triggered by the User Agent prior to the request being sent or post response. This should be mitigated by implementers by restricting the application of new form control fields to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.<br />
<br />
== References ==<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/html/wg/tracker/issues/195]<br />
<br />
* XMLHttpRequest [http://www.w3.org/TR/XMLHttpRequest]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.txt]<br />
<br />
* HTTP Authentication: Basic and Digest Access Authentication [http://www.ietf.org/rfc/rfc2617.txt]<br />
<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-195&diff=57311User:Cjones/ISSUE-1952012-03-22T16:11:41Z<p>Cjones: Updated form method to blacklist, removed _none payload attribute state, moved _asnyc_ to form submission content attribute</p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-195: Enhance HTTP request generation from forms =<br />
<br />
== Summary ==<br />
<br />
This proposal is for the enhancement of HTML forms in complete integration with the HTTP protocol and the ability to generate entire requests through declarative HTML markup in the absence of scripting support. This proposal leverages the maturity of the XHR specification by exposing the additional functionality afforded through javascript direct to declarative HTML code.<br />
<br />
The first requirement of this proposal is to extend the supported HTTP methods by extending the specification of the form method attribute to allow any value for the generated request. In order to protect the user from exposing client-controlled information to the DOM, and to alleviate the client from handling CONNECT operations, the method attribute restricts the allowed values to exclude the blacklist of prohibited methods:<br />
<br />
CONNECT, TRACE, TRACK<br />
<br />
The second requirement of this proposal is the introduction of declarative authoring of HTTP headers within form fields. This is essential to the extension of methods due to their required semantics for the control of ETags and representation versioning. The approach for introducing this functionality is by means of addition of a "payload" attribute to be included on submittable elements:<br />
<br />
button<br />
input<br />
keygen<br />
object<br />
select<br />
textarea<br />
<br />
The attribute consists of a set of enumerated values for targeting different areas of the generated request:<br />
<br />
_action<br />
_header<br />
_body<br />
<br />
The third extension to the specification is the addition of form control fields representative of the named parameters to the XHR "open()" method to be treated in the same manner for controlling the operation of the form request. The “_logout_” field represents a control for initiating a site-by-site clearing of authentication information on successful completion of the request:<br />
<br />
_user_<br />
_password_<br />
_logout_<br />
<br />
The forth extension to the specification is the addition of the &lt;output&gt; element as a submittable element. This element is currently capable of representing calculations over &lt;input&gt; and &lt;output&gt; values and the result of these calculations should be available for payload binding or to be sent as part of a request body to avoid the same calculations being duplicated by the request processor.<br />
<br />
The final extension to the specification is the addition of an “async” boolean attribute for form submission. This attribute is added to &lt;form&gt;, &lt;input&gt; and &lt;button&gt; elements for defining the mode of submission of the form request either as a blocking synchronous or non-blocking asynchronous user interface operation.<br />
<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rational for these enhancements can initially be explained by exploring the role of HTML within the suite of technologies comprising the World Wide Web, namely URIs for identification, HTTP for communication and HTML for declaration. <br />
<br />
The first highlight is that this is a trinity of technologies which exists in a state of symbiosis. This is explicitly evident within the shared acronyms of HTML and HTTP, and is self-evident in the understanding of these technologies with regards to their communication and representation of Resources and the means to identify them by URIs.<br />
<br />
This irreducible system has proven itself through its successful global deployment and universal adoption, however there is a limitation of the system in the ability of self-description within HyperText and this omission limits the overall effectiveness.<br />
<br />
The declaration aspects of the system within HTML have been reduced to a level of 'read' and 'write' operations with all other operations being 'tunneled' through these. While this is sufficient in achieving a system which can function it precludes the system from its full potential.<br />
<br />
The main beneficiaries of these enhancements are not end users directly, but the community of authors, developers and implementers who will be empowered with the exposure to the transfer protocol for the technological benefits that come with having access to the entire feature set. This pays dividends in productivity, understanding, and innovation that come from the ability to interact with complete protocol features.<br />
<br />
The application of the ability to control request generation is defined to be unlimited in what methods may be used, what aspect of the payload may be targeted and from which method they may be used with. This retains the expressiveness of HTML as a language and affords to authors the lack of restriction imposed by the HTTP protocol. While certain combinations of methods, headers and bodies may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of openness is what enables specifications to be the most widely applicable and of most use to the largest amounts of users and use-cases and fosters an environment where innovation is possible and possibility is realized.<br />
<br />
The additional functionality exposed in this set of enhancements is the ability for declarative authoring of HTTP Authentication through forms. This represents a significant advancement for the web in the native support for web sites to use these authentication methods over the proliferation of 'session' based cookie schemes which is the predominant security hole exposed through agent software. The application of HTTP authentication with TLS\SSL transport-level security provides a session-less authentication and authorization mechanism with capability to be used on sites with the most heavy security requirements.<br />
<br />
The "_logout_" form control field is a method for form-based control of in-site HTTP authentication credentials. As with other form control fields it is used to initiate custom browser controlled behaviour over the handling of form requests. A form configured with this control field will construct and send a HTTP request to the URI constructed through the action attribute retaining the existing HTTP Authentication headers in its cache. This request is used to indicate to the server that the limit of authentication has ended and the user has requested to be 'logged out'. On a successful response from the server, the UA will clear the cache for the origin thereby completing the logout process. The ability to control the HTTP authentication cache is currently unavailable in browsers through any means and represents an unacceptable security hole in the adoption of HTTP authentication.<br />
<br />
The addition of the "async" submission form attribute is functionality currently available to XHR scripting and allows AJAX style requests from declarative HTML controls. Combined with the ability for form requests to target different browsing contexts this leads to innovation in the development of rich 'webapp' style HTML documents and additional enablement of frames for such purposes. The "onresponse" event type is added to enable declarative script handling of the responses and data in-line.<br />
<br />
In summary, the changes proposed herein represent the progressive enhancement to HTML forms as initially proposed by HTML5 and already available albeit in the much less accessible manner of XHR and scripted client environments. This set of changes radically open up the expressiveness of the language with the exposure of preexisting functionality which has reached the level of maturity for universal adoption.<br />
<br />
== Details ==<br />
<br />
* Update the valid state for "method" and "formmethod" content attributes to be any value excluding those defined by the following enumerated blacklist:<br />
<br />
CONNECT, TRACE, TRACK<br />
<br />
* Add "payload" as a new content attribute to each of the submittable elements defined in section "4.10.2 Categories"<br />
<br />
* Add the restriction of state of the "payload" content attribute to one of the following enumerated values: <br />
<br />
_action, _header, _body<br />
<br />
* Add the following special values to the list of restricted values for form element's "name" attribute in section "4.10.19.1 Naming form controls":<br />
<br />
_user_, _password_, _logout_<br />
<br />
* Add the definition of the "_user_" special form control on a Text control as the value and behaviour of the XHR authentication parameter "user"<br />
<br />
* Add the definition of the "_password_" special form control on a Password control as the value and behaviour of the XHR authentication parameter "password"<br />
<br />
* Add the definition of the "_logout_" special form control on a Hidden control as the value to require the UA to clear site authentication on successful response.<br />
<br />
* Add “async” as a new boolean content attribute for form submission with a default state of false to each of the submission elements:<br />
<br />
form, button, input<br />
<br />
* Add the “disabled” content attribute to the &lt;object&gt; and &lt;output&gt; elements and retain its state and operation as defined for the other submittable elements where the value represent by the element is excluded from the set of submittable form elements.<br />
<br />
* Update the form submission algorithm by specifying the state of the "action" to be the resolved URL with the additional parameters to the process as the submittable form elements whose "payload" attribute is resolved to the value "_action"<br />
<br />
* Update the form submission algorithm by specifying the state of the "request headers" to be the set of submittable form elements whose "payload" attribute is resolved to the value "_header".<br />
<br />
* Update the form submission algorithm by specifying the state of the "form data" to be the set of submittable form elements whose "payload" attribute is resolved to the value "_body".<br />
<br />
* Update the form submission algorithm by removing the method table and replacing it with a scheme switch to sections defining a scheme-specific set of processing instructions<br />
<br />
* Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:<br />
<br />
# Let the definition of resolution of the set of elements with payload "_action" be those that have their attribute set to "_action" or with unset attribute and the resolved method state of HEAD, GET, OPTIONS or DELETE.<br />
# For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters<br />
# Let the definition of resolution of the set of elements with payload "_header" be those that have their attribute set to "_header"<br />
# For the set of elements resolved with the payload "_header" apply the set of name\value pairs as HTTP author request headers with the same definition as described in XHR<br />
# Let the definition of resolution of the set of elements with payload "_body" be those that have their attribute set to "_body" or with an unset attribute and the resolved method state of PUT, POST, PATCH or custom method.<br />
# For the set of elements resolved with the payload "_body" encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described in XHR<br />
# If there exists a form element corresponding to the special control "_user_" or "_password_" then these values must be applied to the request as with the same definition described in XHR<br />
# Construct the request using the HTTP(S) method defined by the submitter element's resolved "method" attribute state.<br />
# Send the constructed request as either a synchronous or asynchronous request as defined by the submitter element's resolved "async" attribute state.<br />
# If there exists a form element corresponding to the special control "_logout_" and the response to the request is a 2xx success code then the agent must clear the site's authentication cache for subsequent requests.<br />
<br />
* Remove the definition of the FTP scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Remove the definition of the javascript scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Add the definition of the data scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload attribute "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described by "Post to data:".<br />
<br />
* Add the definition of the mailto scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload "_action" encode the set of fields by concatenating them together using the semi-colon ";" deliminator and append to the action URI.<br />
# For the set of elements with the payload "_header" encode the set of fields using the "application/x-www-form-urlencoded" encoding algorithm and append to the action URI with the question mark "?" character.<br />
# For the set of elements with the payload "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply to the end of the action URI with the prefix of "body="<br />
# Navigate the target browsing context to destination represented by the action<br />
<br />
* Add the "onresponse" event type which is triggered by receiving the request's response containing event data representing the response<br />
<br />
* Add the &lt;output&gt; element to the list of submittable elements and enable it for inclusion in the construction of the form request set<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
==== Form Methods ====<br />
<br />
* Declarative specification of HTTP web services within the HTML language<br />
* Enables HTTP web services for scriptless clients and environments<br />
* Simpler visible programming, explanation, documentation and education of HTTP web services and forms<br />
* Correct use of HTTP without tunneling through the non-semantic and non-idempotent POST method<br />
* Greater functionality in form submission attributes on buttons for customizing the data set with alternate request parameters<br />
<br />
==== Form Headers ====<br />
<br />
* Headers allow for complete request representations by including protocol or custom headers which are essential aspects of action and intent<br />
* Headers support the essential semantics of idempotent methods<br />
* Headers support additional response negotiation through techniques such as "Prefer" headers<br />
* Enables scope for further innovation over the protocol which is increasing using headers as a representational state mechanism<br />
<br />
==== Payload Attribute ====<br />
<br />
* Allows the flexibility to specify any and all aspects of the request for any method<br />
* Maintains backwards-compatibility with existing HTML4 forms and HTTP method conventions<br />
* Allows query parameters for PUT and POST for resource targeting and non-representational intent<br />
* Allows GET or other action methods to include embedded digital keys for capability-based security<br />
* &lt;input&gt; and &lt;output&gt; elements can define header fields configured using any input type, validation or calculation<br />
* Use of underscore prefix "_" for payload states uses the familiar conventions of browser context targeting while also retaining scope for further specification possibly in integration with UriTemplates or other name-based templating technologies<br />
* Mailto forms can construct messages with multiple recipients and have full control over all email headers and the body contents without limitation from intent tunneling through HTTP methods<br />
* All submittable elements have a “disabled” state allowing explicit exclusion of values used by documents for user communication or input capture from being mandatory in the request or generated "data:" representations<br />
<br />
==== Form Control Fields ====<br />
<br />
* Form control fields re-use existing conventions for triggering custom User Agent request-generation behaviour <br />
* HTTP Authentication in forms bypasses the unfriendly browser popups and allows site controlled, familiar and flexible CSS user interfaces<br />
* Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache with server notification<br />
<br />
==== Submittable &lt;output&gt; Element ====<br />
<br />
* Client-side calculations do not need to be dependent on identical server-side implementations which otherwise introduce client-server coupling<br />
* Calculations over user inputs can be applied to construct complex header values<br />
* Decouples input capture from data use or representation<br />
<br />
==== Async Submission Attribute ====<br />
<br />
* Asynchronous requests enable rich 'webapp' style documents without imposing procedural construction or limits to scriptless clients<br />
<br />
=== Negative Effects ===<br />
<br />
* The introduction of payload targeting introduces a more complex form request generation algorithm, however backward compatibility is maintained<br />
<br />
* Introduces greater reference to XHR specification<br />
<br />
* Introduces greater requirements on implementations<br />
<br />
* Asynchronous operation introduces potential confusion for authors on the request\response cycle and a document as a representation not an application. However the additional functionality is required for the functions of a 'webapp'<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance defined through the the application of changes in the "Details" section<br />
<br />
* HTTP Authentication is non-required conformance on implementations<br />
<br />
* Asynchronous requests are non-required conformance on implementations<br />
<br />
* FTP and javascript schemes are non-required conformance form actions<br />
<br />
=== Risks ===<br />
<br />
* Additional HTTP methods introduce new security risks from non-script environments. As the new functionality exposed is currently available within XHR it does not introduce any new security risks that are not already available within scripted environments. As the new request generation features enable greater expression of requests, any new security risks would be limited to server processing which is also already available to XHR contexts. As the responses from servers are still processed within a non-script environment there is no further risk introduced to the client with processing the response.<br />
<br />
* Forms may attempt to override User-Agent controlled headers. To mitigate this, the same black-listed headers may be applied by User Agents as with requests from XHR.<br />
<br />
* Nefarious scripts may alter the state of <output> element's value violating the calculations the server was expecting to be applied. Since the nefarious script already has access to DOM the vulnerabilities would not be limited to this and as such are a secondary attack vector resulting from a prior security breach.<br />
<br />
* Existing documents may use the special form control names introduced with this proposal. This may risk unexpected behaviour being triggered by the User Agent prior to the request being sent or post response. This should be mitigated by implementers by restricting the application of new form control fields to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.<br />
<br />
== References ==<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/html/wg/tracker/issues/195]<br />
<br />
* XMLHttpRequest [http://www.w3.org/TR/XMLHttpRequest]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.txt]<br />
<br />
* HTTP Authentication: Basic and Digest Access Authentication [http://www.ietf.org/rfc/rfc2617.txt]<br />
<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-195&diff=56509User:Cjones/ISSUE-1952012-02-13T15:22:23Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-195: Enhance HTTP request generation from forms =<br />
<br />
== Summary ==<br />
<br />
This proposal is for the enhancement of HTML forms in complete integration with the HTTP protocol and the ability to generate entire requests through declarative HTML markup in the absence of scripting support. This proposal leverages the maturity of the XHR specification by exposing the additional functionality afforded through javascript direct to declarative HTML code.<br />
<br />
The first requirement of this proposal is to extend the supported HTTP methods to include the entire range of non-client-hazardous methods from HTTP/1.1:<br />
<br />
HEAD, GET, OPTIONS, CONNECT, PUT, POST, DELETE<br />
<br />
'' Note: TRACE has been specifically excluded due to the potential for exposing otherwise restricted client-controlled information to the DOM ''<br />
<br />
The second requirement of this proposal is the introduction of declarative authoring of HTTP headers within form fields. This is essential to the extension of methods due to their required semantics for the control of ETags and representation versioning. The approach for introducing this functionality is by means of addition of a "payload" attribute to be included on submittable elements:<br />
<br />
button<br />
input<br />
keygen<br />
object<br />
select<br />
textarea<br />
<br />
The attribute consists of a set of enumerated values for targeting different areas of the generated request:<br />
<br />
_action<br />
_header<br />
_body<br />
_none<br />
<br />
The third extension to the specification is the addition of form control fields representative of the named parameters to the XHR "open()" method to be treated in the same manner for controlling the operation of the form request. The forth field represents a control for initiating a site-by-site clearing of authentication information on successful completion of the request:<br />
<br />
_user_<br />
_password_<br />
_async_<br />
_logout_<br />
<br />
The forth extension to the specification is the addition of the &lt;output&gt; element as a submittable element. This element is currently capable of representing calculations over &lt;input&gt; and &lt;output&gt; values and the result of these calculations should be available for payload binding or to be sent as part of a request body to avoid the same calculations being duplicated by the request processor.<br />
<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rational for these enhancements can initially be explained by exploring the role of HTML within the suite of technologies comprising the World Wide Web, namely URIs for identification, HTTP for communication and HTML for declaration. <br />
<br />
The first highlight is that this is a trinity of technologies which exists in a state of symbiosis. This is explicitly evident within the shared acronyms of HTML and HTTP, and is self-evident in the understanding of these technologies with regards to their communication and representation of Resources and the means to identify them by URIs.<br />
<br />
This irreducible system has proven itself through its successful global deployment and universal adoption, however there is a limitation of the system in the ability of self-description within HyperText and this omission limits the overall effectiveness.<br />
<br />
The declaration aspects of the system within HTML have been reduced to a level of 'read' and 'write' operations with all other operations being 'tunneled' through these. While this is sufficient in achieving a system which can function it precludes the system from its full potential.<br />
<br />
The main beneficiaries of these enhancements are not end users directly, but the community of authors, developers and implementers who will be empowered with the exposure to the transfer protocol for the technological benefits that come with having access to the entire feature set. This pays dividends in productivity, understanding, and innovation that come from the ability to interact with complete protocol features.<br />
<br />
The application of the ability to control request generation is defined to be unlimited in what methods may be used, what aspect of the payload may be targeted and from which method they may be used with. This retains the expressiveness of HTML as a language and affords to authors the lack of restriction imposed by the HTTP protocol. While certain combinations of methods, headers and bodies may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of openness is what enables specifications to be the most widely applicable and of most use to the largest amounts of users and use-cases and fosters an environment where innovation is possible and possibility is realized.<br />
<br />
The additional functionality exposed in this set of enhancements is the ability for declarative authoring of HTTP Authentication through forms. This represents a significant advancement for the web in the native support for web sites to use these authentication methods over the proliferation of 'session' based cookie schemes which is the predominant security hole exposed through agent software. The application of HTTP authentication with TLS\SSL transport-level security provides a session-less authentication and authorization mechanism with capability to be used on sites with the most heavy security requirements.<br />
<br />
The "_logout_" form control field is a method for form-based control of in-site HTTP authentication credentials. As with other form control fields it is used to initiate custom browser controlled behaviour over the handling of form requests. A form configured with this control field will construct and send a HTTP request to the URI constructed through the action attribute retaining the existing HTTP Authentication headers in its cache. This request is used to indicate to the server that the limit of authentication has ended and the user has requested to be 'logged out'. On a successful response from the server, the UA will clear the cache for the origin thereby completing the logout process. The ability to control the HTTP authentication cache is currently unavailable in browsers through any means and represents an unacceptable security hole in the adoption of HTTP authentication.<br />
<br />
The exposure of the "_async_" form control field currently available to XHR scripting will allow AJAX style requests from declarative HTML controls. Combined with the ability for form requests to target different browsing contexts this will lead to innovation in the development of rich 'webapp' style HTML documents and additional enablement of frames for such purposes. The "onresponse" event type is added to enable declarative script handling of the responses and data in-line.<br />
<br />
In summary, the changes proposed herein represent the progressive enhancement to HTML forms as initially proposed by HTML5 and already available albeit in the much less accessible manner of XHR and scripted client environments. This set of changes radically open up the expressiveness of the language with the exposure of preexisting functionality which has reached the level of maturity for universal adoption.<br />
<br />
== Details ==<br />
<br />
* Add the HTTP methods types as keywords and states to the list of valid enumerated attributes for the "method" and "formmethod" content attributes: <br />
<br />
HEAD, OPTIONS, CONNECT, PUT, DELETE<br />
<br />
* Add "payload" as a new content attribute to each of the submittable elements defined in section "4.10.2 Categories"<br />
<br />
* Add the restriction of state of the "payload" content attribute to one of the following enumerated values: <br />
<br />
_action, _header, _body, _none<br />
<br />
* Add the following special values to the list of restricted values for form element's "name" attribute in section "4.10.19.1 Naming form controls":<br />
<br />
_user_, _password_, _async_, _logout_<br />
<br />
* Add the definition of the "_user_" special form control on a Text control as the value and behaviour of the XHR authentication parameter "user"<br />
<br />
* Add the definition of the "_password_" special form control on a Password control as the value and behaviour of the XHR authentication parameter "password"<br />
<br />
* Add the definition of the "_async_" special form control on a Hidden control as the value and behaviour XHR parameter "async"<br />
<br />
* Add the definition of the "_logout_" special form control on a Hidden control as the value to require the UA to clear site authentication on successful response.<br />
<br />
* Update the form submission algorithm by specifying the state of the "action" to be the resolved URL with the additional parameters to the process as the form elements whose "payload" attribute is resolved to the value "_action"<br />
<br />
* Update the form submission algorithm by specifying the state of the "request headers" to be the set of form elements whose "payload" attribute is resolved to the value "_header".<br />
<br />
* Update the form submission algorithm by specifying the state of the "form data" to be the set of form elements whose "payload" attribute is resolved to the value "_body".<br />
<br />
* Update the form submission algorithm by specifying that the set of form elements whose "payload" attribute is resolved to the value "_none" are not to be used.<br />
<br />
* Update the form submission algorithm by removing the method table and replacing it with a scheme switch to sections defining a scheme-specific set of processing instructions<br />
<br />
* Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:<br />
<br />
# Let the definition of resolution of the set of elements with payload "_action" be those that have their attribute set to "_action" or with unset attribute and the resolved method state of HEAD, GET, OPTIONS or DELETE<br />
# For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters<br />
# Let the definition of resolution of the set of elements with payload "_header" be those that have their attribute set to "_header"<br />
# For the set of elements resolved with the payload "_header" apply the set of name\value pairs as HTTP author request headers with the same definition as described in XHR<br />
# Let the definition of resolution of the set of elements with payload "_body" be those that have their attribute set to "_body" or with an unset attribute and the resolved method state of PUT, POST or CONNECT<br />
# For the set of elements resolved with the payload "_body" encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described in XHR<br />
# If there exists a form element corresponding to the special control "_user_", "_password_" or "_async_" then these values must be applied to the request as with the same definition described in XHR<br />
# Send the constructed request by HTTP(S) method defined by the submitter element's resolved method attribute state.<br />
# If there exists a form element corresponding to the special control "_logout_" and the response to the request is a 2xx success code then the agent must clear the site's authentication cache for subsequent requests.<br />
<br />
* Remove the definition of the FTP scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Remove the definition of the javascript scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Add the definition of the data scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload attribute "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described by "Post to data:".<br />
<br />
* Add the definition of the mailto scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload "_action" encode the set of fields by concatenating them together using the semi-colon ";" deliminator and append to the action URI.<br />
# For the set of elements with the payload "_header" encode the set of fields using the "application/x-www-form-urlencoded" encoding algorithm and append to the action URI with the question mark "?" character.<br />
# For the set of elements with the payload "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply to the end of the action URI with the prefix of "body="<br />
# Navigate the target browsing context to destination represented by the action<br />
<br />
* Add the "onresponse" event type which is triggered by receiving the request's response containing event data representing the response<br />
<br />
* Add the &lt;output&gt; element to the list of submittable elements and enable it for inclusion in the construction of the form request set<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
==== Form Methods ====<br />
<br />
* Declarative specification of HTTP web services within the HTML language<br />
* Enables HTTP web services for scriptless clients and environments<br />
* Simpler visible programming, explanation, documentation and education of HTTP web services and forms<br />
* Correct use of HTTP without tunneling through the non-semantic and non-idempotent POST method<br />
* Greater functionality in form submission attributes on buttons for customizing the data set with alternate request parameters<br />
<br />
==== Form Headers ====<br />
<br />
* Headers allow for complete request representations by including protocol or custom headers which are essential aspects of action and intent<br />
* Headers support the essential semantics of idempotent methods<br />
* Headers support additional response negotiation through techniques such as "Prefer" headers<br />
* Enables scope for further innovation over the protocol which is increasing using headers as a representational state mechanism<br />
<br />
==== Payload Attribute ====<br />
<br />
* Allows the flexibility to specify any and all aspects of the request for any method<br />
* Maintains backwards-compatibility with existing HTML4 forms and HTTP method conventions<br />
* Allows query parameters for PUT and POST for resource targeting and non-representational intent<br />
* Allows GET or other action methods to include embedded digital keys for capability-based security<br />
* &lt;input&gt; and &lt;output&gt; elements can define header fields configured using any input type, validation or calculation<br />
* Targeting "_none" allows for explicit exclusion of values used by documents for user communication or input capture from being mandatory in the request or generated "data:" representations<br />
* Use of underscore prefix "_" for payload states uses the familiar conventions of browser context targeting while also retaining scope for further specification possibly in integration with UriTemplates or other name-based templating technologies<br />
* Mailto forms can construct messages with multiple recipients and have full control over all email headers and the body contents without limitation from intent tunneling through HTTP methods<br />
<br />
==== Form Control Fields ====<br />
<br />
* Form control fields re-use existing conventions for triggering custom User Agent request-generation behaviour <br />
* HTTP Authentication in forms bypasses the unfriendly browser popups and allows site controlled, familiar and flexible CSS user interfaces<br />
* Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache with server notification<br />
* Asynchronous requests enable rich 'webapp' style documents without imposing procedural construction or limits to scriptless clients<br />
<br />
==== Submittable &lt;output&gt; element ====<br />
<br />
* Client-side calculations do not need to be dependent on identical server-side implementations which otherwise introduce client-server coupling<br />
* Calculations over user inputs can be applied to construct complex header values<br />
* Decouples input capture from data use or representation<br />
<br />
=== Negative Effects ===<br />
<br />
* The introduction of payload targeting introduces a more complex form request generation algorithm, however backward compatibility is maintained<br />
<br />
* Introduces greater reference to XHR specification<br />
<br />
* Introduces greater requirements on implementations<br />
<br />
* Asynchronous operation introduces potential confusion for authors on the request\response cycle and a document as a representation not an application. However the additional functionality is required for the functions of a 'webapp'<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance defined through the the application of changes in the "Details" section<br />
<br />
* HTTP Authentication is non-required conformance on implementations<br />
<br />
* Asynchronous requests are non-required conformance on implementations<br />
<br />
* FTP and javascript schemes are non-required conformance form actions<br />
<br />
=== Risks ===<br />
<br />
* Additional HTTP methods introduce new security risks from non-script environments. As the new functionality exposed is currently available within XHR it does not introduce any new security risks that are not already available within scripted environments. As the new request generation features enable greater expression of requests, any new security risks would be limited to server processing which is also already available to XHR contexts. As the responses from servers are still processed within a non-script environment there is no further risk introduced to the client with processing the response.<br />
<br />
* Forms may attempt to override User-Agent controlled headers. To mitigate this, the same black-listed headers may be applied by User Agents as with requests from XHR.<br />
<br />
* Nefarious scripts may alter the state of <output> element's value violating the calculations the server was expecting to be applied. Since the nefarious script already has access to DOM the vulnerabilities would not be limited to this and as such are a secondary attack vector resulting from a prior security breach.<br />
<br />
* Existing documents may use the special form control names introduced with this proposal. This may risk unexpected behaviour being triggered by the User Agent prior to the request being sent or post response. This should be mitigated by implementers by restricting the application of new form control fields to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.<br />
<br />
== References ==<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/html/wg/tracker/issues/195]<br />
<br />
* XMLHttpRequest [http://http://www.w3.org/TR/XMLHttpRequest]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.txt]<br />
<br />
* HTTP Authentication: Basic and Digest Access Authentication [http://www.ietf.org/rfc/rfc2617.txt]<br />
<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-196&diff=56508User:Cjones/ISSUE-1962012-02-13T13:35:02Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-196: No change for User Agent HTTP response handling behaviour =<br />
<br />
== Summary ==<br />
<br />
This is a change proposal advocating for the resolution of ISSUE-196 by means of no-change in the HTML specification.<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The issue was raised in response to concerns over specific handling of some 2xx Success HTTP response codes by User Agents. Through investigation while there may be some divergent behaviour with regards to individual implementations, the HTTP specification currently provides the definition of expected User Agent behaviour and as such these implementations should be regarded as non-conformant HTTP agents and not non-conformant HTML implementations.<br />
<br />
The HTML specification does not impose conformance requirements on the implementation of HTTP engines in the same manner that HTTP specification does not impose conformance requirements on the implementation of HTML engines. This would invariably introduce a state of inter-dependence between the specifications and deteriorate the otherwise principal authority of the HTTP protocol and its specification process to to define and control the standardization, interoperability and further advancement of the protocol.<br />
<br />
== Details ==<br />
<br />
# Identified divergent behaviour of User Agents should be raised within the HTTP specification process for greater clarity or User Agent bug reporting processes for highlighting non-conformant behaviour for correction.<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* The specification does not introduce or impose additional restrictions on HTTP processing specifically within the context of HTML<br />
* The HTTP specification is maintained as the single authoritative source for conformant behaviour or otherwise<br />
<br />
=== Negative Effects ===<br />
<br />
* The may be some HTTP status codes which require further specification for the effective realization of their benefits and this is reliant on the success of external standardization and User Agent bug processes<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* None<br />
<br />
=== Risks ===<br />
<br />
* User Agents continue to display divergent behaviours due to the lack of specificity in the HTTP specification requiring servers to either customize their response based on snooping HTTP headers or tunneling all responses through predictable behavioural status codes<br />
<br />
== References ==<br />
<br />
* Browser HTTP Response Handling Tests [http://www.cmhjones.com/browser-http-test-matrix.html]<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-196: Define user agent http response handling behaviour [http://www.w3.org/html/wg/tracker/issues/196]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.html]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones&diff=56507User:Cjones2012-02-13T13:19:04Z<p>Cjones: </p>
<hr />
<div>= Cameron Jones =<br />
<br />
Contact: [mailto:cmhjones@gmail.com cmhjones@gmail.com]<br />
<br />
== Change Proposals ==<br />
<br />
* ISSUE-183: Drop the <time> element [http://www.w3.org/wiki/User:Cjones/ISSUE-183]<br />
* ISSUE-184: Enhance the <data> element with a type system [http://www.w3.org/wiki/User:Cjones/ISSUE-184]<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/wiki/User:Cjones/ISSUE-195]<br />
* ISSUE-196: No change for User Agent HTTP response handling behaviour [http://www.w3.org/wiki/User:Cjones/ISSUE-196]</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-195&diff=56502User:Cjones/ISSUE-1952012-02-11T18:22:36Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-195: Enhance HTTP request generation from forms =<br />
<br />
== Summary ==<br />
<br />
This proposal is for the enhancement of HTML forms in complete integration with the HTTP protocol and the ability to generate entire requests through declarative HTML markup in the absence of scripting support. This proposal leverages the maturity of the XHR specification by exposing the additional functionality afforded through javascript direct to declarative HTML code.<br />
<br />
The first requirement of this proposal is to extend the supported HTTP methods to include the entire range of non-client-hazardous methods from HTTP/1.1:<br />
<br />
HEAD, GET, OPTIONS, CONNECT, PUT, POST, DELETE<br />
<br />
'' Note: TRACE has been specifically excluded due to the potential for exposing otherwise restricted client-controlled information to the DOM ''<br />
<br />
The second requirement of this proposal is the introduction of declarative authoring of HTTP headers within form fields. This is essential to the extension of methods due to their required semantics for the control of ETags and representation versioning. The approach for introducing this functionality is by means of addition of a "payload" attribute to be included on submittable elements:<br />
<br />
button<br />
input<br />
keygen<br />
object<br />
select<br />
textarea<br />
<br />
The attribute consists of a set of enumerated values for targeting different areas of the generated request:<br />
<br />
_action<br />
_header<br />
_body<br />
_none<br />
<br />
The third extension to the specification is the addition of form control fields representative of the named parameters to the XHR "open()" method to be treated in the same manner for controlling the operation of the form request. The forth field represents a control for initiating a site-by-site clearing of authentication information on successful completion of the request:<br />
<br />
_user_<br />
_password_<br />
_async_<br />
_logout_<br />
<br />
The forth extension to the specification is the addition of the &lt;output&gt; element as a submittable element. This element is currently capable of representing calculations over &lt;input&gt; and &lt;output&gt; values and the result of these calculations should be available for payload binding or to be sent as part of a request body to avoid the same calculations being duplicated by the request processor.<br />
<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rational for these enhancements can initially be explained by exploring the role of HTML within the suite of technologies comprising the World Wide Web, namely URIs for identification, HTTP for communication and HTML for declaration. <br />
<br />
The first highlight is that this is a trinity of technologies which exists in a state of symbiosis. This is explicitly evident within the shared acronyms of HTML and HTTP, and is self-evident in the understanding of these technologies with regards to their communication and representation of Resources and the means to identify them by URIs.<br />
<br />
This irreducible system has proven itself through its successful global deployment and universal adoption, however there is a limitation of the system in the ability of self-description within HyperText and this omission limits the overall effectiveness.<br />
<br />
The declaration aspects of the system within HTML have been reduced to a level of 'read' and 'write' operations with all other operations being 'tunneled' through these. While this is sufficient in achieving a system which can function it precludes the system from its full potential.<br />
<br />
The main beneficiaries of these enhancements are not end users directly, but the community of authors, developers and implementers who will be empowered with the exposure to the transfer protocol for the technological benefits that come with having access to the entire feature set. This pays dividends in productivity, understanding, and innovation that come from the ability to interact with complete protocol features.<br />
<br />
The application of the ability to control request generation is defined to be unlimited in what methods may be used, what aspect of the payload may be targeted and from which method they may be used with. This retains the expressiveness of HTML as a language and affords to authors the lack of restriction imposed by the HTTP protocol. While certain combinations of methods, headers and bodies may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of openness is what enables specifications to be the most widely applicable and of most use to the largest amounts of users and use-cases and fosters an environment where innovation is possible and possibility is realized.<br />
<br />
The additional functionality exposed in this set of enhancements is the ability for declarative authoring of HTTP Authentication through forms. This represents a significant advancement for the web in the native support for web sites to use these authentication methods over the proliferation of 'session' based cookie schemes which is the predominant security hole exposed through agent software. The application of HTTP authentication with TLS\SSL transport-level security provides a session-less authentication and authorization mechanism with capability to be used on sites with the most heavy security requirements.<br />
<br />
The "_logout_" form control field is a method for form-based control of in-site HTTP authentication credentials. As with other form control fields it is used to initiate custom browser controlled behaviour over the handling of form requests. A form configured with this control field will construct and send a HTTP request to the URI constructed through the action attribute retaining the existing HTTP Authentication headers in its cache. This request is used to indicate to the server that the limit of authentication has ended and the user has requested to be 'logged out'. On a successful response from the server, the UA will clear the cache for the origin thereby completing the logout process. The ability to control the HTTP authentication cache is currently unavailable in browsers through any means and represents an unacceptable security hole in the adoption of HTTP authentication.<br />
<br />
The exposure of the "_async" form control field currently available to XHR scripting will allow AJAX style requests from declarative HTML controls. Combined with the ability for form requests to target different browsing contexts this will lead to innovation in the development of rich 'webapp' style HTML documents and additional enablement of frames for such purposes. The "onresponse" event type is added to enable declarative script handling of the responses and data in-line.<br />
<br />
In summary, the changes proposed herein represent the progressive enhancement to HTML forms as initially proposed by HTML5 and already available albeit in the much less accessible manner of XHR and scripted client environments. This set of changes radically open up the expressiveness of the language with the exposure of preexisting functionality which has reached the level of maturity ready for universal adoption.<br />
<br />
== Details ==<br />
<br />
* Add the HTTP methods types as keywords and states to the list of valid enumerated attributes for the "method" and "formmethod" content attributes: <br />
<br />
HEAD, OPTIONS, CONNECT, PUT, DELETE<br />
<br />
* Add "payload" as a new content attribute to each of the submittable elements defined in section "4.10.2 Categories"<br />
<br />
* Add the restriction of state of the "payload" content attribute to one of the following enumerated values: <br />
<br />
_action, _header, _body, _none<br />
<br />
* Add the following special values to the list of restricted values for form element's "name" attribute in section "4.10.19.1 Naming form controls":<br />
<br />
_user_, _password_, _async_, _logout_<br />
<br />
* Add the definition of the "_user_" special form control on a Text control as the value and behaviour of the XHR authentication parameter "user"<br />
<br />
* Add the definition of the "_password_" special form control on a Password control as the value and behaviour of the XHR authentication parameter "password"<br />
<br />
* Add the definition of the "_async_" special form control on a Hidden control as the value and behaviour XHR parameter "async"<br />
<br />
* Add the definition of the "_logout_" special form control on a Hidden control as the value to require the UA to clear site authentication on successful response.<br />
<br />
* Update the form submission algorithm by specifying the state of the "action" to be the resolved URL with the additional parameters to the process as the form elements whose "payload" attribute is resolved to the value "_action"<br />
<br />
* Update the form submission algorithm by specifying the state of the "request headers" to be the set of form elements whose "payload" attribute is resolved to the value "_header".<br />
<br />
* Update the form submission algorithm by specifying the state of the "form data" to be the set of form elements whose "payload" attribute is resolved to the value "_body".<br />
<br />
* Update the form submission algorithm by specifying that the set of form elements whose "payload" attribute is resolved to the value "_none" are not to be used.<br />
<br />
* Update the form submission algorithm by removing the method table and replacing it with a scheme switch to sections defining a scheme-specific set of processing instructions<br />
<br />
* Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:<br />
<br />
# Let the definition of resolution of the set of elements with payload "_action" be those that have their attribute set to "_action" or with unset attribute and the resolved method state of HEAD, GET, OPTIONS or DELETE<br />
# For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters<br />
# Let the definition of resolution of the set of elements with payload "_header" be those that have their attribute set to "_header"<br />
# For the set of elements resolved with the payload "_header" apply the set of name\value pairs as HTTP author request headers with the same definition as described in XHR<br />
# Let the definition of resolution of the set of elements with payload "_body" be those that have their attribute set to "_body" or with an unset attribute and the resolved method state of PUT, POST or CONNECT<br />
# For the set of elements resolved with the payload "_body" encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described in XHR<br />
# If there exists a form element corresponding to the special control "_user_", "_password_" or "_async" then these values must be applied to the request as with the same definition described in XHR<br />
# Send the constructed request by HTTP(S) method defined by the submitter element's resolved method attribute state.<br />
# If there exists a form element corresponding to the special control "_logout_" and the response to the request is a 2xx success code then the agent must clear the site's authentication cache for subsequent requests.<br />
<br />
* Remove the definition of the FTP scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Remove the definition of the javascript scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Add the definition of the data scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload attribute "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described by "Post to data:".<br />
<br />
* Add the definition of the mailto scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload "_action" encode the set of fields by concatenating them together using the semi-colon ";" deliminator and append to the action URI.<br />
# For the set of elements with the payload "_header" encode the set of fields using the "application/x-www-form-urlencoded" encoding algorithm and append to the action URI with the question mark "?" character.<br />
# For the set of elements with the payload "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply to the end of the action URI with the prefix of "body="<br />
# Navigate the target browsing context to destination represented by the action<br />
<br />
* Add the "onresponse" event type which is triggered by receiving the request's response containing event data representing the response<br />
<br />
* Add the &lt;output&gt; element to the list of submittable elements and enable it for inclusion in the construction of the form request set<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* Declarative specification of HTTP web services<br />
* Enables HTTP web services for scriptless clients<br />
* Simpler explanation, documentation and education of HTTP web services<br />
* Correct use of HTTP without tunneling through unsemantic and non-idempotent POST method<br />
* Headers allow for complete request representations supporting the requirements of the semantics of idempotent methods and the ability for further declaration of response negotiation through methods such as "Prefer" headers<br />
* Greater functionality of form submission attributes on buttons for customizing the data set with different request parameters<br />
* Flexibility for specifying all aspects of the request for any method, ie query parameters for POST, etc<br />
* &lt;input&gt; and &lt;output&gt; defined header fields configured using any type or calculation<br />
* Body targeting enables digital keys for capability-based security within GET requests<br />
* HTTP Authentication driven by forms bypasses unfriendly browser popups and allows site controlled and familiar CSS user-interfaces<br />
* Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache<br />
* Asynchronous requests enable rich webapp style documents<br />
* Mailto forms can construct messages with multiple recipients and full control over scheme headers and body contents<br />
<br />
=== Negative Effects ===<br />
<br />
* The introduction of payload targeting introduces a more complex form request generation algorithm, however backward compatibility is maintained<br />
<br />
* Introduces greater reference to XHR specification<br />
<br />
* Introduces greater requirements on implementations<br />
<br />
* Asynchronous operation introduces potential confusion for authors on the request\response cycle and a document as a representation not an application. However the additional functionality required for the functions of a 'webapp'<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance defined through the the application of changes in the "Details" section<br />
<br />
* HTTP Authentication is non-required conformance on implementations<br />
<br />
* Asynchronous requests are non-required conformance on implementations<br />
<br />
* FTP and javascript schemes are non-required conformance form actions<br />
<br />
=== Risks ===<br />
<br />
* Additional HTTP methods introduce new security risks from non-script environments. As the new functionality exposed is currently available within XHR it does not introduce any new security risks that are not already available within scripted environments. As the new request generation features enable greater expression of requests, any new security risks would be limited to server processing which is also already available to XHR contexts. As the responses from servers are still processed within a non-script environment there is no further risk introduced to the client with processing the response.<br />
<br />
* Forms may attempt to override User-Agent controlled headers. To mitigate this, the same black-listed headers should be applied as requests generated from XHR.<br />
<br />
* Nefarious scripts may alter the state of <output> element's value violating the calculations the server was expecting to be applied. Since the nefarious script already has access to DOM the vulnerabilities would not be limited to this and as such are a secondary attack vector resulting from a prior security breach.<br />
<br />
* Existing documents may use the special form control names introduced with this proposal. This may risk unexpected behaviour to be triggered by the User Agent prior to the request being sent or post response. This should be mitigated by implementers by restricting the application of form controls to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.<br />
<br />
== References ==<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/html/wg/tracker/issues/195]<br />
<br />
* XMLHttpRequest [http://http://www.w3.org/TR/XMLHttpRequest]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.txt]<br />
<br />
* HTTP Authentication: Basic and Digest Access Authentication [http://www.ietf.org/rfc/rfc2617.txt]<br />
<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-195&diff=56501User:Cjones/ISSUE-1952012-02-11T18:16:49Z<p>Cjones: </p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-195: Enhance HTTP request generation from forms =<br />
<br />
== Summary ==<br />
<br />
This proposal is for the enhancement of HTML forms in complete integration with the HTTP protocol and the ability to generate entire requests through declarative HTML markup in the absence of scripting support. This proposal leverages the maturity of the XHR specification by exposing the additional functionality afforded through javascript direct to declarative HTML code.<br />
<br />
The first requirement of this proposal is to extend the supported HTTP methods to include the entire range of non-client-hazardous methods from HTTP/1.1:<br />
<br />
HEAD, GET, OPTIONS, CONNECT, PUT, POST, DELETE<br />
<br />
'' Note: TRACE has been specifically excluded due to the potential for exposing otherwise restricted client-controlled information to the DOM ''<br />
<br />
The second requirement of this proposal is the introduction of declarative authoring of HTTP headers within form fields. This is essential to the extension of methods due to their required semantics for the control of ETags and representation versioning. The approach for introducing this functionality is by means of addition of a "payload" attribute to be included on submittable elements:<br />
<br />
button<br />
input<br />
keygen<br />
object<br />
select<br />
textarea<br />
<br />
The attribute consists of a set of enumerated values for targeting different areas of the generated request:<br />
<br />
_action<br />
_header<br />
_body<br />
_none<br />
<br />
The third extension to the specification is the addition of form control fields representative of the named parameters to the XHR "open()" method to be treated in the same manner for controlling the operation of the form request. The forth field represents a control for initiating a site-by-site clearing of authentication information on successful completion of the request:<br />
<br />
_user_<br />
_password_<br />
_async_<br />
_logout_<br />
<br />
The forth extension to the specification is the addition of the &lt;output&gt; element as a submittable element. This element is currently capable of representing calculations over &lt;input&gt; and &lt;output&gt; values and the result of these calculations should be available for payload binding or to be sent as part of a request body to avoid the same calculations being duplicated by the request processor.<br />
<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rational for these enhancements can be initially explained by first exploring the role of HTML within the suite of technologies comprising the World Wide Web, namely URIs for identification, HTTP for communication and HTML for declaration. <br />
<br />
The first point to be highlighted is that this is a trinity of technologies which exists in a state of symbiosis. This is explicitly evident within the shared acronyms of HTTP and HTML, and is self-evident in the understanding of these technologies with regards to their communication and representation of Resources and the means to identify them by URIs.<br />
<br />
This irreducible system has proven itself through its successful global deployment and universal adoption, however there exists a limitation of the system in the ability of self-description within HyperText and this omission limits its overall effectiveness.<br />
<br />
The declaration aspects of the system within HTML have been reduced to a level of 'read' and 'write' operations with all other operations being 'tunneled' through these. While this is sufficient in achieving a system which can function it precludes the system from its full potential.<br />
<br />
The main beneficiaries of these enhancements are not end users directly, but the community of authors, developers and implementers who will be empowered with the exposure to the transfer protocol for the technological benefits that come with having access to the entire feature set. This pays dividends in productivity, understanding, and innovation that come from the ability to interact with complete protocol features.<br />
<br />
The application of the ability to control request generation is defined to be unlimited in what methods may be used, what aspect of the payload may be targeted and from which method they may be used with. This retains the expressiveness of HTML as a language and affords to authors the lack of restriction imposed by the HTTP protocol. While certain combinations of methods, headers and bodies may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of openness is what enables specifications to be the most widely applicable and of most use to the largest amounts of users and use-cases and fosters an environment where innovation is possible and possibility is realized.<br />
<br />
The additional functionality exposed in this set of enhancements is the ability for declarative authoring of HTTP Authentication through forms. This represents a significant advancement for the web in the native support for web sites to use these authentication methods over the proliferation of 'session' based cookie schemes which is the predominant security hole exposed through agent software. The application of HTTP authentication with TLS\SSL transport-level security provides a session-less authentication and authorization mechanism with capability to be used on sites with the most heavy security requirements.<br />
<br />
The "_logout_" form control field is a method for form-based control of in-site HTTP authentication credentials. As with other form control fields it is used to initiate custom browser controlled behaviour over the handling of form requests. A form configured with this control field will construct and send a HTTP request to the URI constructed through the action attribute retaining the existing HTTP Authentication headers in its cache. This request is used to indicate to the server that the limit of authentication has ended and the user has requested to be 'logged out'. On a successful response from the server, the UA will clear the cache for the origin thereby completing the logout process. The ability to control the HTTP authentication cache is currently unavailable in browsers through any means and represents an unacceptable security hole in the adoption of HTTP authentication.<br />
<br />
The exposure of the "_async" form control field currently available to XHR scripting will allow AJAX style requests from declarative HTML controls. Combined with the ability for form requests to target different browsing contexts this will lead to innovation in the development of rich 'webapp' style HTML documents and additional enablement of frames for such purposes. The "onresponse" event type is added to enable declarative script handling of the responses and data in-line.<br />
<br />
In summary, the changes proposed herein represent the progressive enhancement to HTML forms as initially proposed by HTML5 and already available albeit in the much less accessible manner of XHR and scripted client environments. This set of changes radically open up the expressiveness of the language with the exposure of preexisting functionality which has reached the level of maturity ready for universal adoption.<br />
<br />
== Details ==<br />
<br />
* Add the HTTP methods types as keywords and states to the list of valid enumerated attributes for the "method" and "formmethod" content attributes: <br />
<br />
HEAD, OPTIONS, CONNECT, PUT, DELETE<br />
<br />
* Add "payload" as a new content attribute to each of the submittable elements defined in section "4.10.2 Categories"<br />
<br />
* Add the restriction of state of the "payload" content attribute to one of the following enumerated values: <br />
<br />
_action, _header, _body, _none<br />
<br />
* Add the following special values to the list of restricted values for form element's "name" attribute in section "4.10.19.1 Naming form controls":<br />
<br />
_user_, _password_, _async_, _logout_<br />
<br />
* Add the definition of the "_user_" special form control on a Text control as the value and behaviour of the XHR authentication parameter "user"<br />
<br />
* Add the definition of the "_password_" special form control on a Password control as the value and behaviour of the XHR authentication parameter "password"<br />
<br />
* Add the definition of the "_async_" special form control on a Hidden control as the value and behaviour XHR parameter "async"<br />
<br />
* Add the definition of the "_logout_" special form control on a Hidden control as the value to require the UA to clear site authentication on successful response.<br />
<br />
* Update the form submission algorithm by specifying the state of the "action" to be the resolved URL with the additional parameters to the process as the form elements whose "payload" attribute is resolved to the value "_action"<br />
<br />
* Update the form submission algorithm by specifying the state of the "request headers" to be the set of form elements whose "payload" attribute is resolved to the value "_header".<br />
<br />
* Update the form submission algorithm by specifying the state of the "form data" to be the set of form elements whose "payload" attribute is resolved to the value "_body".<br />
<br />
* Update the form submission algorithm by specifying that the set of form elements whose "payload" attribute is resolved to the value "_none" are not to be used.<br />
<br />
* Update the form submission algorithm by removing the method table and replacing it with a scheme switch to sections defining a scheme-specific set of processing instructions<br />
<br />
* Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:<br />
<br />
# Let the definition of resolution of the set of elements with payload "_action" be those that have their attribute set to "_action" or with unset attribute and the resolved method state of HEAD, GET, OPTIONS or DELETE<br />
# For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters<br />
# Let the definition of resolution of the set of elements with payload "_header" be those that have their attribute set to "_header"<br />
# For the set of elements resolved with the payload "_header" apply the set of name\value pairs as HTTP author request headers with the same definition as described in XHR<br />
# Let the definition of resolution of the set of elements with payload "_body" be those that have their attribute set to "_body" or with an unset attribute and the resolved method state of PUT, POST or CONNECT<br />
# For the set of elements resolved with the payload "_body" encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described in XHR<br />
# If there exists a form element corresponding to the special control "_user_", "_password_" or "_async" then these values must be applied to the request as with the same definition described in XHR<br />
# Send the constructed request by HTTP(S) method defined by the submitter element's resolved method attribute state.<br />
# If there exists a form element corresponding to the special control "_logout_" and the response to the request is a 2xx success code then the agent must clear the site's authentication cache for subsequent requests.<br />
<br />
* Remove the definition of the FTP scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Remove the definition of the javascript scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Add the definition of the data scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload attribute "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described by "Post to data:".<br />
<br />
* Add the definition of the mailto scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload "_action" encode the set of fields by concatenating them together using the semi-colon ";" deliminator and append to the action URI.<br />
# For the set of elements with the payload "_header" encode the set of fields using the "application/x-www-form-urlencoded" encoding algorithm and append to the action URI with the question mark "?" character.<br />
# For the set of elements with the payload "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply to the end of the action URI with the prefix of "body="<br />
# Navigate the target browsing context to destination represented by the action<br />
<br />
* Add the "onresponse" event type which is triggered by receiving the request's response containing event data representing the response<br />
<br />
* Add the &lt;output&gt; element to the list of submittable elements and enable it for inclusion in the construction of the form request set<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* Declarative specification of HTTP web services<br />
* Enables HTTP web services for scriptless clients<br />
* Simpler explanation, documentation and education of HTTP web services<br />
* Correct use of HTTP without tunneling through unsemantic and non-idempotent POST method<br />
* Headers allow for complete request representations supporting the requirements of the semantics of idempotent methods and the ability for further declaration of response negotiation through methods such as "Prefer" headers<br />
* Greater functionality of form submission attributes on buttons for customizing the data set with different request parameters<br />
* Flexibility for specifying all aspects of the request for any method, ie query parameters for POST, etc<br />
* &lt;input&gt; and &lt;output&gt; defined header fields configured using any type or calculation<br />
* Body targeting enables digital keys for capability-based security within GET requests<br />
* HTTP Authentication driven by forms bypasses unfriendly browser popups and allows site controlled and familiar CSS user-interfaces<br />
* Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache<br />
* Asynchronous requests enable rich webapp style documents<br />
* Mailto forms can construct messages with multiple recipients and full control over scheme headers and body contents<br />
<br />
=== Negative Effects ===<br />
<br />
* The introduction of payload targeting introduces a more complex form request generation algorithm, however backward compatibility is maintained<br />
<br />
* Introduces greater reference to XHR specification<br />
<br />
* Introduces greater requirements on implementations<br />
<br />
* Asynchronous operation introduces potential confusion for authors on the request\response cycle and a document as a representation not an application. However the additional functionality required for the functions of a 'webapp'<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance defined through the the application of changes in the "Details" section<br />
<br />
* HTTP Authentication is non-required conformance on implementations<br />
<br />
* Asynchronous requests are non-required conformance on implementations<br />
<br />
* FTP and javascript schemes are non-required conformance form actions<br />
<br />
=== Risks ===<br />
<br />
* Additional HTTP methods introduce new security risks from non-script environments. As the new functionality exposed is currently available within XHR it does not introduce any new security risks that are not already available within scripted environments. As the new request generation features enable greater expression of requests, any new security risks would be limited to server processing which is also already available to XHR contexts. As the responses from servers are still processed within a non-script environment there is no further risk introduced to the client with processing the response.<br />
<br />
* Forms may attempt to override User-Agent controlled headers. To mitigate this, the same black-listed headers should be applied as requests generated from XHR.<br />
<br />
* Nefarious scripts may alter the state of <output> element's value violating the calculations the server was expecting to be applied. Since the nefarious script already has access to DOM the vulnerabilities would not be limited to this and as such are a secondary attack vector resulting from a prior security breach.<br />
<br />
* Existing documents may use the special form control names introduced with this proposal. This may risk unexpected behaviour to be triggered by the User Agent prior to the request being sent or post response. This should be mitigated by implementers by restricting the application of form controls to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.<br />
<br />
== References ==<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/html/wg/tracker/issues/195]<br />
<br />
* XMLHttpRequest [http://http://www.w3.org/TR/XMLHttpRequest]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.txt]<br />
<br />
* HTTP Authentication: Basic and Digest Access Authentication [http://www.ietf.org/rfc/rfc2617.txt]<br />
<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-195&diff=56500User:Cjones/ISSUE-1952012-02-11T18:13:06Z<p>Cjones: ISSUE-195: Enhance HTTP request generation from forms</p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-195: Enhance HTTP request generation from forms =<br />
<br />
== Summary ==<br />
<br />
This proposal is for the enhancement of HTML forms in complete integration with the HTTP protocol and the ability to generate entire requests through declarative HTML markup in the absence of scripting support. This proposal leverages the maturity of the XHR specification by exposing the additional functionality afforded through javascript direct to declarative HTML code.<br />
<br />
The first requirement of this proposal is to extend the supported HTTP methods to include the entire range of non-client-hazardous methods from HTTP/1.1:<br />
<br />
HEAD, GET, OPTIONS, CONNECT, PUT, POST, DELETE<br />
<br />
'' Note: TRACE has been specifically excluded due to the potential for exposing otherwise restricted client-controlled information to the DOM ''<br />
<br />
The second requirement of this proposal is the introduction of declarative authoring of HTTP headers within form fields. This is essential to the extension of methods due to their required semantics for the control of ETags and representation versioning. The approach for introducing this functionality is by means of addition of a "payload" attribute to be included on submittable elements:<br />
<br />
button<br />
input<br />
keygen<br />
object<br />
select<br />
textarea<br />
<br />
The attribute consists of a set of enumerated values for targeting different areas of the generated request:<br />
<br />
_action<br />
_header<br />
_body<br />
_none<br />
<br />
The third extension to the specification is the addition of form control fields representative of the named parameters to the XHR "open()" method to be treated in the same manner for controlling the operation of the form request. The forth field represents a control for initiating a site-by-site clearing of authentication information on successful completion of the request:<br />
<br />
_user_<br />
_password_<br />
_async_<br />
_logout_<br />
<br />
The forth extension to the specification is the addition of the &lt;output&gt; element as a submittable element. This element is currently capable of representing calculations over &lt;input&gt; and &lt;output&gt; values and the result of these calculations should be available to be sent as part of a request to avoid those same calculations being duplicated by the request processor.<br />
<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rational for these enhancements can be initially explained by first exploring the role of HTML within the suite of technologies comprising the World Wide Web, namely URIs for identification, HTTP for communication and HTML for declaration. <br />
<br />
The first point to be highlighted is that this is a trinity of technologies which exists in a state of symbiosis. This is explicitly evident within the shared acronyms of HTTP and HTML, and is self-evident in the understanding of these technologies with regards to their communication and representation of Resources and the means to identify them by URIs.<br />
<br />
This irreducible system has proven itself through its successful global deployment and universal adoption, however there exists a limitation of the system in the ability of self-description within HyperText and this omission limits its overall effectiveness.<br />
<br />
The declaration aspects of the system within HTML have been reduced to a level of 'read' and 'write' operations with all other operations being 'tunneled' through these. While this is sufficient in achieving a system which can function it precludes the system from its full potential.<br />
<br />
The main beneficiaries of these enhancements are not end users directly, but the community of authors, developers and implementers who will be empowered with the exposure to the transfer protocol for the technological benefits that come with having access to the entire feature set. This pays dividends in productivity, understanding, and innovation that come from the ability to interact with complete protocol features.<br />
<br />
The application of the ability to control request generation is defined to be unlimited in what methods may be used, what aspect of the payload may be targeted and from which method they may be used with. This retains the expressiveness of HTML as a language and affords to authors the lack of restriction imposed by the HTTP protocol. While certain combinations of methods, headers and bodies may be discouraged they are none-the-less conformant and should not be restricted from being generated or sent. This degree of openness is what enables specifications to be the most widely applicable and of most use to the largest amounts of users and use-cases and fosters an environment where innovation is possible and possibility is realized.<br />
<br />
The additional functionality exposed in this set of enhancements is the ability for declarative authoring of HTTP Authentication through forms. This represents a significant advancement for the web in the native support for web sites to use these authentication methods over the proliferation of 'session' based cookie schemes which is the predominant security hole exposed through agent software. The application of HTTP authentication with TLS\SSL transport-level security provides a session-less authentication and authorization mechanism with capability to be used on sites with the most heavy security requirements.<br />
<br />
The "_logout_" form control field is a method for form-based control of in-site HTTP authentication credentials. As with other form control fields it is used to initiate custom browser controlled behaviour over the handling of form requests. A form configured with this control field will construct and send a HTTP request to the URI constructed through the action attribute retaining the existing HTTP Authentication headers in its cache. This request is used to indicate to the server that the limit of authentication has ended and the user has requested to be 'logged out'. On a successful response from the server, the UA will clear the cache for the origin thereby completing the logout process. The ability to control the HTTP authentication cache is currently unavailable in browsers through any means and represents an unacceptable security hole in the adoption of HTTP authentication.<br />
<br />
The exposure of the "_async" form control field currently available to XHR scripting will allow AJAX style requests from declarative HTML controls. Combined with the ability for form requests to target different browsing contexts this will lead to innovation in the development of rich 'webapp' style HTML documents and additional enablement of frames for such purposes. The "onresponse" event type is added to enable declarative script handling of the responses and data in-line.<br />
<br />
In summary, the changes proposed herein represent the progressive enhancement to HTML forms as initially proposed by HTML5 and already available albeit in the much less accessible manner of XHR and scripted client environments. This set of changes radically open up the expressiveness of the language with the exposure of preexisting functionality which has reached the level of maturity ready for universal adoption.<br />
<br />
== Details ==<br />
<br />
* Add the HTTP methods types as keywords and states to the list of valid enumerated attributes for the "method" and "formmethod" content attributes: <br />
<br />
HEAD, OPTIONS, CONNECT, PUT, DELETE<br />
<br />
* Add "payload" as a new content attribute to each of the submittable elements defined in section "4.10.2 Categories"<br />
<br />
* Add the restriction of state of the "payload" content attribute to one of the following enumerated values: <br />
<br />
_action, _header, _body, _none<br />
<br />
* Add the following special values to the list of restricted values for form element's "name" attribute in section "4.10.19.1 Naming form controls":<br />
<br />
_user_, _password_, _async_, _logout_<br />
<br />
* Add the definition of the "_user_" special form control on a Text control as the value and behaviour of the XHR authentication parameter "user"<br />
<br />
* Add the definition of the "_password_" special form control on a Password control as the value and behaviour of the XHR authentication parameter "password"<br />
<br />
* Add the definition of the "_async_" special form control on a Hidden control as the value and behaviour XHR parameter "async"<br />
<br />
* Add the definition of the "_logout_" special form control on a Hidden control as the value to require the UA to clear site authentication on successful response.<br />
<br />
* Update the form submission algorithm by specifying the state of the "action" to be the resolved URL with the additional parameters to the process as the form elements whose "payload" attribute is resolved to the value "_action"<br />
<br />
* Update the form submission algorithm by specifying the state of the "request headers" to be the set of form elements whose "payload" attribute is resolved to the value "_header".<br />
<br />
* Update the form submission algorithm by specifying the state of the "form data" to be the set of form elements whose "payload" attribute is resolved to the value "_body".<br />
<br />
* Update the form submission algorithm by specifying that the set of form elements whose "payload" attribute is resolved to the value "_none" are not to be used.<br />
<br />
* Update the form submission algorithm by removing the method table and replacing it with a scheme switch to sections defining a scheme-specific set of processing instructions<br />
<br />
* Add the definition of the HTTP and HTTPS scheme processing instruction set as the construction of a request by the following process:<br />
<br />
# Let the definition of resolution of the set of elements with payload "_action" be those that have their attribute set to "_action" or with unset attribute and the resolved method state of HEAD, GET, OPTIONS or DELETE<br />
# For the set of elements resolved with the payload "_action" mutate the action URL by applying the name\value pairs as query parameters<br />
# Let the definition of resolution of the set of elements with payload "_header" be those that have their attribute set to "_header"<br />
# For the set of elements resolved with the payload "_header" apply the set of name\value pairs as HTTP author request headers with the same definition as described in XHR<br />
# Let the definition of resolution of the set of elements with payload "_body" be those that have their attribute set to "_body" or with an unset attribute and the resolved method state of PUT, POST or CONNECT<br />
# For the set of elements resolved with the payload "_body" encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described in XHR<br />
# If there exists a form element corresponding to the special control "_user_", "_password_" or "_async" then these values must be applied to the request as with the same definition described in XHR<br />
# Send the constructed request by HTTP(S) method defined by the submitter element's resolved method attribute state.<br />
# If there exists a form element corresponding to the special control "_logout_" and the response to the request is a 2xx success code then the agent must clear the site's authentication cache for subsequent requests.<br />
<br />
* Remove the definition of the FTP scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Remove the definition of the javascript scheme from the form submission algorithm. The form is not used as mechanism for constructing a request and as such the inclusion of this scheme offers nothing over its declaration and use within a HTML anchor.<br />
<br />
* Add the definition of the data scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload attribute "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply as the request data with the same definition as described by "Post to data:".<br />
<br />
* Add the definition of the mailto scheme processing instruction set as defined by the following process:<br />
# For the set of elements with the payload "_action" encode the set of fields by concatenating them together using the semi-colon ";" deliminator and append to the action URI.<br />
# For the set of elements with the payload "_header" encode the set of fields using the "application/x-www-form-urlencoded" encoding algorithm and append to the action URI with the question mark "?" character.<br />
# For the set of elements with the payload "_body" or unset encode the set of elements using the appropriate form encoding algorithm and apply to the end of the action URI with the prefix of "body="<br />
# Navigate the target browsing context to destination represented by the action<br />
<br />
* Add the "onresponse" event type which is triggered by receiving the request's response containing event data representing the response<br />
<br />
* Add the &lt;output&gt; element to the list of submittable elements and enable it for inclusion in the construction of the form request set<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* Declarative specification of HTTP web services<br />
* Enables HTTP web services for scriptless clients<br />
* Simpler explanation, documentation and education of HTTP web services<br />
* Correct use of HTTP without tunneling through unsemantic and non-idempotent POST method<br />
* Headers allow for complete request representations supporting the requirements of the semantics of idempotent methods and the ability for further declaration of response negotiation through methods such as "Prefer" headers<br />
* Greater functionality of form submission attributes on buttons for customizing the data set with different request parameters<br />
* Flexibility for specifying all aspects of the request for any method, ie query parameters for POST, etc<br />
* &lt;input&gt; and &lt;output&gt; defined header fields configured using any type or calculation<br />
* Body targeting enables digital keys for capability-based security within GET requests<br />
* HTTP Authentication driven by forms bypasses unfriendly browser popups and allows site controlled and familiar CSS user-interfaces<br />
* Logout functionality provides simple, scriptless, universal control over the HTTP authentication cache<br />
* Asynchronous requests enable rich webapp style documents<br />
* Mailto forms can construct messages with multiple recipients and full control over scheme headers and body contents<br />
<br />
=== Negative Effects ===<br />
<br />
* The introduction of payload targeting introduces a more complex form request generation algorithm, however backward compatibility is maintained<br />
<br />
* Introduces greater reference to XHR specification<br />
<br />
* Introduces greater requirements on implementations<br />
<br />
* Asynchronous operation introduces potential confusion for authors on the request\response cycle and a document as a representation not an application. However the additional functionality required for the functions of a 'webapp'<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance defined through the the application of changes in the "Details" section<br />
<br />
* HTTP Authentication is non-required conformance on implementations<br />
<br />
* Asynchronous requests are non-required conformance on implementations<br />
<br />
* FTP and javascript schemes are non-required conformance form actions<br />
<br />
=== Risks ===<br />
<br />
* Additional HTTP methods introduce new security risks from non-script environments. As the new functionality exposed is currently available within XHR it does not introduce any new security risks that are not already available within scripted environments. As the new request generation features enable greater expression of requests, any new security risks would be limited to server processing which is also already available to XHR contexts. As the responses from servers are still processed within a non-script environment there is no further risk introduced to the client with processing the response.<br />
<br />
* Forms may attempt to override User-Agent controlled headers. To mitigate this, the same black-listed headers should be applied as requests generated from XHR.<br />
<br />
* Nefarious scripts may alter the state of <output> element's value violating the calculations the server was expecting to be applied. Since the nefarious script already has access to DOM the vulnerabilities would not be limited to this and as such are a secondary attack vector resulting from a prior security breach.<br />
<br />
* Existing documents may use the special form control names introduced with this proposal. This may risk unexpected behaviour to be triggered by the User Agent prior to the request being sent or post response. This should be mitigated by implementers by restricting the application of form controls to only HTML5 documents thereby ensuring that existing documents can not inadvertently be affected by the introduction of new features.<br />
<br />
== References ==<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-195: Enhance HTTP request generation from forms [http://www.w3.org/html/wg/tracker/issues/195]<br />
<br />
* XMLHttpRequest [http://http://www.w3.org/TR/XMLHttpRequest]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.txt]<br />
<br />
* HTTP Authentication: Basic and Digest Access Authentication [http://www.ietf.org/rfc/rfc2617.txt]<br />
<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-196&diff=56499User:Cjones/ISSUE-1962012-02-11T16:51:17Z<p>Cjones: ISSUE-196: No change for HTTP integration and the HTML fetch algorithm</p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<br />
= ISSUE-196: No change for HTTP integration and the HTML fetch algorithm =<br />
<br />
== Summary ==<br />
<br />
This is a change proposal advocating for the resolution of ISSUE-196 by means of no-change in HTML specification.<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The issue was raised in response to concerns over specific handling of some 2xx Success HTTP response codes by User Agents. Through investigation while there may be some divergent behaviour with regards to individual implementations, the HTTP specification currently provides the definition of expected User Agent behaviour and as such these implementations should be regarded as non-conformant HTTP agents and not non-conformant HTML implementations.<br />
<br />
The HTML specification does not impose conformance requirements on the implementation of HTTP engines in the same manner that HTTP specification does not impose conformance requirements on the implementation of HTML engines. This would invariably introduce a state of inter-dependence between the specifications and deteriorate the otherwise principal authority of the HTTP protocol and its specification process to to define and control the standardization, interoperability and further advancement of the protocol.<br />
<br />
== Details ==<br />
<br />
# Identified divergent behaviour of User Agents should be raised within the HTTP specification process for greater clarity or User Agent bug reporting processes for highlighting non-conformant behaviour for correction.<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* The specification does not introduce or impose additional restrictions on HTTP processing specifically within the context of HTML<br />
* The HTTP specification is maintained as the single authoritative source for conformant behaviour or otherwise<br />
<br />
=== Negative Effects ===<br />
<br />
* The may be some HTTP status codes which require further specification for the effective realization of their benefits and this is reliant on the success of external specification and User Agent bug processes<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* None<br />
<br />
=== Risks ===<br />
<br />
* User Agents continue to display divergent behaviours due to the lack of specificity in the HTTP specification requiring servers to either customize their response based on snooping HTTP headers or tunnelling all responses through predictable behavioural status codes<br />
<br />
== References ==<br />
<br />
* Browser HTTP Response Handling Tests [http://www.cmhjones.com/browser-http-test-matrix.html]<br />
<br />
* Bug 10671 - consider adding support for PUT and DELETE as form methods [http://www.w3.org/Bugs/Public/show_bug.cgi?id=10671]<br />
<br />
* ISSUE-196: Define user agent http response handling behaviour [http://www.w3.org/html/wg/tracker/issues/196]<br />
<br />
* Hypertext Transfer Protocol -- HTTP/1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.html]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones&diff=56498User:Cjones2012-02-11T12:51:58Z<p>Cjones: Added contact details</p>
<hr />
<div>= Cameron Jones =<br />
<br />
Contact: [mailto:cmhjones@gmail.com cmhjones@gmail.com]<br />
<br />
== Change Proposals ==<br />
<br />
* ISSUE-183: Drop the <time> element [http://www.w3.org/wiki/User:Cjones/ISSUE-183]<br />
* ISSUE-184: Enhance the <data> element with a type system [http://www.w3.org/wiki/User:Cjones/ISSUE-184]</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/&diff=56497User:Cjones/2012-02-11T12:50:28Z<p>Cjones: moved User:Cjones/ to User:Cjones:&#32;Removed trailing slash</p>
<hr />
<div>#REDIRECT [[User:Cjones]]</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones&diff=56496User:Cjones2012-02-11T12:50:28Z<p>Cjones: moved User:Cjones/ to User:Cjones:&#32;Removed trailing slash</p>
<hr />
<div>= User: Cjones =<br />
<br />
== Change Proposals ==<br />
<br />
* ISSUE-183: Drop the <time> element [http://www.w3.org/wiki/User:Cjones/ISSUE-183]<br />
* ISSUE-184: Enhance the <data> element with a type system [http://www.w3.org/wiki/User:Cjones/ISSUE-184]</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones&diff=56457User:Cjones2012-02-09T16:07:05Z<p>Cjones: User - Cjones</p>
<hr />
<div>= User: Cjones =<br />
<br />
== Change Proposals ==<br />
<br />
* ISSUE-183: Drop the <time> element [http://www.w3.org/wiki/User:Cjones/ISSUE-183]<br />
* ISSUE-184: Enhance the <data> element with a type system [http://www.w3.org/wiki/User:Cjones/ISSUE-184]</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-184&diff=56456User:Cjones/ISSUE-1842012-02-09T16:01:29Z<p>Cjones: Change Proposal for ISSUE-184: Enhance the &lt;data&gt; element with a type system</p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<!-- Please add relevant Categories --><br />
<!-- [[Category:CategoryName]] --><br />
<!-- Review the list of categories for those that have already been created: --><br />
<!-- http://www.w3.org/html/wg/wiki/Special:Categories --><br />
<!-- More Category info at http://meta.wikimedia.org/wiki/Help:Category --><br />
<br />
= Change Proposal for ISSUE-184: Enhance the &lt;data&gt; element with a type system =<br />
<br />
== Summary ==<br />
<br />
This is a counter-proposal by means of enhancement over the Tantekelik's main proposal advocating for the addition of a <data> element for resolution of ISSUE-184.<br />
<br />
This proposal supplements the addition of the &lt;data&gt; element with a "type" attribute for discriminating the class of data represented by the value attribute or the contained element contents.<br />
<br />
The valid values for the "type" attribute are an enumerated set of keywords initially relating to a sub-set of the values currently accepted for the &lt;input&gt; element.<br />
<br />
In addition, this proposal recommends the addition of the "type" attribute to the &lt;output&gt; element in order to allow for "typed" values to be represented by this element to aid style rules, targeting and formatting across the elements in a predictable and complementary manner.<br />
<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The rationale for the addition of the &lt;data&gt; element is well documented in Tantekelik's proposal for ISSUE-184 however the definition of the element only contains the attribute "value" in addition to the set of global element attributes. This exhibits a lack of definition as to what the &lt;data&gt; element represents and how it can or should be interpreted. <br />
<br />
The contents of the &lt;data&gt; element is a text-format representation of the machine readable data and as such while it may be parsable it is highly ambiguous and can not be definitely used to acquire the value or type of the data.<br />
<br />
The "value" attribute of the &lt;data&gt; element is a text-encoded representation of the data information, however it is expected that there will be numerous different types of data being represented by the &lt;data&gt; element and there is significant scope for overlap within text-encodings. This leaves the problem of what the value represents and how to interpret it.<br />
<br />
The "type" attribute solves this problem by providing the necessary discrimination over the value, or even partially the label, in order that the correct decoding algorithm can be selected for parsing the text into its binary representation for machine processing.<br />
<br />
The "type" attribute is seen to be essential for the successful deployment of &lt;data&gt; as a solution to machine readable data values. <br />
<br />
As this is the case and due to the introduction of a set of type-classes into the HTML vocabulary, the scope for the application of these types is recommended to be extended to the other data-related elements &lt;input&gt; and &lt;output&gt;. These elements represent the means for user-interaction over data and are subject to the same requirements of data parsing and format representation.<br />
<br />
The user agent is already responsible for the task of value parsing and formatting on the &lt;input&gt; elements, this behavior can naturally be extended to the &lt;output&gt; and &lt;data&gt; elements in coordination with style rules for controlling the presentational customization in an externalized manner.<br />
<br />
The benefits of providing and extending these tasks to data outside of &lt;input&gt; elements is that the user agent can be provided with raw machine-readable data whereby the representation of the data is both available for client-side localization and for automated translation into representations that adhere to the cultural conventions of the user. This support is currently only afforded to &lt;input&gt; elements resulting in semi-translation which is confusing and error prone for users.<br />
<br />
== Details ==<br />
<br />
# Apply the set of changes defined by Tantekelik's proposal for ISSUE-184<br />
# Add the "type" attribute to the &lt;data&gt; and &lt;output&gt; elements<br />
# Define the valid states for the "type" attribute for these elements initially as a sub-set of enumerated values based on valid states for the &lt;input&gt; element: text, tel, url, email, datetime, date, month, week, time, datetime-local, number, range, color<br />
# Define the implementation rendering algorithm for &lt;data&gt; and &lt;output&gt; elements without content as the substitution of the value attribute with the application of style-based formatting rules<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* The &lt;data&gt; element allows authors to markup machine readable information<br />
<br />
* The "type" attribute allows for automatic user agent substitution of formatting of data values with client-side localization<br />
<br />
* The contents of the &lt;data&gt; element allows for a label-override for specific value representation<br />
<br />
* The &lt;output&gt; element may perform automatic transliteration of data type values from &lt;input&gt; values with restriction and validation<br />
* Allows for greater specificity and control over the denominations of date and time information currently afforded to the &lt;time&gt; element and its proposed extensions<br />
<br />
* Simplifies implementations by introducing a type system across elements protecting otherwise text-only data from invalid values and the resulting benefits that type guarantees have for scripting and value-consumers<br />
<br />
=== Negative Effects ===<br />
<br />
* Introduces a value type which is independent of the external declaration of data markup technologies, however since all values are currently interpreted as text this offers an additional level of validation and integrity available prior to external data interpretation<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* Additional conformance as specified in the changes described in "Details" section<br />
<br />
* Conformance class changes required to support Tantekelik's proposal<br />
<br />
=== Risks ===<br />
<br />
* As the addition of new features and the application of as type system as value restriction over value expression the risks of introducing this feature set is limited to future development and deployments<br />
<br />
== References ==<br />
<br />
* ISSUE-184: Add a data element [http://www.w3.org/html/wg/tracker/issues/184]<br />
<br />
* Tantekelik's propsal for ISSUE-184 [http://www.w3.org/wiki/User:Tantekelik/data_element]<br />
<br />
__NOTOC__</div>Cjoneshttps://www.w3.org/wiki/index.php?title=User:Cjones/ISSUE-183&diff=56449User:Cjones/ISSUE-1832012-02-09T15:26:35Z<p>Cjones: Change Proposal for ISSUE-183: Drop the &lt;time&gt; element</p>
<hr />
<div>[[Category:ChangeProposal]]<br />
[[Category:Issues]]<br />
<!-- Please add relevant Categories --><br />
<!-- [[Category:CategoryName]] --><br />
<!-- Review the list of categories for those that have already been created: --><br />
<!-- http://www.w3.org/html/wg/wiki/Special:Categories --><br />
<!-- More Category info at http://meta.wikimedia.org/wiki/Help:Category --><br />
<br />
= Change Proposal for ISSUE-183: Drop the &lt;time&gt; element =<br />
<br />
== Summary ==<br />
<br />
This is a counter-proposal to the enhancement of the &lt;time&gt; element advocated for resolution of ISSUE-183. This proposal recommends the removal of the &lt;time&gt; element from HTML5 by replacement with the prerequisite addition of the &lt;data&gt; element in ISSUE-184.<br />
<br />
The functionality currently available within &lt;time&gt; and the supplementary functionality advocated in the original proposal is recommended to be integrated into HTML5 through the addition of date and time parsing rules for values represented in the &lt;data&gt; element.<br />
<br />
This proposal references an additional proposal for enhancement of the &lt;data&gt; element by extending Tantekelik's proposal for ISSUE-184 through the addition of a "type" attribute for discriminating parsing rules allowing for the additional functionality to be maintained.<br />
<br />
__TOC__<br />
<br />
== Rationale ==<br />
<br />
The addition of a &lt;data&gt; element provides the necessary method for authors to markup machine readable data within HTML documents. The addition of the &lt;data&gt; element renders the &lt;time&gt; element obsolete by means of duplication of declarative functionality. <br />
<br />
This duplication would cause confusion for authors over the scope of such element and which method to use and in what context. <br />
<br />
For documents rendered by server processing and substitution the additional &lt;time&gt; element would either require special case programming constructs for handling times and dates, or would result in the &lt;time&gt; element not being used by automated document generation machines in favor of the simpler and more generic &lt;data&gt; element.<br />
<br />
This duplication would also complicate any scripted processing of HTML documents on the client or by search engines or other applications. Such scripts and applications would be forced to deal with two data sets of date and time information resulting in more complicated programming requirements and introducing unnecessary risk of errors and information omission. <br />
<br />
This damage is also not limited to scripted applications but also CSS style rules which must also deal with duplication of targeting and rules. Since the means for styling dates, times and other data through CSS is still under active development this introduces unacceptable risk and complications to this development and specification process.<br />
<br />
In summary, unless &lt;time&gt; is dropped the fundamental programming principal of Don't Repeat Yourself (DRY) will be violated causing all of the negative effects and risks associated with violation of this rule.<br />
<br />
== Details ==<br />
<br />
# Remove the &lt;time&gt; element and all associated attributes<br />
# Replace the time and date parsing instruction set with the &lt;data&gt; element<br />
# Update the time and date parsing instruction set with the additional rules introduced by Tantekelik's proposal to ISSUE-183<br />
<br />
== Impact ==<br />
<br />
=== Positive Effects ===<br />
<br />
* The DRY principal that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system" is maintained<br />
* The method for marking up data information is simple, generic and universally applicable to all data types<br />
* The expressiveness of the <time> element is retained<br />
* The additional enhancements provided by Tantekelik proposal are realized<br />
* The development of CSS style rules for data is not imposed with undue complexity<br />
<br />
=== Negative Effects ===<br />
<br />
* Experimental uses of &lt;time&gt; are rendered obsolete and require updating. Since these authors are ahead of the curve they are aware of the potential that changes may occur. The upgrade path is simple requiring only substitution of element name and may encourage these authors to extend their support of &lt;data&gt; to more use cases improving the corpus of machine readable data on the web.<br />
<br />
=== Conformance Classes Changes ===<br />
<br />
* &lt;time&gt; is non-conformant element<br />
* Conformance Class Changes required to support Tantekelik's propsal<br />
<br />
=== Risks ===<br />
<br />
* Without the supplementary addition of a &lt;data&gt; 'type' attribute discriminator, the additional processing rules introduced with Tantekelik's proposal may introduce complex data parsing rules. See the supplementary counter-proposal to ISSUE-184 for more information.<br />
<br />
== References ==<br />
<br />
* ISSUE-183: Enhance and simplify the time element [http://www.w3.org/html/wg/tracker/issues/183]<br />
<br />
* Tantekelik's propsal for ISSUE-183 [http://www.w3.org/wiki/User:Tantekelik/time_element]<br />
<br />
* ISSUE-184: Add a data element [http://www.w3.org/html/wg/tracker/issues/184]<br />
<br />
* Tantekelik's propsal for ISSUE-184 [http://www.w3.org/wiki/User:Tantekelik/data_element]<br />
<br />
* CJones' supplementary counter-proposal for ISSUE-184 [http://www.w3.org/wiki/User:Cjones/ISSUE-184]<br />
<br />
__NOTOC__</div>Cjones