refs

気を付けていること

ブローカーはプロトコル説明部分では使わない。
- 基本はクライアントとサーバ（仕様に合わせて）
- ただし慣例的にMQTTの説明で使われているので実装や実例の紹介のようなところではブローカーとした方が良いように思っている。
- 編集を続けていて出典から知ったけれども、MQTTv3.1以前は仕様書上もブローカーだったのですね。
アプリケーションメッセージの送信は「配布」「転送」としている。
パケットの送受信は「送信」「受信」としている。
パケットの名前は大文字オンリー（仕様に合わせて）
メッセージとパケットを混同しないようにする。
- 特にパケットをメッセージと書く
- メッセージ：MQTTより上位のデータ
- パケット：MQTTの制御で使うプロトコルメッセージ
いちおうパケットタイプとパケットを使い分けているがあまり細かい基準はない。
- 概念的なものを説明するときはパケットタイプ
- 具体的なもの（フォーマットや実際に送信するデータの説明など）を説明するときはパケット

MQTT#セキュリティの課題は投稿してから単にレポートを列記するのではなく内容をまとめて記載したほうが良いと思った。

Portal:鉄道/加筆依頼にMQTT#IECC_ScalableのDeltaRailについて加筆修正依頼中

残りの追記できそうなトピック

名前ネタ。
- https://groups.google.com/g/mqtt/c/F0JlXXiUA_M
- https://f.hubspotusercontent00.net/hubfs/6941105/Que%20es%20MQTT%20-%20IBM%20podcast%20-%20Piper,%20Diaz,%20Nipper%20-%2011182011-1.pdf
なぜMQTTが注目され始めたか
サーバのMQTTv5対応はだいぶ進んだが、クライアント側は実はまだほとんどMQTTv3.1.1じゃないのか。
- 独自研究レベルの経験上の実感
- どこかトラフィック分析の結果とか公表してくれないかな。
Facebookが使っていることの出典
- どこかで見つけたのにURLを紛失してしまった。

時雨堂やOPTiMの中の人が書いているみたいに、有名ライブラリやバイナリでも結構適当な実装が多いです。Reservedに正しくないデータが設定されているときにエラー扱いしないといけないのですが、大抵のライブラリやブローカーは正常処理します。
MQTTv2の仕様文章って残っていたんですね。HiveMQの記事はいつも機械翻訳のモノを読んでいたので気づかなかった。
参考文献のオリジナルは英語Blogだけれども、公式に日本語Blogもある場合の参考文献の付け方。
- 日本語版なのだから日本語Blogで良いと思うし実際にそうした。
- → MQTT#セキュリティの課題のトレンドマイクロのレポート
- ただ、情報の正確性やより深く知りたいときの出典として英語Blogへの参照も付けたいと個人的（技術者的）には思うけれどもそういうテンプレートはあるのだろうか。
- 単純な翻訳じゃなくて日本語Blog独自の記述があるのですよね…〇月×日△△が書いた～と言う記事紹介程度の追加だけど。
- IBMやMicrosoftのドキュメントみたいに日本語ページが機械翻訳なら英語ページで迷わないんだけども。