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? > 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. > 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. > 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. 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. > 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. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
