Subject: [netmod] Use of prefixes in YANG models

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 17 Mar 2021 17:03:11 -0700

I have seen the debate on the use of prefixes in YANG models, specially as it relates to their use when importing a model. I think it would nice to be clear on what is required, what is nice, and what is not ok to do. I do not want to confuse this discussion with the length of the prefix, which I believe is somewhat related but not the same discussion.

RFC 7950 says:

   All prefixes, including the prefix for the module itself, MUST be
   unique within the module or submodule.

This is a requirement, as is clear by the MUST.

Then RFC 7950 says:

   To
   improve readability of YANG modules, the prefix defined by a module
   SHOULD be used when the module is imported, unless there is a
   conflict.

It also says:

   When used inside the "import" statement, the "prefix" statement
   defines the prefix to be used when accessing definitions inside the
   imported module.

Clearly, the scope of the “prefix" statement used with an “import” statement is limited to the module where it is imported and does not impact the imported module. As such, and because it is a SHOULD and not a MUST, this is a “nice to have”  without conflicts, but one would not be wrong using a different prefix from the one defined in the imported module. Add to this, most tools, e.g. pyang or yanglint do not complain if you do define a different prefix when there are no conflicts. I have not seen a problem in the implementation of the module when the prefix is different.

RFC 8407 confuses this whole situation by saying:

      The proper module prefix MUST be used for all identifiers imported
      from other modules.

which as written is true for identifiers (but not for other types of imports??). Besides, it does not define what is “proper module prefix". In the absence of a proper definition, one should follow what RFC 7950 says.

Comments?

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 18 Mar 2021 09:05:07 +0100

We often do not do a good job in distinguishing technical requirements
from usage guidelines. (And RFC 2119 keywords make things worse.)

As far as I recall, the intent of the RFC 8407 text was to say that it
is helpful for _humans_ to always use 'if:name' when you refer to the
leaf 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when
you refer to 'date-and-time' defined in 'ietf-yang-types'.

I believe we agreed that module authors assigning a prefix different
from the default prefix during an import should have either technical
reasons for doing so (resolving prefixes clashes) or some other good
reason to depart from the general guideline aiming to reduce human
confusion.

/js (who stopped believing that RFC 2119 keywords are helpful years ago)

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: tom petch <[email-masked]>
Date: Thu, 18 Mar 2021 11:49:52 +0000

From: netmod <[email-masked]> on behalf of Juergen Schoenwaelder <[email-masked]>
Sent: 18 March 2021 08:05

<tp>
To make an abstract concept concrete, draft-ietf-babel-yang-model imports yang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time or yt:counter32.  An early YANG Doctor review by Radek did not comment on this aspect of the I-D.  More recently, I have.

Tom Petch

---

From: Don Fedyk <[email-masked]>
Date: Thu, 18 Mar 2021 17:06:59 +0000

Clarity and consistency would help.

Many of the supporting tool chains are picky about prefixes. IE they must be the same as in the definition file.  I have a case where yanglint wants "local prefixes or derived-from(-or-self) construct" for an local identity in an xpath statement. (either remedy seems to work.) I argued for the prefixes in but others argue they are not necessary but I cannot validate without them. 

"not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works (prefix/no prefix)
But "../../bridge-type != 'dot1q:two-port-mac-relay-bridge'	 works too.

Thanks
Don 

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani <[email-masked]>; Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Use of prefixes in YANG models

We often do not do a good job in distinguishing technical requirements from usage guidelines. (And RFC 2119 keywords make things worse.)

As far as I recall, the intent of the RFC 8407 text was to say that it is helpful for _humans_ to always use 'if:name' when you refer to the leaf 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer to 'date-and-time' defined in 'ietf-yang-types'.

I believe we agreed that module authors assigning a prefix different from the default prefix during an import should have either technical reasons for doing so (resolving prefixes clashes) or some other good reason to depart from the general guideline aiming to reduce human confusion.

<tp>

Tom Petch

On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> Clearly, the scope of the "prefix" statement used with an "import" statement is limited to the module where it is imported and does not impact the imported module. As such, and because it is a SHOULD and not a MUST, this is a "nice to have"  without conflicts, but one would not be wrong using a different prefix from the one defined in the imported module. Add to this, most tools, e.g. pyang or yanglint do not complain if you do define a different prefix when there are no conflicts. I have not seen a problem in the implementation of the module when the prefix is different.
>
> which as written is true for identifiers (but not for other types of imports??). Besides, it does not define what is "proper module prefix". In the absence of a proper definition, one should follow what RFC 7950 says.
>
> Comments?
>
> Mahesh Jethanandani
> [email-masked]
>
>
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Mar 2021 10:22:55 -0700

On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk <[email-masked]> wrote:

