Re: [netconf] Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities)

[Qin Wu <[e-mail]>]

Hi, Robert:

-----邮件原件-----
>发件人: Robert Varga [mailto:[e-mail]] 
>发送时间: 2021年8月12日 6:49
>收件人: Qin Wu <[e-mail]>; Mahesh Jethanandani <[e-mail]>; [e-mail]
>主题: Re: [netconf] Compression mode vs Encoding format (draft-tao-netconf-data-export-capabilities)

>On 04/08/2021 10:17, Qin Wu wrote:
>> Hi, Mahesh:

>Hello everyone,

>> One of comments you raised in the meeting on
>> draft-tao-netconf-data-export-capabilities-05
>> (https://datatracker.ietf.org/doc/html/draft-tao-netconf-data-export-c
>> apabilities-05.txt)
>> 
>> is the relation between compression mode and Encoding format.
>> 
>> Here is a few clarifications:
>> 
>> 1.       Compression mode is not encoding format
>> 
>> Compression mode indicates that the server support data compression or 
>> deflate or gzip compression supported by NETCONF. The deflate or gzip 
>> compression will be applied to xml file.
>> 
>> It is independent from what encoding (e.g., JSON, XML, binary) is 
>> chosen for exported data.

>Perhaps we should be using different names?
[Qin Wu] Sounds good suggestion, I think encoding here is notification message encoding
Which I realize, is different from HTTP content encoding 
https://www.iana.org/assignments/http-parameters/http-parameters.xhtml
he registry currently lists:

br           Brotli Compressed Data Format                [RFC7932]     
compress     UNIX "compress" data format                  [RFC7230] Section 4.2.1
deflate      "deflate" compressed data ([RFC1951])        [RFC7230] Section 4.2.2
             inside the "zlib" data format ([RFC1950])
exi          W3C Efficient XML Interchange

>>I think the modeling intent is really to reference various media types:

>>dec:xml and dec:json correspond to
>>https://datatracker.ietf.org/doc/html/rfc8040#section-11.3
>>dec:cbor corresponds to
>>https://www.ietf.org/archive/id/draft-ietf-core-yang-cbor-16.html#name-media-types-registry

>>dec:gpb corresponds to ???

[Qin Wu] There is no official media type for protocol buffers registered with the IANA, They choose Content_type or ALT Content_type instead, see the link
https://googleapis.dev/java/google-http-client/1.29.0/com/google/api/client/protobuf/ProtocolBuffers.html
Maybe dec:gpb should be taken out.

>>Converting between encodings routinely requires understanding of the YANG model (for example instance-identifiers in JSON vs XML).

>> 2.       Compression mode is not header compression defined by HTTP2.
>> 
>> 3.       Right now, we haven’t seen any standard documenting 
>> compression mode.

>Right, but compression (in the bit stream sense) is probably best left to the transport protocol -- SSH/HTTP can routinely handle that.

>This is more akin to HTTP's Transfer-Encoding, I think.

[Qin Wu] I agree. See above the reference link:
https://googleapis.dev/java/google-http-client/1.29.0/com/google/api/client/protobuf/ProtocolBuffers.html

>Efficient XML Interchange Capability for NETCONF has been proposed
>> before
>> 
>> https://datatracker.ietf.org/doc/html/draft-varga-netconf-exi-capabili
>> ty-01 
>> <https://datatracker.ietf.org/doc/html/draft-varga-netconf-exi-capabil
> ity-01>
>> 
>> but it doesn’t reach any agreement. The idea is very close to what we 
>> propose in draft-tao-netconf-data-export-capabilities-05. But still 
>> different.

>Right, and then the exi-capability draft would define an identity derived from dec:binary (and probably a media type as well). Not that I plan to pick it up again anytime soon :)

[Qin Wu] Understood, thank for clarification.

>Regards,
>Robert

> 
> Hope this clarify your comment.
> 
>  
> 
> -Qin (On behalf of authors)
> 
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>