> On 5 Mar 2015, at 19:56, Martin Thomson <[email protected]> wrote:
>
> On 5 March 2015 at 07:21, Francois Le Faucheur (flefauch)
> <[email protected]> wrote:
> ...
>> I have added this at the end of S3.3:
>>
>> NEW:
>> “
>> An uCDN-side implementation of the CDNI Logging interface MUST reject a CDNI
>> Logging File that does not comply with the occurences specified above for
>> each and every directive. For example, an uCDN-side implementation of the
>> CDNI Logging interface receiving a CDNI Logging file with zero occurence of
>> the Version directive, or with two occurences of the Integrity-hash, SHOULD
>> reject this CDNI Logging File.
>> "
>
> That SHOULD needs to be qualified somehow. Why would an
> implementation ignore the SHOULD and not reject the file?
Sorry that was a typo. It was meant to be a MUST (like in the previous
sentence). It has been updated.
>
>
>> And also edited the end of S3.4 as per the following:
>>
>> OLD:
>> "
>> An uCDN-side implementation of the CDNI Logging interface MUST be
>> able to accept CDNI Logging Files with CDNI Logging Records of
>> Record-Type "cdni_http_request_v1" containing any CDNI Logging Field
>> defined in Section 3.4.1 as long as the CDNI Logging Record and the
>> CDNI Logging File are compliant with the present document.
>> “
>> NEW:
>> “
>> An uCDN-side implementation of the CDNI Logging interface MUST be
>> able to accept CDNI Logging Files with CDNI Logging Records of
>> Record-Type "cdni_http_request_v1" containing any CDNI Logging Field
>> defined in Section 3.4.1 as long as the CDNI Logging Record and the
>> CDNI Logging File are compliant with the present document.
>>
>> In case, an uCDN-side implementation of the CDNI Logging interface receives
>> a CDNI Logging File with HTTP Request Logging Records that do not contain
>> field values for exactly the set of field names actually listed in the
>> preceding “Fields” directive, the implementation SHOULD reject those HTTP
>> Request Logging Records, and SHOULD accept the other HTTP Request Logging
>> Records .
>> "
>
> Again, SHOULD is weak without some support.
I can’t really think of a good reason to not do that, so those have been turned
into MUST.
>
>> NEW:
>> “
>> The entity transmitting a CDNI Logging File as per the present document MUST
>> set the value to "CDNI/1.0”. In the future, other versions of CDNI Logging
>> File might be specified; those would use a value different to "CDNI/1.0”
>> allowing the entity receiving the CDNI Logging File to identify the
>> corresponding version.
>> "
>
> This doesn't tell a receiver what to do with "CDNI/1.1". It needs to do that.
This discussion made me realise that we need a registry for Versions. Thank you.
I have added a new registry:
NEW:
“
6.2. CDNI Logging File Version Registry
The IANA is requested to create a new registry, CDNI Logging File
Version.
The initial contents of the CDNI Logging Logging File Version
registry comprise the value "CDNI/1.0" specified in Section 3.3 of
the present document, and are as follows:
+-----------------+-----------+----------------------------------+
| Version | Reference | Description |
+-----------------+-----------+----------------------------------+
| CDNI/1.0 | RFC xxxx | CDNI Logging File version 1.0 |
| | | as specified in RFC xxxx |
+-----------------+-----------+----------------------------------+
Figure 9
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document]
Within the registry, Version values are to be allocated by IANA
according to the "Specification Required" policy specified in
[RFC5226]. Version values are to be allocated by IANA with a format
as specified for the Version directive in Section 3.3.
"
and added this text:
NEW:
"
An entity receiving a CDNI Logging File with a value set to "CDNI/1.0” MUST
process the CDNI Logging File as per the present document. An entity receiving
a CDNI Logging File with a value set to a different value MUST process the CDNI
Logging File as per the specification referenced in the CDNI Logging File
Version registry (see section 6.2) if the implementation supports this
specification and MUST reject the CDNI Logging File otherwise.
“
I’ll wait to hear from you, and if you’re OK with taht I’ll reach out to the
IANA to notify them about the extra registry to be created.
>
>> NEW:
>> "
>> The general TLS usage guidance in [I-D.ietf-uta-tls-bcp] SHOULD be
>> followed.
>> “
>
> In this case, a SHOULD is OK, I suppose.
>
>> S 3.4.1
>> o cs(<HTTP-header-name>):
>> HTTP header fields, esp. in HTTP/2 can contain HTAB, even if that
>> isn't permitted by the grammar. You probably want to describe how
>> that is handled.
>>
>>
>> Since the value of the HTTP header is encoded as a “quoted string”
>> (QSTRING), is it not OK to have a HTAB within the HTTP header value as long
>> as it is properly bracketed by the Quotes?
>
> Header field *names* aren't quoted.
>
Oh, I see , invalid HTAB inside the HTTP header name itself.
> My point was that even though this is a bug in the sender, you are
> going to see these in the wild and they are going to screw up the
> logging file.
I have added this:
NEW:
“
The entity transmitting the CDNI Logging File MUST ensure that the
<HTTP-header-name> of the cs(<HTTP-header-name) listed in the Fields directive
comply with HTTP specifications and, in particular, does not include any HTAB,
since this would prevent proper parsing of the Fields directive by the entity
receiving the CDNI Logging File.
"
>
>> The document says that "client-side implementation of the CDNI Logging
>> interface MAY pull, at its convenience, a CDNI Logging File “ using standard
>> HTTP. Since range request is just a standard HTTP mechanism, the clien-side
>> may use it if it sees fit.
>> Do you feel it is worth specifically calling out that range requests can be
>> used?
>> No problem in doing that if you feel it is useful.
>
> Nah, that's OK.
Thanks for helping improve our document.
Francois
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