> Many of the supporting tool chains are picky about prefixes. IE they must
> be the same as in the definition file.  I have a case where yanglint wants
> "local prefixes or derived-from(-or-self) construct" for an local identity
> in an xpath statement. (either remedy seems to work.) I argued for the
> prefixes in but others argue they are not necessary but I cannot validate
> without them.
>
>

The tool makers should understand that YANG prefixes are not required to be
unique.
It is understood that short character sequences have a high probability of
duplication.
So what if the server wants to support 2 modules with the same prefix
defined in the YANG module?
Is it not clear that the ENTIRE point of having the prefix-stmt in the
import-stmt is
because the imported modules may have prefixes that collide?

Andy

"not(derived-from(../../bridge-type,'two-port-mac-relay-bridge'))" works
> (prefix/no prefix)
> As far as I recall, the intent of the RFC 8407 text was to say that it is
> helpful for _humans_ to always use 'if:name' when you refer to the leaf
> 'name' defined in 'ietf-interfaces' or 'yang:date-and-time' when you refer
> to 'date-and-time' defined in 'ietf-yang-types'.
>
> I believe we agreed that module authors assigning a prefix different from
> the default prefix during an import should have either technical reasons
> for doing so (resolving prefixes clashes) or some other good reason to
> depart from the general guideline aiming to reduce human confusion.
>
> <tp>
> To make an abstract concept concrete, draft-ietf-babel-yang-model imports
> yang types from RFC6991 and gives it the prefix yt: as in yt:date-and-time
> or yt:counter32.  An early YANG Doctor review by Radek did not comment on
> this aspect of the I-D.  More recently, I have.
>
> Tom Petch
>
>
>
> > I have seen the debate on the use of prefixes in YANG models, specially
> as it relates to their use when importing a model. I think it would nice to
> be clear on what is required, what is nice, and what is not ok to do. I do
> not want to confuse this discussion with the length of the prefix, which I
> believe is somewhat related but not the same discussion.
> >
> > RFC 7950 says:
> >
> > Clearly, the scope of the "prefix" statement used with an "import"
> statement is limited to the module where it is imported and does not impact
> the imported module. As such, and because it is a SHOULD and not a MUST,
> this is a "nice to have"  without conflicts, but one would not be wrong
> using a different prefix from the one defined in the imported module. Add
> to this, most tools, e.g. pyang or yanglint do not complain if you do
> define a different prefix when there are no conflicts. I have not seen a
> problem in the implementation of the module when the prefix is different.
> >
> > which as written is true for identifiers (but not for other types of
> imports??). Besides, it does not define what is "proper module prefix". In
> the absence of a proper definition, one should follow what RFC 7950 says.
> >
> > Comments?
> >
> > Mahesh Jethanandani
> > [email-masked]
> >
> >
> >
> >
> >
>

---

From: Don Fedyk <[email-masked]>
Date: Thu, 18 Mar 2021 17:41:41 +0000

So you are saying I should beat up on the tool chain people that have not followed the spec. I tried that already 😊 , but since I can redefine the prefixes locally as a workaround, and I couldn’t convince them it was an issue, it fell by the wayside with one tool so far.

If  the spec was more precise it would settle the arguments.
Regards,
Don

From: Andy Bierman <[email-masked]>
Sent: Thursday, March 18, 2021 1:23 PM
To: Don Fedyk <[email-masked]>
Cc: tom petch <[email-masked]>; Mahesh Jethanandani <[email-masked]>; Juergen Schoenwaelder <[email-masked]>; [email-masked]
Subject: Re: [netmod] Use of prefixes in YANG models

On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk <[email-masked]<mailto:[email-masked]>> wrote:
Clarity and consistency would help.

The tool makers should understand that YANG prefixes are not required to be unique.
It is understood that short character sequences have a high probability of duplication.
So what if the server wants to support 2 modules with the same prefix defined in the YANG module?
Is it not clear that the ENTIRE point of having the prefix-stmt in the import-stmt is
because the imported modules may have prefixes that collide?

Andy

Thanks
Don

-----Original Message-----
From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>; Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] Use of prefixes in YANG models

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>
Sent: 18 March 2021 08:05

<tp>

Tom Petch

On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> [email-masked]<mailto:[email-masked]>
>
>
>
>
>

> [email-masked]<mailto:[email-masked]>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Mar 2021 11:02:20 -0700

On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk <[email-masked]> wrote:

> So you are saying I should beat up on the tool chain people that have not
> followed the spec. I tried that already 😊 , but since I can redefine the
> prefixes locally as a workaround, and I couldn’t convince them it was an
> issue, it fell by the wayside with one tool so far.
>
>
>

I think it is unfortunate that the IETF wanted so many clever little rules
for the creation of YANG modules.
Also unfortunate that RFC 2119 terms in the style guide get confused with
similar terms in the YANG RFC.

