- From: Alexey Melnikov <alexey.melnikov@isode.com>
- Date: Wed, 5 Dec 2018 11:04:05 +0000
- To: Tommy Pauly <tpauly@apple.com>, Mark Nottingham <mnot@mnot.net>
- Cc: "Julian F. Reschke" <julian.reschke@gmx.de>, ietf <ietf@ietf.org>, draft-ietf-httpbis-cdn-loop@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org
On 04/12/2018 22:25, Tommy Pauly wrote:
>> On Dec 4, 2018, at 2:21 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>
>> Hi Julian,
>>
>>> On 3 Dec 2018, at 1:51 am, Julian Reschke <julian.reschke@gmx.de> wrote:
>>>
>>> s/[RFC7230], Section 5.7.1/Section 5.7.1 of [RFC7230]/
>>>
>>>> "tracking message forwards, avoiding request loops, and identifying
>>>> the protocol capabilities of senders along the request/response
>>>> chain."
>>>> In theory, Via could be used to identify these loops. However, in
>>>> practice it is not used in this fashion, because some HTTP servers
>>>> use Via for other purposes - in particular, some implementations
>>>> disable some HTTP/1.1 features when the Via header is present.
>>> It would be nice if this came with pointers to related bug reports so the reader could have a glance.
>>>
>>>> 2. The CDN-Loop Request Header Field
>>>> CDN-Loop: FooCDN, barcdn; host="foo123.bar.cdn"
>>>> CDN-Loop: baz-cdn; abc="123"; def="456", anotherCDN
>>>> Note that the token syntax does not allow whitespace, DQUOTE or any
>>>> of the characters "(),/:;<=>?@[]{}". See [RFC7230], Section 3.2.6.
>>> s/. See [RFC7230], Section 3.2.6./([RFC7230], Section 3.2.6)./
>>>
>>>> Likewise, note the rules for when parameter values need to be quoted
>>>> in [RFC7231], Section 3.1.1.
>>> s/[RFC7231], Section 3.1.1/Section 3.1.1 of [RFC7231]/
>> Is this just personal preference, or is there a reason you suggest this form? I see nothing about it in RFC7322.
> In fact, RFC 7322 actually includes both styles of section reference:
>
> Status of This Memo
>
> ... see Section 2 of RFC 5741.
>
> 4.8.4. Internationalization Considerations Section
>
> ... see "IETF Policy on Character Sets
> and Languages" [BCP18], Section 6, for more information.
I suggest we leave this document as-as and let RFC Editor to sort this
out. They are quite good at this.
Received on Wednesday, 5 December 2018 11:05:19 UTC