4. Examples

   The examples below use theoretical services that contain Enumservices
   which might not make sense, but that are still used for educational
   purposes.  For example, the protocol used is in some cases exactly
   the same string as the URI scheme.  That was the specification in RFC
   2916(-> 3761prop), but this 'default' specification of an Enumservice is no longer
   allowed.  All Enumservices need to be registered explicitly by the
   procedure specified in section Section 3.

4.1. Example

   $ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
      NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
      NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
      NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .

   This describes that the domain 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa. is
   preferably contacted by SIP, secondly via H.323 for voice, and
   thirdly by SMTP for messaging.  Note that the tokens "sip", "h323",
   and "msg" are Types registered with IANA, and they have no implicit
   connection with the protocols or URI schemes with the same names.

   In all cases, the next step in the resolution process is to use the
   resolution mechanism for each of the protocols, (specified by the URI
   schemes sip, h323 and mailto) to know what node to contact for each.