SML は Service Metadata Locator の略であり、
受信者の Participant Identifier から、どの SMP を参照すべきかを見つける探索レイヤである。
Peppol では DNS を用いた名前解決により、受信者に対応する SMP の場所を導く。

要するに、SML は「どこを見に行けばよいか」を決める仕組みである。

SMP は Service Metadata Publishing の略であり、
SML で見つけた先で、その受信者がどの文書をどのプロファイルで受け取れるかを公開する。
典型的には次のような情報がある。

Peppol の基本的な探索は、次の二段階である。

SML/SMP は、四隅モデルにおいて「最終受信者に届く受信APを見つける」には非常に強い。
しかし、これは基本的に「受信者に対応する受信側メタデータを見つける」仕組みであり、
複数の異種EDIネットワークをまたぐ多段中継や、
複数候補の中からどの経路を選ぶかという問題そのものを解く仕組みではない。

したがって、SML/SMP は重要だが、
ネットワーク・オブ・ネットワークス型の相互接続にはそれだけでは足りない。

共通EDIや業界EDIでは、各プロバイダがそれぞれ利用者登録簿を持っていることが多い。
しかし、それだけでは送信者は次のことを判断できない。

つまり必要なのは、各社の名簿の寄せ集めではなく、
それらを束ねて参照できる共通の上位ディレクトリである。

上位ディレクトリは、少なくとも次の三つを支える必要がある。

ここでいう到達可能性とは、単なる住所録ではない。
「この事業者へは、どのネットワークから、どのGWを経由して、どの文書が届けられるか」
という route 情報まで含む。

異種EDI間では、直接到達できないことがある。
その場合は、ネットワーク間をつなぐ中継GWや変換サービスが必要になる。

たとえば、次のようなケースがあり得る。

このとき必要なのは、単なる登録簿ではなく、
「どのネットワークからどのネットワークへ、どの条件で到達できるか」を示す経路広告である。

本稿でいう Web3 は、暗号資産や投機の話ではない。
主に次の技術群を指す。

DID は分散的に管理できる識別子であり、
DID Document には公開鍵、認証方式、service、serviceEndpoint などを記述できる。

この serviceEndpoint は、
「この主体について詳細情報を知りたければ、どこを見ればよいか」を示す入口として使える。
したがって、SML 的な探索結果や SMP 的なメタデータの入口に向いている。

VC は、ある主体が別の主体について行う主張を、検証可能な形で表す仕組みである。
たとえば、次のようなことを主張できる。

これにより、上位ディレクトリは単なる名簿ではなく、
「誰がその情報を保証しているか」を伴った信頼付きディレクトリになる。

ENS のような分散名前解決は、入口だけを分散基盤に置き、
実際の詳細メタデータはオフチェーンに置く設計ができる。

これは EDI のように、
更新頻度が高く、運用情報の秘匿性も必要な世界では重要である。
すべてをオンチェーンに載せる必要はない。

上位ディレクトリが持つべき情報は、単なる事業者一覧ではない。
少なくとも、次の三種類の情報が必要である。

これは通信ネットワークの BGP 的な発想に似ているが、EDI では単純な到達性だけでは足りない。
EDI の route advertisement には、少なくとも次の条件が絡む。

したがって、これは単なる最短経路問題ではなく、
ポリシー付き経路選択問題である。

Web3 は、経路情報の登録や真正性検証には向いている。
しかし、実際の経路選択は変動要因が多い。

これらを逐次オンチェーン管理するのは、
更新コスト、秘匿性、運用柔軟性の点で不利である。

現実的には、次の分担がよい。

つまり、Web3 は「信頼付きの経路候補の台帳」であり、
経路選択エンジンはその中から実行時に最適候補を選ぶ。

経路選択エンジンは、少なくとも次の観点を見る必要がある。

実務に向くのは、次の三層構造である。

この層では、事業者ID、プロバイダID、ネットワークIDを DID やその参照に対応付ける。
ENS や DID Resolver により、
「この主体について、どのメタデータを見ればよいか」を解決する。

これは SML の Web3 版に相当する。

この層では、VC や署名付きメタデータを使い、
次のような到達可能性情報を公開する。

これは SMP を拡張した、
「到達可能性と信頼の広告層」と捉えられる。

この層では、現在の障害状況、契約、料金、優先順位、変換可否を見て、
複数候補から最終経路を決める。
配送自体は、AS4、HTTPS API、その他の既存メッセージング方式を使えばよい。

つまり、配送方式そのものを Web3 にする必要はない。
Web3 は、その前段の discovery と trust に集中させる方がよい。

この構成により、次のことが実現できる。

一方、これだけでは自動的に決まらないものもある。

これらは技術だけではなく、運用ガバナンスの問題である。