RFC 8407 is normative for IETF YANG module authors.
RFC 7950 is for YANG module tool-makers.
People should know the difference, especially since 8407 only applies to
the IETF, not other organizations.

Regards,

Andy

>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* Thursday, March 18, 2021 1:23 PM
> *To:* Don Fedyk <[email-masked]>
> *Cc:* tom petch <[email-masked]>; Mahesh Jethanandani <
> [email-masked]>; Juergen Schoenwaelder <
> [email-masked]>; [email-masked]
> *Subject:* Re: [netmod] Use of prefixes in YANG models
>
>
>
>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 19 Mar 2021 09:59:07 +0100

> Clarity and consistency would help.

Right, but mainly human readers. Properly written tools should have no problems with 

>
> Many of the supporting tool chains are picky about prefixes. IE they
> must be the same as in the definition file.  I have a case where

This is simply wrong, but it is in fact the same problem that plagued XML. James Clark, one of XML gurus, identified the namespace/prefix duality as a serious design flaw in XML. This is an instructive reading:

https://blog.jclark.com/2010/01/xml-namespaces.html

> yanglint wants "local prefixes or derived-from(-or-self) construct"
> for an local identity in an xpath statement. (either remedy seems to
> work.) I argued for the prefixes in but others argue they are not
> necessary but I cannot validate without them.
>

The latter is known to be brittle and shoould not be used. That's why the derived-from function was introduced.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: tom petch <[email-masked]>
Date: Fri, 19 Mar 2021 09:23:06 +0000

From: Andy Bierman <[email-masked]>
Sent: 18 March 2021 18:02

On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk <[email-masked]<mailto:[email-masked]>> wrote:
So you are saying I should beat up on the tool chain people that have not followed the spec. I tried that already 😊 , but since I can redefine the prefixes locally as a workaround, and I couldn’t convince them it was an issue, it fell by the wayside with one tool so far.

I think it is unfortunate that the IETF wanted so many clever little rules for the creation of YANG modules.
Also unfortunate that RFC 2119 terms in the style guide get confused with similar terms in the YANG RFC.

RFC 8407 is normative for IETF YANG module authors.
RFC 7950 is for YANG module tool-makers.
People should know the difference, especially since 8407 only applies to the IETF, not other organizations.

<tp>
Apologies for the useless quoting that my webmail imposes on me:-(

Andy

Of course tool chains should allow for a change of prefix but you did write, in RFC8407,
"   o  The proper module prefix MUST be used for all identifiers imported
      from other modules.
"
and this discussion started with the meaning of 'proper' here.  I take it to mean the prefix defined by the author of the imported module.  I may have a brilliant idea that is a massive improvement on what the author of the imported module chose, but too late.  If this is an RFC, then I can only cause confusion by using a different prefix in my module and that would be improper.

Is this what you intended?

Tom Petch

Regards,
Don

Andy

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 18, 2021 1:23 PM
To: Don Fedyk <[email-masked]<mailto:[email-masked]>>
Cc: tom petch <[email-masked]<mailto:[email-masked]>>; Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>; Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] Use of prefixes in YANG models

Andy

Thanks
Don

-----Original Message-----
From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>; Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] Use of prefixes in YANG models

<tp>

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Mar 2021 11:46:17 +0100

> If  the spec was more precise it would settle the arguments.

RFC 7950 says that tools must support a prefix statement inside an
import statement, which overrides the prefix defined in the imported
module. A tool that does not support this is not implementing RFC 7950
correctly.

RFC 8407 provides additional rules for authors writing IETF YANG
modules. Implementations may generate warnings (perhaps even errors,
may be implementation specific) if these rules are violated by modules
to which the RFC 8407 rules apply. (This implies that a tool needs to
know whether RFC 8407 rules apply or not.)

It is true that RFC 8407 is not very explicit to which YANG modules
the rules apply but given the many IETF specific rules, it is kind of
implicit that the rules may not apply 1:1 to YANG modules published by
other organizations.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Mar 2021 04:55:41 -0700

On Fri, Mar 19, 2021 at 2:23 AM tom petch <[email-masked]> wrote:

> and this discussion started with the meaning of 'proper' here.  I take it
> to mean the prefix defined by the author of the imported module.  I may
> have a brilliant idea that is a massive improvement on what the author of
> the imported module chose, but too late.  If this is an RFC, then I can
> only cause confusion by using a different prefix in my module and that
> would be improper.
>

You mean what the WG intended.
I believe you are correct.

Use the prefix defined in the imported module if it is not already in use
amongst the
local prefixes within the module.  Otherwise pick a different prefix.
(No guidelines for picking a replacement prefix are given)

Andy

