On Sun, Apr 14, 2024 at 10:21:33PM +0200, Oliver Hartkopp wrote: > > > On 14.04.24 06:03, Vincent Mailhol wrote: > > > > > This doesn't remove the fact that I think that this naming convention > > is stupid because of the RAS syndrome, but I acknowledge that CAN CC > > is now the official denomination and thus, that we should adopt it in > > our documentation as well. > > > > ;-) > > I honestly did not knwow the new CAN in Automation naming scheme. Will keep the CAN-CC here. Thanks! > > > > Add a space between ISO and the number. Also, update the year: > > > > > > > > ISO 15765-2:2024 > > > > > > > > > > Interesting! Didn't know there's already a new version. > > > > > > Will check this out whether we really support ISO 15765-2:2024 ... > > > > > > Do you have the standard at hand right now or should we leave this as > > > ISO15765-2:2016 until we know? > > > > I have access to the newer revisions. But I never really invested time > > into reading that standard (neither the 2016 nor the 2024 versions). > > > > Regardless, here is a verbatim extract from the Foreworld section of > > ISO 15765-2:2024 > > > > This fourth edition cancels and replaces the third edition (ISO > > 15765-2:2016), which has been technically revised. > > > > The main changes are as follows: > > > > - restructured the document to achieve compatibility with OSI > > 7-layers model; > > > > - introduced T_Data abstract service primitive interface to > > achieve compatibility with ISO 14229-2; > > > > - moved all transport layer protocol-related information to Clause 9; > > > > - clarification and editorial corrections > > > > Yes, I've checked the release notes on the ISO website too. > This really looks like editorial stuff that has nothing to do with the data > protocol and its segmentation. > The :2016 suffix is cited both here and inside the Kconfig. We can: - keep the :2016 here and then update both the documentation and the Kconfig once the standard has been checked - move to :2024 both here and inside the Kconfig - drop the :2016 from everywhere (leaving only ISO 15765) and move to ISO 15765:2024 only inside the "Specifications used" paragraph What do you think? Shall the modifications to the Kconfig be done as part of this series? Best regards, Francesco Valla
