Re: [http-auth] WGLC on the MutualAuth drafts

[大岩寛 <[e-mail]>]

Dear Julian,

My understanding of your message is that you'll just define the
value encoding of I18n string, and all RFCs referring it must say,
for example, "the value of parameter foo will be encoded by RFC5987bis,
like foo=UTF-8''caf%C3%89 ."
Is it right? If not, please forgive me and skip the rest of my message.

If it's true, in that case, I'm *not in favor* of "obsoleting" or "replacing"
the current 5987 by it, as it simply drops the current feature, not replacing it.

Both defining the value encoding 
And defining the general parameter extension framework
is definitely the two existing features of current 5987.
I'm relying basically on *the latter feature*.

The most important value of the current 5987 is that non-percent-encoded
ASCII parameters and percent-encoded 5987-style parameters
can co-exist and deterministically distinguished,
while keeping ASCII-only use cases wire-compatible.
Yes, it's a bit tricky encoding, but it works.
If I need to say "this parameter will be 5987bis-value-encoded
(so %20 MUST be treated as a space, not percent-two-zero)",
it's no better than simple percent-encoded UTF-8,
especially with cryptographic operations
(which requires binary-to-binary equivalence and thus denies
almost all kinds of character encoding negotiations).

The reason I accepted to adopt RFC5987 in Fall 2014 is that
consistent support of it would make better promotion for
some future "common libraries", you favorite term, 
to transparently support internationalized HTTP authentication.
It's not only for "my" proposals but also for all future proposals.
Without the tag extension framework part, I find little value for it.

More to say, should you say it, I strongly think that you should 
say it before I *did* accept the proposed use of 5987 (it was proposed by you!).
If I knew your plan at that point, and if only the value encoding part is
defined in 5987bis, I have no reason to adopt RFC 5987 *and 5987bis*.
I'd simply chose to use simple percent-encoded UTF-8, without any charset tag,
It's much simpler and much much easier to deploy with existing libraries.

-- 
Yutaka OIWA, Ph.D.       Leader, Cyber Physical Architecture Research Group
                                  Information Technology Research Institute
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[e-mail]>, <[e-mail]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

> -----Original Message-----
> From: Julian Reschke [mailto:[e-mail]]
> Sent: Tuesday, July 5, 2016 7:09 PM
> To: 大岩寛 <[e-mail]>; Yoav Nir <[e-mail]>; httpauth
> mailing list <[e-mail]>
> Subject: Re: [http-auth] WGLC on the MutualAuth drafts
> 
> On 2016-07-05 06:24, 大岩寛 wrote:
> > ...
> > [3]
> >> FYI: I'm in the process of revising RFC 5987, and that ABNF
> >> production is going to be removed. Seems we need to coordinate here.
> >
> > Can you tell us some more detail about this?
> > May be we also need to coordinate with the Chairs about the scheduling.
> > ...
> 
> When I wrote RFC 5987, I put too much emphasis in being consistent with RFC
> 2231 and in the ABNF.
> 
> The plan for RFC 5987bis is that it'll just define the grammar for the field
> *value*. I'll stay away from defining and redefining parameters in general.
> 
> Best regards, Julian
>