1

私はびっくりしました

ドメイン example.comのJMAPサポート電子メール ホストは、ホスト名とポート (通常はポート 443) を指定する SRV レコード _jmaps._tcp.example.com を発行する必要があります。

認証 URL はhttps://hostname/.well-known/jmapです(リダイレクト後)。

SRV ルックアップを使用できないクライアントをサポートするために、autoconfig.example.com または autodiscover.example.com を使用する他の自動検出オプションが JMAP の将来のバージョンに追加される可能性があります。

これは、既知の URI レジストリの元のユース ケースとは一致しません。robots.txt やdnt/などdnt-policy.txt。また、IPP / CUPS 印刷は、DNS TXT レコードを使用して URL を指定しなくても正常に機能します。SRV レコードを検索できる場合は、TXT も同様に検索できます。また、自動検出プロトコルには、明らかに完全な URI を含めることができる XML が含まれます。

たとえば、よく知られている URI のレジストリによってこれが受け入れられる可能性はありますか? それとも、作り上げられた URI スキームのように、非標準的なものとして残る可能性が高いですか?

4

1 に答える 1

0

このアイデアはほぼ間違いなく、既知の URI のレジストリに既に登録されている CalDav から生まれました。RFC 6532では、DNS SRV と、DNS TXT および既知の URI の両方が定義されています。したがって、JMAP の提案は完全に根拠のあるものです。

URL が認証されるというのは奇妙に聞こえるかもしれませんが、CalDav ではこれも正当化されます。複数のサーバー間でユーザーを分割するのに役立つと思います。

IMO SRV を使用するのは良い方法ではありません。一方、JMAP では、SRV を使用しないクライアントを具体的に検討しています。CalDav の使用も同様の理由によるものと推測されます。

おそらく Web 中心の実装が完全な URI を発見できないのは奇妙に思えます (つまり、自動構成プロトコルを使用している場合)。

これらのアプローチは、ユーザーのメール アドレスから始まることを覚えておく必要があると思います。すべてに HTTP URI を使用する神聖な Web アーキテクチャ... まあ、URI については何も言う必要はないとしましょうmailto:。DNS は、ドメインから URI へのギャップを埋める「正しい」方法でなければなりません。しかし、DNS を解決する方法や、HTTP と通信するための IP を検索する方法しか知らない Web 中心の世界では? 多少の妥協はあるでしょう。

于 2016-03-24T14:38:35.493 に答える