Subject: [CDNi] Mark's review of cdni-logging text related to "compressed" transfer

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 27 Sep 2013 12:57:22 +0000

Hello Mark,

For memory, we discussed the following during the CDNI WG meeting in Berlin:
* we'd like to be able to exchange "CDNI Logging Files" in both uncompressed and compressed content encoding.
* this is a common situation already well addressed by HTTP
* "usual way is to advertise one URL then say in the content encoding whether it is compressed"

We have attempted to reflect this in the new version of our "CDNI Logging interface":
http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-06.txt

Could you (or another HTTP expert that you may designate) have a look and let us know if you have comments, suggestions, concerns?

The relevant part is section "4.2.  CDNI Logging File Pull" of http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-06.txt.
For convenience, I have quoted below the related subset of the text, highlighing in red the text discussing the compressed encoding topic.

Thanks for your help.

Francois

"
   A client-side implementation of the CDNI Logging interface MUST pull,
   at its convenience, a CDNI Logging File that is published by the
   server-side in the CDNI Logging Feed.  To do so, the client-side:

   o  MUST use HTTP v1.1 ( [RFC2616])

   o  SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS")
      as per [RFC2818] whenever protection of the CDNI Logging
      information is required (see Section 6.1)

   o  MUST use the URI that was associated to the CDNI Logging File
      (within the "src" attribute of the corresponding atom:content
      element) in the CDNI Logging Feed

   o  MUST support exchange of uncompressed CDNI Logging Files (i.e.
      using "identity" content coding as defined in [RFC2616])

   o  SHOULD support exchange of gzip compressed CDNI Logging Files
      (i.e. using "gzip" content coding as defined in [RFC2616])

…

 The server-side implementation MUST respond to any valid pull request
   by a client-side implementation for a CDNI Logging File published by
   the server-side in the subscription document of the CDNI Logging
   Feed.  The server-side implementation:

   o  MUST handle the client-side request as per HTTP v1.1

   o  MUST include the CDNI Logging File identified by the request URI
      inside the body of the HTTP response

   o  MUST support exchange of uncompressed CDNI Logging Files (i.e.
      using "identity" content-coding as defined in [RFC2616])

   o  SHOULD support exchange of gzip compressed CDNI Logging Files
      (i.e. using "gzip" content-coding as defined in [RFC2616]

   Content negotiation approaches defined in [RFC2616] (e.g. using
   Accept-Encoding request-header field or Content-Encoding entity-
   header field) MAY be used by the client-side and server-side
   implementations to establish the content-coding to be used for a
   particular exchange of a CDNI Logging File.
"

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 Sep 2013 15:35:27 +1000

Hi Francois,

>       using "identity" content coding as defined in [RFC2616])

"identity" was left in 2616 by mistake; there is no identity coding. See:
  http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-5.3.4
and
  http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-3.1.2.1

>    particular exchange of a CDNI Logging File.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 30 Sep 2013 07:28:25 +0000

Hello Mark,

Thanks much for your reviwe and comment.
Looking at the pointers you sent, I understand that "identity" can still be conveyed by the client inside "Accept-Encoding" but is no longer to be conveyed by the server inside "Content-Encoding".
To reflect this, I tweaked the text (see below) using the phrase "without encoding applied to the representation".
Let us know if this all good now, or not.
Thanks

Francois

"

   o  MUST support exchange of CDNI Logging Files without content encoding applied to the representation

   o  SHOULD support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC2616]) applied to the representation

…

   o  MUST support exchange of CDNI Logging Files without content encoding applied to the representation

   o  SHOULD support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC2616]) applied to the representation

On 30 Sep 2013, at 07:35, Mark Nottingham <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi Francois,

On 27/09/2013, at 10:57 PM, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

"

…

Cheers,