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

From: 大岩寛 <[email-masked]>
Date: Tue, 5 Jul 2016 04:24:19 +0000

Dear Julian,

Thank you very much for very valuable comments.
I reflected most of your comments into the draft and
the draft is now on 
https://raw.githubusercontent.com/yoiwa/httpauth-mutual/master/http-auth-extension.txt
I'll submit it to IETF around tomorrow.

About three points which seems important...

[1]
> b) this introduces a syntax for private extensions that is awfully similar to
> the "x-" convention that we just deprecated a few years ago...

I'm of course aware of the discussion on "x-dash-considered-harmful", and
the current specification carefully follows the practice defined in
RFC6648 (BCP178).  In particular, it treats domain-based keywords
"just as a namespace", which is similar to the SSH algorithm specifiers.
The revised draft clarifies that the "official" extensions can also use
domain-based keywords if they want.
("x-" is especially considered harmful when it requires to 
 handle them specially, differently from non-x things.)

I think that, as an extension point, it is important for
developers to easily deploy their experimental ideas to try.
Another idea is to lower the IANA registry barrier to just
"first-come-first-serve", but it may let IANA process many trivial
(almost garbage-like) registrations.

[2]
> I'm not totally convinced that a new header field is needed here? Is
> there a reason why sending "WWW-Authenticate" with a 2xx response
> wouldn't work?
> 
> (And yes, we probably discussed this several times already, but it would
> be good to summarize the outcome over here)

I'll add some text regarding this.

[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.

-- 
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: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Julian Reschke <[email-masked]>
Date: Tue, 5 Jul 2016 12:08:48 +0200

On 2016-07-05 06:24, 大岩寛 wrote:
> ...
> ...

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Jul 2016 14:26:12 +0300

Hi, Julian

> On 5 Jul 2016, at 1:08 PM, Julian Reschke <[email-masked]> wrote:
> 
> 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.
> 

I’m not sure I follow what kind of coordination is needed here. IMO the -extension document is ready to go to IETF LC (after the authors make the necessary changes you’ve already discussed). I think it’s going to be past the IESG before 5987bis is ready. Do you see any need to make this document depend on 5987bis instead of 5987? Will making this change require any changes to the ABNF in the document?

If not, I think we can proceed with a reference to 5987, and then when 5987bis obsoletes 5987 it will still be fine. Am I missing something?

Thanks

Yoav

---

From: Julian Reschke <[email-masked]>
Date: Tue, 5 Jul 2016 13:39:07 +0200

> I’m not sure I follow what kind of coordination is needed here. IMO the -extension document is ready to go to IETF LC (after the authors make the necessary changes you’ve already discussed). I thin…

Yes, IMHO it would require changes.

> If not, I think we can proceed with a reference to 5987, and then when 5987bis obsoletes 5987 it will still be fine. Am I missing something?

Technically it would still be fine, but it would have a normative 
reference on an obsoleted spec.

I think it would be better to coordinate, and have this new document 
reference 5987bis.

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Jul 2016 18:09:40 +0300

> On 5 Jul 2016, at 2:39 PM, Julian Reschke <[email-masked]> wrote:
> 

OK. Any chance you and the authors can get the changes done before Friday’s deadline?

> Technically it would still be fine, but it would have a normative reference on an obsoleted spec.
> 
> I think it would be better to coordinate, and have this new document reference 5987bis.
> 
> Best regards, Julian
> 
> 
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 5 Jul 2016 17:17:13 +0200

> OK. Any chance you and the authors can get the changes done before Friday’s deadline?

Very unlikely on my side.

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Jul 2016 22:15:22 +0300

> On 5 Jul 2016, at 6:17 PM, Julian Reschke <[email-masked]> wrote:
> 

So what kind of changes are we talking about?  Just the ABNF block, or a bunch of surrounding text?

The reason I’m asking is that I think if it’s just the ABNF we can progress the document with a note to the AD that the ABNF will need an update, and finish that during IETF last call. Otherwise we’re delaying by another 3-4 weeks. Of course, considering how long this has been in process 3-4 extra weeks are no big deal, but why procrastinate if we don’t have to?

Regards,

Yoav

---

From: 大岩寛 <[email-masked]>
Date: Thu, 7 Jul 2016 13:32:15 +0000

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.

> -----Original Message-----
> From: Julian Reschke [mailto:[email-masked]]
> Sent: Tuesday, July 5, 2016 7:09 PM
> To: 大岩寛 <[email-masked]>; Yoav Nir <[email-masked]>; httpauth
> mailing list <[email-masked]>
> Subject: Re: [http-auth] WGLC on the MutualAuth drafts
> 
> >> 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.
> >
> 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
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 7 Jul 2016 15:47:27 +0200

> Is it right? If not, please forgive me and skip the rest of my message.

Something like that.

(did you want to say "foo*" here?)

> I'm relying basically on *the latter feature*.

The problem is that there isn't a generic parameter framework. For  
instance, header fields differ in whitespace and error handling.

(I agree that it would be good if there was something like that, but  
that's a separate discussion)

> almost all kinds of character encoding negotiations).

We'll keep the recommendation to mark the use of the encoding by  
appending "*" to the parameter name, if that's what you're concerned about.

Best regards, Julian

---

From: 大岩寛 <[email-masked]>
Date: Thu, 7 Jul 2016 14:14:43 +0000

Dear Julian,

> > 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,

Dropping of * is intentional, to mean "someone only uses encoded values,
without the field extending mechanism by appending *."

> The problem is that there isn't a generic parameter framework. For instance,
> header fields differ in whitespace and error handling.
> 
> (I agree that it would be good if there was something like that, but that's
> a separate discussion)

(I agree it, as it was really tricky to write my draft regarding it :-)

> > The most important value of the current 5987 is that
...
> > denies almost all kinds of character encoding negotiations).
> 
> We'll keep the recommendation to mark the use of the encoding by appending "*"
> to the parameter name, if that's what you're concerned about.

