| It is not an optional extension for those Content Delivery Networks that are conforming to this specification. That’s two qualifiers: CDNs and conforming.
I can have a perfectly fine HTTP/1.1 implementation that never sends a cdn-info. If I have such an implementation, nothing about this new specification is forcing me to update my implementation. Even if my implementation is used in CDNs, it is still perfectly compliant with 7230/7231. It’s just not compliant with the new specification.
If we’re not requiring existing implementations to be updated, we usually don’t use the ‘UPDATES’ keyword.
Yoav
Hi Mark,
The RFC states:
Conforming Content Delivery Networks SHOULD add a cdn-info to this
header field in all requests they generate or forward (creating the
header field if necessary) It says SHOULD, not OPTIONAL. So I don't think it is optional extension in cdn to use this protocol field.
On Fri, Feb 8, 2019 at 6:51 AM Mark Nottingham < mnot@xxxxxxxx> wrote: Hello Abdussalam,
> On 6 Feb 2019, at 3:22 pm, Abdussalam Baryun <abdussalambaryun@xxxxxxxxx> wrote:
>
> I think while defining new protocol-header-field for detections, it should update rfc7231 or 7230.
We don't use 'updates' to denote the minting of an optional extension to the protocol; finding those is the purpose of the registry, not the 'updates' relationship.
IMHO to find standards and related is by document-relationship first (RFC editor job), not by operation-assignment, and all protocols need to register their operation-assignments for the environment-regulation, and doing registering is for operation-assignments (IANA job). I think any extension RFC standard SHOULD be an update to its protocol RFC.
Best Regards, AB
|
