Form behavior, and mailto and other URIs:

In response to conversations about the 'mailto:' URI and various WhatWG specs, and reducing normative overlap between HTML and IETF documents:

Summary of (my) recommendations:
* update 3986 if necessary (standards track RFC, update equivalence definition)
* update IRI spec, possibly add new protocol element "browser URI string" which encapsulates HTML5 URI info, references IRI document)
* update 'mailto:' URI spec if necessary to match browser implementations
* create a separate "Form processing" document as RFC or HTMLWG product
* change HTML5 doc to reference above


I think specifying form behavior -- how to take a filled out form with form data and turn it into a HTTP request with the form data encoded either in a URI or as a POST to a URI with a message body -- would usefully be a separate specification. I could imagine even updating the requirements for URI scheme definitions, allowing specification of the behavior of a URI and a set of form data elements (with form field information, form source metadata and context and other information) could be turned into protocol actions for the protocol identified by the URI scheme.

I don't think that specification should be contained within the definition of HTML-- it is much more general than HTML and applies to many 'form' formats such as XForms, PDF, Flash, Sliverlight and other form containers.

I also don't think it belongs in the "mailto:" URI specification or the "http:" URI specification either, although getting it right might require changes to either or both of those documents.

Thus, I'm suggesting a different document. I think this could possibly be pursued either an IETF standards-track RFC in the application area or a separate work item in HTML working group, depending on resolution of the "scope" issue.

> For <input type="email">, html5 already defers to RFC2822 (although not 5322 yet).

I would think that moving the definition of form handling and input types to a separate document which HTML5 and other specifications would reference would help greatly in the modularization of HTML, but the split probably requires some refinement.

> For URI normalization, HTML5 resolving/normalization seems to be generic. 

Yes, I think URI normalization and resolution does not belong in the HTML5 document. I think this belongs also as a separate topic, perhaps as a standards-track update to RFC 3986.

> If the mailto RFCs specified exactly how mailto URIs should be normalized
>  ("mailto:?subject=1 √2" -> "mailto:?subject=1%20%E2%88%9A2" for example) 
> and it differs from HTML5's, then perhaps HTML5 can defer to the mailto 
> RFCs when dealing with 'mailto:'. But, that might be up to browser vendors
>  also to accept having non-generic handling (which I personally think they 
> should in this case).

I’m unhappy with the idea that mailto URIs should be "normalized" as opposed
to "resolved". If you have a URI that starts with 'mailto:' and some action
that you wish to perform. In some cases, form submission can be characterized
as first creating a URI and then resolving the URI (perhaps after normalization)
but this isn't the case for POST, for multipart/form-data, and so I don't 
think it is itself a URI normalization issue.

Larry
--
http://larry.masinter.net

Received on Wednesday, 11 March 2009 17:50:03 UTC