Hmm, what a "recommendation" means for me is important.
Restructuring the definitions is no matter and OK for me.

It can be optional (as it is currently), but at least
I need to be possible to say implementers, showing printed paper of RFC5987bis,
"OK, it's the "common" way written here, so let's implement 
 this translation as a common utility function."
If it looks like "someone invented to append *, it might be interesting",
it's too weak.

---

From: 大岩寛 <[email-masked]>
Date: Thu, 7 Jul 2016 14:23:51 +0000

Dear Yoav,

I have not yet have enough information to discover how we should do with
RFC5987bis, including three options:
 1) Keep referring to current RFC5987 until next possible revision,
 2) Wait for bis, or follow it in IETF LC,
or unlikely (hopefully,)
 3) Rethink of the WG decision on RFC5987 and go back to WG discussion.
However, nothing of above plans will prohibit me to submit the 
revised drafts before the "submission lockout period".
So, I'll submit the revised drafts
with keeping references to RFC5987 as it is currently.
If we later decide to make change at this moment (with a few weeks delay),
let us consider it just as intermediate drafts, and I'll re-submit the
more-revised drafts just after the lockout period.

Thanks,

> From: http-auth [mailto:[email-masked]] On Behalf Of Yoav Nir
> Sent: Wednesday, July 6, 2016 4:15 AM
> To: Julian Reschke <[email-masked]>
> Cc: httpauth mailing list <[email-masked]>
> >>>> I’m not sure I follow what kind of coordination is needed here. IMO the
> -extension document is ready to go to IETF LC (after the authors make the
> necessary changes you’ve already discussed). I think it’s going to be past
> the IESG before 5987bis is ready. Do you see any need to make this document
> depend on 5987bis instead of 5987? Will making this change require any changes
> to the ABNF in the document?
> >>>
> The reason I’m asking is that I think if it’s just the ABNF we can progress
> the document with a note to the AD that the ABNF will need an update, and finish
> that during IETF last call. Otherwise we’re delaying by another 3-4 weeks.
> Of course, considering how long this has been in process 3-4 extra weeks are
> no big deal, but why procrastinate if we don’t have to?
> 
> Regards,
> 
> Yoav
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

---

From: Julian Reschke <[email-masked]>
Date: Thu, 7 Jul 2016 16:24:05 +0200

> without the field extending mechanism by appending *."

OK, not sure this is a good idea, though.

> If it looks like "someone invented to append *, it might be interesting",

Well, feel free to provide feedback on rfc5987bis so we can get this right.

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Jul 2016 17:35:04 +0300

Hi.

Definitely submit the revised draft. At the conclusion of this thread, we can decide whether to proceed with RFC 5987, wait for 5987bis with the document in the working group, or proceed with the document and have it wait for the 5987bis in the RFC editor’s queue.

Just one question: This thread has been about the -extension document. The base mutual document also references RFC 5987. Will that need any updates (except changing the RFC number in the reference), or is that document fine the way it is?

Thanks

Yoav

> On 7 Jul 2016, at 5:23 PM, 大岩寛 <[email-masked]> wrote:
> 
> Dear Yoav,
>

---

From: 大岩寛 <[email-masked]>
Date: Thu, 7 Jul 2016 15:00:47 +0000

The situation is the same with the mutual document.
If any changes are required to the httpauth-extension.
the same changes will be to the auth-mutual.

