DoCoMoの説明にある「RFCに準拠しています」はウソ
RFCに準拠というのは言葉が悪いとは思うが・・・
まぁ、元NTTだからDoCoMoをかばうわけではなくく
プログラマとしてRFCに向かう姿勢だけを言えば
NTT関連企業 時代にこの逆をやられたことがある。
とあるRFCで、繋がらないので、メーカにクレーム入れたら。そのメーカー関係者にRFC作者がいてRFCではそこまで考慮して書かなかっただけ。RFCのバグなので修正するよって。RFCが修正されたことがある。
実際問題、RFCは想定してあることについて書かれているだけで、想定範囲外のことについては、やってはいけないのではなく、規定されていないだけ。
したがって、SHOULD NOTと書かれていない場合で、他ベンダーがやってきた場合、入力は可能な限り受け入れて、出力はRFC通りの法則に基づいて受け入れるように修正される事が多い。
RFCではダメと決めた事はSHOULD NOTと書くのが決まりで。書かれていない場合は、想定外。想定もれな場合もあり得る。
実際、いくつかの問題では、想定していなかったとRFC作者に言われて、各ベンダーさんの意見募集を経て、できることになったりする場合もあるしね。
結局、RFCで類推できるレベルだとひっくり返ることがあるので、SHOULD NOTと書かれていなければ、BNFを読んでできないと見えても（RFC作者の書き間違い。想定もれの可能性があり）、作る側としてはグレーゾーンなので、送らないが受け取れるように考えて作っておかないといけない。
一番やっかいなのはBNFなどの文法は参考だから絶対じゃない（とRFC作者に言われた経験からすれば）。人間だからバグもあるよ。SHOULD NOTと書かれていない場合はBNFの書き方を間違えている場合もあるから、作者にメールしてね。というRFCの柔軟な（場合もある）規定を、既存の通信業者が、絶対の物だと考えすぎている点だと思う。
もっとも、上記の通り、やられたほうがたまったものじゃなく、システムの修正になったりするわけだが・・・
まぁ、RFCって、結構修正されたりして変わるからね。プログラマとしては信じすぎちゃダメダよという事。
つか、送るときとか、メールアドレスとかは.＠とかa..a@はヤッチャダメだとは思うが・・・
でもこれはレガシー対応
すでにそういうダメシステムが有る以上、受け入れるしかないのが世の常というのが、どうにもこうにも、システム屋の辛いところ。
関連 BNFについては、一般的に
RFC2396でのＵＲＩ規定なども含めて、昨今のRFCのBNFの一般論ではシステム的に問題がない場合は、通るように修正されるのが一般的でしょうか？
URＩ関連では＠の前は.許容ですし。
昔はヘッダ : パラメータ だったのが ヘッダ *LWSP":" *LWSPあたりが通常の解釈だし・・・
まだＲＦＣになってない、業界でのお約束とかもあるし（ｗ
結構通信関係はめんどい。というのが感想
RFCに準拠というのは言葉が悪いとは思うが・・・
まぁ、元NTTだからDoCoMoをかばうわけではなくく
プログラマとしてRFCに向かう姿勢だけを言えば
NTT関連企業 時代にこの逆をやられたことがある。
とあるRFCで、繋がらないので、メーカにクレーム入れたら。そのメーカー関係者にRFC作者がいてRFCではそこまで考慮して書かなかっただけ。RFCのバグなので修正するよって。RFCが修正されたことがある。
実際問題、RFCは想定してあることについて書かれているだけで、想定範囲外のことについては、やってはいけないのではなく、規定されていないだけ。
したがって、SHOULD NOTと書かれていない場合で、他ベンダーがやってきた場合、入力は可能な限り受け入れて、出力はRFC通りの法則に基づいて受け入れるように修正される事が多い。
RFCではダメと決めた事はSHOULD NOTと書くのが決まりで。書かれていない場合は、想定外。想定もれな場合もあり得る。
実際、いくつかの問題では、想定していなかったとRFC作者に言われて、各ベンダーさんの意見募集を経て、できることになったりする場合もあるしね。
結局、RFCで類推できるレベルだとひっくり返ることがあるので、SHOULD NOTと書かれていなければ、BNFを読んでできないと見えても（RFC作者の書き間違い。想定もれの可能性があり）、作る側としてはグレーゾーンなので、送らないが受け取れるように考えて作っておかないといけない。
一番やっかいなのはBNFなどの文法は参考だから絶対じゃない（とRFC作者に言われた経験からすれば）。人間だからバグもあるよ。SHOULD NOTと書かれていない場合はBNFの書き方を間違えている場合もあるから、作者にメールしてね。というRFCの柔軟な（場合もある）規定を、既存の通信業者が、絶対の物だと考えすぎている点だと思う。
もっとも、上記の通り、やられたほうがたまったものじゃなく、システムの修正になったりするわけだが・・・
まぁ、RFCって、結構修正されたりして変わるからね。プログラマとしては信じすぎちゃダメダよという事。
つか、送るときとか、メールアドレスとかは.＠とかa..a@はヤッチャダメだとは思うが・・・
でもこれはレガシー対応
すでにそういうダメシステムが有る以上、受け入れるしかないのが世の常というのが、どうにもこうにも、システム屋の辛いところ。
関連 BNFについては、一般的に
RFC2396でのＵＲＩ規定なども含めて、昨今のRFCのBNFの一般論ではシステム的に問題がない場合は、通るように修正されるのが一般的でしょうか？
URＩ関連では＠の前は.許容ですし。
昔はヘッダ : パラメータ だったのが ヘッダ *LWSP":" *LWSPあたりが通常の解釈だし・・・
まだＲＦＣになってない、業界でのお約束とかもあるし（ｗ
結構通信関係はめんどい。というのが感想
