Subject: IANA URIS, was: APPSDIR review of draft-ietf-httpbis-p1-messaging-24

From: Julian Reschke <[email-masked]>
Date: Sun, 27 Oct 2013 22:18:06 +0100

On 2013-10-27 19:44, S Moonesamy wrote:
> ...
> Nits:
>
> For Section 8.1, the Message Header Field Names registry is at
> http://www.iana.org/assignments/message-headers/
>
> For Section 8.2, the URI Schemes registry is at
> http://www.iana.org/assignments/uri-schemes/
> ...

Ack.

Out of curiosity: is there an obvious way to find out what the 
"canonical" URI of a registry is?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Oct 2013 16:53:28 +0100

On 2013-10-27 19:44, S Moonesamy wrote:
> ...
> The HTTP Transfer Coding namespace (Section 8.4) is currently "First
> Come First Served".  The new registration procedure required IETF
> Review.  What is the reason for the change?
> ...

My understanding is that we wanted to set a high bar because this really 
ought to happen with lots of care and review.

The related ticket is 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/188>, and it was 
discussed during IETF 75 
(<http://tools.ietf.org/wg/httpbis/minutes?item=minutes75.html>).

Best regards, Julian

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Oct 2013 09:55:10 -0700

Hello,

While I was reviewing other drafts in the set I noticed that Section 
3.2.4 of draft-ietf-httpbis-p1-messaging-24 has the following:

   "Historically, HTTP header field values could be extended over
    multiple lines by preceding each extra line with at least one space
    or horizontal tab (obs-fold).  This specification deprecates such
    line folding except within the message/http media type
    (Section 8.3.1).  A sender MUST NOT generate a message that includes
    line folding (i.e., that has any field-value that contains a match to
    the obs-fold rule) unless the message is intended for packaging
    within the message/http media type."

There is an IETF specification which interpreted Section 4.2 of RFC 
2616 as follows:

   "the HTTP header syntax allows extending single header values across
    multiple lines, by inserting a line break followed by whitespace"

I'll classify deprecating line folding as an issue.

Section 4.2 of RFC 2616 (and RFC 2068) follows the same generic 
format as that given in Section 3.1 of RFC 822.  Section 2.2 of RFC 
2616 states that:

   "HTTP/1.1 header field values can be folded onto multiple lines if the
    continuation line begins with a space or horizontal tab."

I suggest that implementors of specifications which have a dependency 
on RFC 2616 review the relevant section in 
draft-ietf-httpbis-p1-messaging-24 about line folding and comment if 
they consider the deprecation as a problem.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 29 Oct 2013 06:39:14 -0700

Hi Julian,
At 08:53 28-10-2013, Julian Reschke wrote:
>My understanding is that we wanted to set a high bar because this 
>really ought to happen with lots of care and review.
>
>The related ticket is 

I'll consider this as addressed.

Regards,
S. Moonesamy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Oct 2013 17:03:30 +0100

On 2013-10-27 19:44, S Moonesamy wrote:
> ...
> In Section 6.4
>
>    "A client SHOULD limit the number of simultaneous open connections
>     that it maintains to a given server."
>
> There is an explanation about why a specific number is not included for
> this recommendation in the paragraphs following the above text.  I read
> Issue #131.  I don't see any discussion of the tradeoffs in Section
> 6.4.  The is a note about servers may reject an excessive number of
> connections from a client if they deem that it is abusive.
> ...

I have trouble parsing this comment. Do you see an issue here?

Best regards, Julian

---

From: S Moonesamy <[email-masked]>
Date: Wed, 30 Oct 2013 01:31:27 -0700

Hi Julian,
>I have trouble parsing this comment. Do you see an issue here?

I read the text again (Section 6.4).  It is difficult to say what is 
deemed abusive.  You could get around that with, for example:

   A client SHOULD limit the number of simultaneous open connections
   that it maintains to a given server as each connection consumes
   server resources.

Please note that I used some text from the third paragraph of that section.

Regards,
S. Moonesamy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 09:50:57 +0100

> Please note that I used some text from the third paragraph of that section.

Well, there are more reasons for limiting the connection; that's why we 
have a separate paragraph about it. Just moving one of them up here 
doesn't look like an improvement to me.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 14:53:36 +0100

On 2013-10-28 17:55, S Moonesamy wrote:
> There is an IETF specification which interpreted Section 4.2 of RFC 2616
> as follows:
>

<http://tools.ietf.org/html/rfc4918#section-10.4.2>

So yes, this is a change from 2616 that we made due to security problems 
(header injection).

> Section 4.2 of RFC 2616 (and RFC 2068) follows the same generic format
> as that given in Section 3.1 of RFC 822.  Section 2.2 of RFC 2616 states
> that:
>
> I suggest that implementors of specifications which have a dependency on
> RFC 2616 review the relevant section in

Review is always good.

Note that the change is listed in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-24.html#rfc.section.A.2.p.8>:

"Header fields that span multiple lines ("line folding") are deprecated. 
(Section 3.2.4)"

Best regards, Julian