Hi Lada,
On 01/03/2017 10:45, Ladislav Lhotka wrote:
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.
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: +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
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
