アカウント名:
パスワード:
原理主義的には「間違っているのは使っちゃダメ」なのかも知れないが、有る物は有るんだから仕方ない。適当にユーザーが慣れてから、新規メールアドレスに制限を入れて…って10年じゃ変更は出来ないと見た。
過去に何回も話題に出ているけど、RFC上、@の前をダブルクォーテーションで囲えば連続ドットでも送れるんだから、メールアドレスの変更をする必要はない。http://srad.jp/it/comments.pl?sid=421870&cid=1434447 [srad.jp]
これぐらいのことは、携帯キャリアが責任を持って変換すればいいんじゃないの?
>悪いのはdomcomo側>それでdomcomoのためにそうなのか。
GMailや他のメールクライアントを落として来れば使えるってのだから、htcのプリインストールしているあのメールクライアントがクオートしていないとかじゃなかろうか。
foo..bar@example.com と "foo..bar"@example.com を同一視しないワナもあるかも。
"foo..bar"@example.comを扱えないシステムも結構あるんだよなぁ。それはそれで問題だけど。
RFC違反のメアドを使ってるユーザーがメールを受信できないとか送信できないだけなら放置すればいいけど、他に迷惑かかるからやめて欲しいわ。
メールアドレスを登録するサービスで、RFC違反のアドレスが登録できずエラーになったら、文句言われるのはサービス側なんだぜ?こういうアドレス使ってる連中って理由を説明しても逆切れするだけだし。(それがあるからキャリアも今までの非を認めたがらないんでしょうけど)登録フォームのチェック要件を緩和するだけで済めばいいが、システムそのものを変えないといけない場合は誰がそのコスト持ってくれるんだ?
対応を行うのは携帯電話会社ではなく、すべての MUA の作成元ですね。あと、API 提供元。
携帯電話会社の gateway で変換ではそこまでたどり着くまでに MTA を経由することがあるので対応としてはダメです。
RFC5321 [ietf.org] では Quoted-string 形式は認められているわけで、Dot-string では許可されていない連続する "." や "( ) [ ] : ; @ ," が含まれた場合、自動的に Quoted-string に変換すればいいと思いますけど。
さすがにその変換をやらなければダメとは RFC532 には書かれてませんけどね。
変換も何もクライアントが弾いていたらそもそも受け取れないんでは?特定のクライアントで起こるってアナウンスなんだから、キャリア側は対応されていると思われます。
全くだ。猶予期間1ヶ月で根絶させろ。何十年やっとるんじゃボケ。死ね。
告知打つだけでいいから手間も費用も最小じゃないの?できない理由がさっぱりわからない。
システム作る人間がどれだけ苦労するか判ってねえな。そのコストをドコモやKDDIが持ってくれる訳でもないくせに。
そんな変則的なドットのアドレスが重要か?
そのシステムを作る人の食い扶持を持って来る顧客からの苦情が来るから、困るんだと思うが。
言ってしまえばそういう意見は「ユーザーの金でユーザーの利便性を奪い取れ」って事に成るので、世の中で広く営業している人は原理原則だけでは動けないんですよ。狭い社会や自前の金でなら、誰も苦労しないとは思いますが。
その程度の仕事でずっと食えているのなら、楽なもんだともいえるわな。
現在取得・変更する際はRFC準拠のものを求められるので、新たに〜というのは、文句付けていいものだとおもいますけどね。問題になるのは過去そういうのが考慮されていなかったときのアドレス(もしくは仕様)。
# みんながみんな、ここに来る人たちみたいに# 「そっかー標準仕様に違反してるなら変更しないといけないよねー」と考えるわけではないので。
いますよね、できない理由を探すスペシャリスト。
営業にしたら、できない理由を探して顧客の無理な要求を断ってくれるスペシャリストにならないかな?
この場合の一番の問題は、「現状顧客は何も要望していない」って事だよ?つまり、形的には「キャリア側が自社の理由でユーザーに被害を与える」事そのものになる。
一方的に迷惑を蒙れば大抵の人は怒るし、それを見た人も当然と思うのは仕方ない。
RFC準拠なんての学校でも教えない様に、一般常識でも何でもない上、今まで問題なくつかっていたのを「アンタが悪い」って言うのは難しい。特にお金を貰っていて自分でそれをもともと提供していて言うのなら、「アンタ自分の事を棚に上げて何様のつもり?」と言われても仕方ないだろう。
身内に近い方に贔屓目が過ぎる奴らが多すぎ。上流の職になるほど顧客の利便要望を考慮する必要が有るんで、考えるくらいはした方が良いと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
今有る物は使える様にするしかないのじゃ? (スコア:0)
原理主義的には「間違っているのは使っちゃダメ」なのかも知れないが、有る物は有るんだから仕方ない。
適当にユーザーが慣れてから、新規メールアドレスに制限を入れて…って10年じゃ変更は出来ないと見た。
Re:今有る物は使える様にするしかないのじゃ? (スコア:1)
…あれ?大丈夫な気がしないよ…?
Re:ダブルクォーテーション (スコア:1, 参考になる)
過去に何回も話題に出ているけど、RFC上、@の前をダブルクォーテーションで囲えば連続ドットでも送れるんだから、メールアドレスの変更をする必要はない。
http://srad.jp/it/comments.pl?sid=421870&cid=1434447 [srad.jp]
これぐらいのことは、携帯キャリアが責任を持って変換すればいいんじゃないの?
Re:ダブルクォーテーション (スコア:1, 興味深い)
Re: (スコア:0)
>悪いのはdomcomo側
>それでdomcomoのために
そうなのか。
Re: (スコア:0)
GMailや他のメールクライアントを落として来れば使えるってのだから、htcのプリインストールしているあのメールクライアントがクオートしていないとかじゃなかろうか。
Re: (スコア:0)
foo..bar@example.com と "foo..bar"@example.com を同一視しないワナもあるかも。
Re: (スコア:0)
"foo..bar"@example.comを扱えないシステムも結構あるんだよなぁ。
それはそれで問題だけど。
RFC違反のメアドを使ってるユーザーがメールを受信できないとか送信できないだけなら放置すればいいけど、
他に迷惑かかるからやめて欲しいわ。
メールアドレスを登録するサービスで、RFC違反のアドレスが登録できずエラーになったら、
文句言われるのはサービス側なんだぜ?
こういうアドレス使ってる連中って理由を説明しても逆切れするだけだし。
(それがあるからキャリアも今までの非を認めたがらないんでしょうけど)
登録フォームのチェック要件を緩和するだけで済めばいいが、システムそのものを変えないといけない場合は誰がそのコスト持ってくれるんだ?
Re:ダブルクォーテーション (スコア:1)
対応を行うのは携帯電話会社ではなく、すべての MUA の作成元ですね。あと、API 提供元。
携帯電話会社の gateway で変換ではそこまでたどり着くまでに MTA を経由することがあるので対応としてはダメです。
RFC5321 [ietf.org] では Quoted-string 形式は認められているわけで、Dot-string では許可されていない連続する "." や "( ) [ ] : ; @ ," が含まれた場合、自動的に Quoted-string に変換すればいいと思いますけど。
さすがにその変換をやらなければダメとは RFC532 には書かれてませんけどね。
Re: (スコア:0)
変換も何もクライアントが弾いていたらそもそも受け取れないんでは?
特定のクライアントで起こるってアナウンスなんだから、キャリア側は対応されていると思われます。
Re: (スコア:0)
Re: (スコア:0, 荒らし)
全くだ。猶予期間1ヶ月で根絶させろ。
何十年やっとるんじゃボケ。死ね。
告知打つだけでいいから手間も費用も最小じゃないの?
できない理由がさっぱりわからない。
Re: (スコア:0)
システム作る人間がどれだけ苦労するか判ってねえな。
そのコストをドコモやKDDIが持ってくれる訳でもないくせに。
そんな変則的なドットのアドレスが重要か?
Re: (スコア:0)
そのシステムを作る人の食い扶持を持って来る顧客からの苦情が来るから、困るんだと思うが。
言ってしまえばそういう意見は
「ユーザーの金でユーザーの利便性を奪い取れ」
って事に成るので、世の中で広く営業している人は原理原則だけでは動けないんですよ。
狭い社会や自前の金でなら、誰も苦労しないとは思いますが。
Re: (スコア:0)
Re: (スコア:0)
その程度の仕事でずっと食えているのなら、楽なもんだともいえるわな。
Re: (スコア:0)
現在取得・変更する際はRFC準拠のものを求められるので、
新たに〜というのは、文句付けていいものだとおもいますけどね。
問題になるのは過去そういうのが考慮されていなかったときのアドレス(もしくは仕様)。
# みんながみんな、ここに来る人たちみたいに
# 「そっかー標準仕様に違反してるなら変更しないといけないよねー」と考えるわけではないので。
Re: (スコア:0)
いますよね、できない理由を探すスペシャリスト。
Re:今有る物は使える様にするしかないのじゃ? (スコア:1)
営業にしたら、できない理由を探して顧客の無理な要求を
断ってくれるスペシャリストにならないかな?
-- う~ん、バッドノウハウ?
Re: (スコア:0)
この場合の一番の問題は、「現状顧客は何も要望していない」って事だよ?
つまり、形的には「キャリア側が自社の理由でユーザーに被害を与える」事そのものになる。
一方的に迷惑を蒙れば大抵の人は怒るし、それを見た人も当然と思うのは仕方ない。
RFC準拠なんての学校でも教えない様に、一般常識でも何でもない上、今まで問題なく
つかっていたのを「アンタが悪い」って言うのは難しい。
特にお金を貰っていて自分でそれをもともと提供していて言うのなら、
「アンタ自分の事を棚に上げて何様のつもり?」
と言われても仕方ないだろう。
身内に近い方に贔屓目が過ぎる奴らが多すぎ。
上流の職になるほど顧客の利便要望を考慮する必要が有るんで、
考えるくらいはした方が良いと思う。
Re: (スコア:0)