Re: [ietf-types] The application/www-form-urlencoded format

["Martin J. Dürst" <[e-mail]>]

Hello Björn,

Can you give some rough information on where 
application/www-form-urlencoded is implemented or implementation is planned?

Also, in many cases, an identifier without x- denotes just the same as 
the identifier with the x-. I think it would be good if the registration 
template contained at least a small reminder and pointer to make clear 
that it's not exactly the same as the x- variant.

Regards,   Martin.


On 2010/09/26 6:14, Bjoern Hoehrmann wrote:
> Hi,
>
>    http://tools.ietf.org/html/draft-hoehrmann-urlencoded -- the draft de-
> scribes the application/www-form-urlencoded format, a variant of the
> application/x-www-form-urlencoded format first described in RFC 1866.
> RFC 1866 recommended that implementations also accept ";" as separator,
> which the draft permits and prefers, and RFC 1866 failed to define the
> character encoding to use, the draft addresses that by mandating UTF-8,
> which is universally recommended these days. As the ampersand will be
> handled as it would be for the RFC 1866 format, I believe the formats
> are similar enough that using the very similar name is justified. [1]
>
> The draft probably still has some rough edges in the prose but the
> format is not going to change. I believe it addresses the feedback I
> got since the first draft published four years ago; public feedback at
> http://lists.w3.org/Archives/Public/www-archive/2006Sep/thread.html#msg30
>
> The template is as follows. Looking at RFC 4288 again, it seems instead
> of "8bit" the encoding considerations should be "binary".
>
>     Type name:               application
>     Subtype name:            www-form-urlencoded
>     Required parameters:     none
>     Optional parameters:     none
>
>        Note: The media type does not have a 'charset' parameter, it
>        is incorrect specify one and to associate any significance to
>        it if specified. The character encoding is always UTF-8. The
>        Unicode encoding form signature is not supported; a leading
>        U+FEFF character will be considered part of a<name>.
>
>     Encoding considerations: 8bit
>
>     Security considerations: See section 9.
>     Interoperability considerations:
>        None, except as noted in other sections of this document.
>
>     Published specification: RFC XXXX
>     Applications that use this media type:
>        Systems that interchange data sets of name-value pairs.
>
>     Additional information:
>
>        Magic number(s):             n/a
>        File extension(s):           n/a
>        Macintosh file type code(s): TEXT
>        Fragment identifiers:        n/a
>
>     Person&  email address to contact for further information:
>        See Author's Address section.
>
>     Intended usage:          COMMON
>     Restrictions on usage:   n/a
>     Author:                  See Author's Address section.
>     Change controller:       The IESG.
>
> [1] The regular expression to match both names is slightly simpler if
>      they only differ in the "x-", and it seems fitting to standardize
>      an "x-" type by removing the "x-", but if there is a good argument
>      why using similar names is a bad idea, I am also quite open to name
>      it application/name-value-pairs or something like that instead.
>
> Let me know if anyone sees any other problem. Thanks,

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[e-mail]