> On 1 Mar 2017, at 10:46, Juergen Schoenwaelder > <[email protected]> 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. > > 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