> From: Yoav Nir [mailto:[email-masked]]
> Sent: Thursday, July 7, 2016 11:35 PM
> To: 大岩寛 <[email-masked]>
> Definitely submit the revised draft. At the conclusion of this thread, we can
> decide whether to proceed with RFC 5987, wait for 5987bis with the document
> in the working group, or proceed with the document and have it wait for the
> 5987bis in the RFC editor’s queue.
> 
> Just one question: This thread has been about the -extension document. The base
> mutual document also references RFC 5987. Will that need any updates (except
> changing the RFC number in the reference), or is that document fine the way
> it is?
> 
> Thanks
> 
> Yoav
> 
> > I have not yet have enough information to discover how we should do
> > with RFC5987bis, including three options:
> > 2) Wait for bis, or follow it in IETF LC, or unlikely (hopefully,)
> > However, nothing of above plans will prohibit me to submit the revised
> > drafts before the "submission lockout period".
> > If we later decide to make change at this moment (with a few weeks
> > delay), let us consider it just as intermediate drafts, and I'll
> > re-submit the more-revised drafts just after the lockout period.
> >
> > Thanks,
> >
> > --
> >> -extension document is ready to go to IETF LC (after the authors make
> >> the necessary changes you’ve already discussed). I think it’s going
> >> to be past the IESG before 5987bis is ready. Do you see any need to
> >> make this document depend on 5987bis instead of 5987? Will making
> >> this change require any changes to the ABNF in the document?
> >>>>>
> >>>> OK. Any chance you and the authors can get the changes done before
> >>>> Friday’s
> >> deadline?
> >>>
> >> The reason I’m asking is that I think if it’s just the ABNF we can
> >> progress the document with a note to the AD that the ABNF will need
> >> an update, and finish that during IETF last call. Otherwise we’re delaying
> by another 3-4 weeks.
> >> Of course, considering how long this has been in process 3-4 extra
> >> weeks are no big deal, but why procrastinate if we don’t have to?
> >>
> >> Regards,
> >>
> >> Yoav
> >>

---

From: 大岩寛 <[email-masked]>
Date: Thu, 7 Jul 2016 15:04:42 +0000

Thank you, Julian,

> > Dropping of * is intentional, to mean "someone only uses encoded
> > values, without the field extending mechanism by appending *."
> 

Thanks. I'm not proposing, it's just an example to clarify :-)

> Well, feel free to provide feedback on rfc5987bis so we can get this right.

Yes, I'll definitely contribute.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Sat, 9 Jul 2016 12:34:10 +0200

On 2016-06-18 11:59, Julian Reschke wrote:
> ...
> 4.  Authentication-Control header
>
>     Authentication-Control = 1#Auth-Control-Entry
>     Auth-Control-Entry     = auth-scheme 1*SP 1#auth-control-param
>     auth-control-param     = extensive-token BWS "=" BWS token
>                            / extensive-token "*" BWS "=" BWS ext-value
>     ext-value              = <see RFC 5987, Section 3.2>
>
>       Figure 4: the BNF syntax for the Authentication-Control header
>

Sorry for causing confusion.

Since I wrote this I went back to RFC 5987bis, and it turns out that the 
ABNF production I intended to kill is *ext-parameter*, not *ext-value*.

See change in 
<https://tools.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rfc5987bis-02.txt#part-4> 
(just submitted).

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Mon, 11 Jul 2016 08:54:05 +0300

> On 9 Jul 2016, at 1:34 PM, Julian Reschke <[email-masked]> wrote:
> 
> Since I wrote this I went back to RFC 5987bis, and it turns out that the ABNF production I intended to kill is *ext-parameter*, not *ext-value*.
> 
> See change in <https://tools.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rfc5987bis-02.txt#part-4> (just submitted).

OK, and comparing RFC 5987 and rfc5987bis I see that the definition of ext-value is the same. 

So does that mean we’re good to go on these drafts?

Yoav

---

From: 大岩寛 <[email-masked]>
Date: Mon, 11 Jul 2016 07:08:15 +0000

Dear Yoav and Julian,

I just took a quick observation of the diff URL, and
it seems to be mostly fine to go forward.

Dear Julian,

The current text in Section 3.2.1 and 4 is really fine for me.
If the changes (Appendix C) goes to the final text,
I prefer

  Do not attempt to define a generic parameter ABNF; just concentrate	
  on the parameter value syntax.

to be changed something like below,

  Do not define a parameter ABNF in a generic way;  It is clarified that
  the formal syntax should be defined in each document referring to this document.

so that the relation between the generic convention and the referring
document is clearer.
"Concentrate on the parameter value" is unclear for the people
who does not share the background reason not defining the key syntax as ABNF.
They can be misleaded to the understanding that we're throwing
the star-convention away, too.
Maybe the background reason can be expressed somewhere as an informative, 
explanatory text.

> Sent: Monday, July 11, 2016 2:54 PM
> Subject: Re: [http-auth] RFC5987bis, was: WGLC on the MutualAuth drafts
> 
> 
> > Since I wrote this I went back to RFC 5987bis, and it turns out that the ABNF
> production I intended to kill is *ext-parameter*, not *ext-value*.
> >
> > See change in
> <https://tools.ietf.org/rfcdiff?url2=draft-ietf-httpbis-rfc5987bis-02.txt#
> part-4> (just submitted).
>