Re: [netmod] draft netmod charter update proposal

[Robert Wilton <[e-mail]>]

Hi Lada,


On 01/03/2017 10:45, Ladislav Lhotka wrote:
>> On 1 Mar 2017, at 10:46, Juergen Schoenwaelder <[e-mail]> wrote:
>>
>> On Wed, Mar 01, 2017 at 09:32:37AM +0100, Ladislav Lhotka wrote:
>>>> So are we going through all NETMOD/NETCONF documents now to replace
>>>> 'encoding' with 'representation', which also includes changing
>>>> document titles? I am not necessarily against that change but I think
>>>> it is good to understand the implications that go well beyond some
>>>> charter text. (I did do my own analysis how frequently we have used
>>>> encoding in our documents, I assume others have done this as well.)
>>>>
>>> I don't think it is necessary to immediately update old RFCs with this new term. I do think though it is important to stop using "encoding". People have to realize that
>>>
>>> - different representations of conceptual data/resources cannot be automatically translated to each other as the term "encoding" might suggest
>>>
>> I do not think that encoding implies that encoding A can be converted
> But, if my memory serves me well, you have always insisted on being able to do the roundtrip conversion between XML and JSON (without using the data model, or in anydata).
>
>> to encoding B nor do I think representation does not imply that
>> representation A can be converted into representation B.
>>
>>> - it is important to think about what representation to use for a given use case (this may influence the choice of protocols and/or tools).
>> The same has always been true before as well.
> At one point, it looked like XML will be the mandatory "encoding" for RESTCONF, despite my fierce opposition, as if it was the the same as requiring everybody to support UTF-8. Fortunately this was eventually overturned.
>
>>> This terminology will also help app folks understand what we are dealing with in NETCONF/NETMOD.
>> I am not against changing terminology but I think we should make sure
>> that there is agreement, ideally in NETMOD and NETCONF, to adopt this
>> new terminology. The worst result would be if documents end up being
>> inconsistent in their terminology for a long period of time. So it is
>> also useful to consider how long the transition to a new terminology
>> is realistically going to be, i.e., how many documents are affected
>> and how much and when it is likely that they can move to a new
>> terminology.
> Yes, "representation" should be one of the terms newly defined in 7950bis, and it can also be mentioned that "encoding" was used informally in the past. As far as I know, "encoding" has never been defined before in this context, so IMO no complicated transition is otherwise needed. And the fact that the term "representation" is used in this sense in related areas can only help.
I'm not sure that I see that 'encoding' as the bad word for 
XML/JSON/CBOR etc.  Possibly 'representation' might be better, but I 
think that saying that something is 'encoded in XML' is likely to be 
well understood.

As I understand it, encoding doesn't just apply to characters, but is 
widely used in other places, such as audio, video, Ethernet (e.g. 64b/66b).

Perhaps, where appropriate, the drafts should differentiate between the 
YANG encoding for a YANG datatree vs the underlying character encoding 
that is being used.

Rob


>
>> In other words, if we make this change, we may consider to have this
>> explicitly mentioned in both charters.
> I don't mind although I don't think it is *that* important.
>
> Lada
>
>> /js
>>
>> -- 
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <http://www.jacobs-university.de/>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>