> Cc: tom petch <[email-masked]<mailto:[email-masked]>>; Mahesh
> Jethanandani <[email-masked]<mailto:[email-masked]>>;
> Juergen Schoenwaelder <[email-masked]<mailto:
> [email-masked]>>; [email-masked]<mailto:
> [email-masked]>
> To: Mahesh Jethanandani <[email-masked]<mailto:
> [email-masked]>>; Juergen Schoenwaelder <
> [email-masked]<mailto:
> [email-masked]>>
> From: netmod <[email-masked]<mailto:[email-masked]>> on
> behalf of Juergen Schoenwaelder <[email-masked]
> <mailto:[email-masked]>>

---

From: tom petch <[email-masked]>
Date: Fri, 19 Mar 2021 16:38:11 +0000

From: Andy Bierman <[email-masked]>
Sent: 19 March 2021 11:55

On Fri, Mar 19, 2021 at 2:23 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Sent: 18 March 2021 18:02

On Thu, Mar 18, 2021 at 10:41 AM Don Fedyk <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
So you are saying I should beat up on the tool chain people that have not followed the spec. I tried that already 😊 , but since I can redefine the prefixes locally as a workaround, and I couldn’t convince them it was an issue, it fell by the wayside with one tool so far.

<tp>

Andy

Use the prefix defined in the imported module if it is not already in use amongst the
local prefixes within the module.  Otherwise pick a different prefix.
(No guidelines for picking a replacement prefix are given)

<tp>
Andy

Thank you for that; yes, it was the intent of the WG that I was looking for clarification of.

Tom Petch

Tom Petch

Andy

Regards,
Don

Andy

From: Andy Bierman <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Sent: Thursday, March 18, 2021 1:23 PM
To: Don Fedyk <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Cc: tom petch <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; Mahesh Jethanandani <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] Use of prefixes in YANG models

On Thu, Mar 18, 2021 at 10:07 AM Don Fedyk <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
Clarity and consistency would help.

Andy

Thanks
Don

-----Original Message-----
From: netmod <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> On Behalf Of tom petch
Sent: Thursday, March 18, 2021 7:50 AM
To: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] Use of prefixes in YANG models

From: netmod <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> on behalf of Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Sent: 18 March 2021 08:05

<tp>

Tom Petch

On Wed, Mar 17, 2021 at 05:03:11PM -0700, Mahesh Jethanandani wrote:
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>
>
>
>
>

> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Mar 2021 18:54:09 +0100

> Apologies for the useless quoting that my webmail imposes on me:-(

Your webmail does not allow to edit the quoted text?

/js

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 19 Mar 2021 10:30:27 -1000

> On Mar 19, 2021, at 12:46 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I believe support by tools for the additional rules imposed by RFC 8407 would be helpful. There are several ways to recognize that the module in question is an IETF module, e.g. namespace, or by a more direct option on the tool CLI, e.g. —ietf option in pyang. The tools can print a warning if the prefix of the imported module is not used.

> implicit that the rules may not apply 1:1 to YANG modules published by

Additionally, RFC 8407 is a BCP. It does not update RFC 7950. However, it is changing the prefix requirement for import in RFC 7950, from a SHOULD to a MUST. Aren’t languages supposed to be consistent in how its rules are meant to be interpreted?

Mahesh Jethanandani
[email-masked]

---

From: tom petch <[email-masked]>
Date: Sat, 20 Mar 2021 11:49:09 +0000

From: Juergen Schoenwaelder <[email-masked]>
Sent: 19 March 2021 17:54

It has no replace function so I would have to insert a > character in front of every line by hand.  And, often, the original e-mail as displayed has a series of coloured lines down the left hand side which give some indication as to what the level of quoting is.  When composing a reply, those lines have vanished so I would have to go back to the original e-mail to see what the level of quoting is for any one paragraph and then insert the appropriate number of > characters  for each line of each paragraph.  Life is too short to iron tea towels (as a famous person once said)!

Tom Petch

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 20 Mar 2021 13:15:03 +0100

> It has no replace function so I would have to insert a > character in front of every line by hand.  And, often, the original e-mail as displayed has a series of coloured lines down the left hand si…

I do not know what forces you to use this webclient but there is
always a readers vs. writers or who pays the price aspect. I do
occasionally press 'delete' on emails requiring extra time or special
tools to identify the contribution (and given that I am of the dying
species reading emails in plain text, I accept that the world is
moving on and I am just stuck in the 20th century).

/js

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 20 Mar 2021 13:19:25 +0100

> moving on and I am just stuck in the 20th century).

+1.
Further to that, let me point out that getting emails that were mishandled like this makes many readers think the sender suffers of a serious disregard for their readers.  That may not be the signal that you want to send to a large professional community of peers.

Grüße, Carsten