> On 1 Mar 2017, at 11:53, t.petch <[email protected]> wrote: > > ----- Original Message ----- > From: "Juergen Schoenwaelder" <[email protected]> > Sent: Wednesday, March 01, 2017 9:46 AM > >> 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 >> to encoding B nor do I think representation does not imply that >> representation A can be converted into representation B. > > I agree. > > I think that the real difference is between those working with networks > and those operating at a higher level. Just because the terminology is > suitable for HTTP, URI and such like does not make it appropriate for > network configuration.
The resource/representation concepts come (I think) from Roy Fielding's dissertation where it is explicitly mentioned that they are not specific to HTTP. Also, in my view, NETCONF/RESTCONF is a higher level than HTTP. Lada > > I would stay with encoding. > > Tom Petch > >>> - 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. >> >>> 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. >> >> In other words, if we make this change, we may consider to have this >> explicitly mentioned in both charters. >> >> /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/> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
