Re: Slug header encoding

[James M Snell <jasnell@xxxxxxxxx>]

I would have absolutely no problem requiring that implementations
support UTF-8 encoding with RFC2047.  I also have no problem with the
idea of supporting %-encoding of the Slug value.  There's actually
nothing in the spec stopping implementations from doing so today other
than the not being able to predict how servers will handle it.
Unfortunately, I don't think there's really any chance of getting a
consensus on using the %-encoding approach.

- James

ASAKURA Hiroshi wrote:
> Hi, all
> 
> I would like to propose to change the Slug header encoding method
> from RFC2047 to RFC3986(%-encodings). The reason is following:
> 
>   1. RFC2047 has some issues.
>      I wrote an article, see <http://photofriend.blogzine.jp/tech/>.
> 
>   2. IRI and URI uses %-encodings.
>      HTTP header has IRI or URI. These identifier can use
>      percent encodings, and it is convenient for developer to use
>      same encoding method for Slug header.
> 
>   3. We should utf-8 for non-ASCII characters.
>      Recently, specifications of IETF supports Unicode.
>      For example, IRI(RFC3987):
>      >An IRI is a sequence of characters from the Universal Character
>      >Set(Unicode/ISO 10646).
> 
>      RFC2047 supports any encodings such as iso-2022-jp, shift-jis,
>      euc-jp, utf-8 (for Japanese Kanji). APP Servers need to support
>      them. But RFC3986 assume utf-8. APP Servers only need to
>      support it.
> 
> 
>