RFC文書を自動翻訳したページ一覧 翻訳の正確性は保証しません。必ず英文と比較してお読みください。 稀に原文の一部が抜けるので、右上の原文へのリンク「Orig」から原文も読むようにしてください。 図や表が複数ページにわたるときや、間に空行が含まれるときは、上手に解釈できないことがあります。 翻訳物に関してはRFCの著作権の関係で RFC 2220 以降のみを公開しています。 RFCを翻訳するツール群は github.com/tex2e/rfc-translater に置いてあります。
Stream: Independent Submission RFC: 9401 Category: Informational Published: 1 April 2023 ISSN: 2070-1721 Author: RFC 9401 The Addition of the Death (DTH) Flag to TCP Abstract This memo specifies the incorporation of Death (DTH) flag to TCP, including DTH's use of one bit in the TCP header. The flag is designed to make TCP session narratives smooth and attractive.¶ Status of This Memo This document
HTTP/2 は Google の SPDY がもとになるなど、RFC制定にもGoogleが関わっている、Googleの陰謀ともいえる規格です。実は、HTTP/2 の 広告ブロックが困難というか事実上不可能になるというデメリット(Googleにとっては最大限のメリットであることから)が隠されています。Google は 表向きはユーザのプライバシーを理由に TLS 化を推進していますが、裏に広告ブロックを妨害したいという陰謀が隠れていると思います。 まず、Microsoft が反対したこともあって RFC では TLS は必須とはなりませんでしたが、Chrome と Firefox(Firefox の最大のスポンサーは残念なことに Google です)の実装においては TLS 必須のため、事実上 HTTP/2 では TLS が必須ですから、プロキシやVPN(Android における広告ブロッ
16年ぶりとなるHTTPの新しいバージョン、HTTP/2の標準化プロセスが2月18日付けで完了し、RFCとなりました。 IETFのブログでの報告。 HTTP/2 Approved | IETF Blog IETF HTTP Working Groupのチェア、Mark Nottingham氏のブログでの報告。 mnot’s blog: HTTP/2 is Done HTTP/2は昨年、2014年8月にHTTPbisワーキンググループのラストコールとなり、12月にIETFのステアリンググループであるIESGがRFCのための最終検討に入っていました。 HTTP/2は、現在広く使われているHTTP/1.1と互換性を保ちつつ、通信による遅延をできるだけ小さくし、ネットワーク帯域を効率的に使うために非同期で通信を多重化することなどによって、より高速な通信を実現することを目指したものです。 もともとG
「1つだったRFCは6つに分割され」とあったのは、2616をUpdateした https://tools.ietf.org/html/rfc7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing https://tools.ietf.org/html/rfc7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content https://tools.ietf.org/html/rfc7232 Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests https://tools.ietf.org/html/rfc7233 Hypertext Transfer Protocol
メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記(2013/11/27) twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano
定期的に繰り返される話題ですがまた盛り上がっているのできちんと書いておきます。 「通るべきメールアドレスが弾かれると激おこ」という前提で話を進めます。 問題点1. メールアドレスに関して、RFCなんてそもそも守られていない 2009年以前に登録されたDoCoMo携帯のメールアドレスなど、quoted-stringじゃないのにピリオド連続するものが実在している以上、彼らを許容するべきです。 今そこにある実装 >>(越えられない壁)>> RFC です。 問題点2. メールアドレスの国際化 @の左側(addr-spec)でUTF-8を利用できるようにするRFC5335が発行されています。これにより、通すべき文字が一気に増えます。 RFC5335 Internationalized Email Headers JPRSが国際化電子メールアドレスの標準化活動に貢献 / 株式会社日本レジストリサービス
comma-separated values(略称:CSV)は、テキストデータをいくつかのフィールド(項目)に分け、区切り文字であるカンマ「,」で区切ったデータ形式。拡張子は .csv、MIMEタイプは text/csv。 「comma-separated variables」とも言う。日本語では広く普及した訳語はないが、「カンマ区切り」「コンマ区切り」などとも呼ばれる。Microsoft Excelの日本語版では「CSV (カンマ区切り)」としている。 概要[編集] データ交換用のデファクトスタンダードとして、古くから多くの表計算ソフトやデータベースソフトで使われている。CSV形式の細部の実装はソフトウェアによって異なるため(例えば項目を単一引用符「'」や二重引用符「"」で括ったり、ファイルの一行目をヘッダとして予約したりなど)、他のソフトウェアで表(テーブル)として読み込む際に互換性で
Aさんから自分とBさん、Cさんに宛てたメールを受信し、「全員に返信」をします。 当然、Aさん、Bさん、Cさん宛てににメールが作成されます。 このとき、Cさんのアドレス登録(プロパティ)をたとえば「三田さん(もじら組)」とかにしていて、しかも、このカッコの前が半角、後ろが全角になっている場合、このCさんのメールアドレスは消えてしまい、送信してもエラーで帰ってきてしまいます。(送信せずに「保存」でも確かめることができます) 通常「三田さん(もじら組)<○○○@×××.com>」となるところが、「三田さん(もじら組)」だけになってしまいアドレス部分が消えます。 これは何度でも再現します。 両方全角だと大丈夫なようです。前と後ろが逆の場合は試していません。 私だけの現象でしょうか? この「カッコの前が半角、後ろが全角」というのは、普通に書いていてよく起こりうるパターンなので、ちょっとイヤです。 環
こちらはWindows7への買い替えのお客様。 セットアップ自体は問題なく完了しましたが、問題はメール設定の完了後に起こった。 一通りのセットアップが完了してから、メールソフトがWindowsLiveメールに変わりましたので…と説明をしていたら、 「じゃ、とりあえずここに送ってみて」 と渡された、ドコモ携帯のメールアドレス。 …うーむ、こ、コレは…。なんかイヤ~な予感が…。 (コレに関しては後述) ま、まぁ、とりあえずコレで送信してみましょう。 メールの新規作成画面から、渡されたメールアドレスを入力してみたら。 (こちらはVista環境での再現画面です) メッセージを送信できませんでした。 受信者の中に、電子メールアドレスが指定されていないユーザーが存在します。すべての受信者の電子メールアドレスがアドレス帳に入力されていることを確認してください。…∑( ̄△ ̄; な、なんだとぅ~? ----
HTTPの日付文字列はあまり使われていないRFC2822になっている。探すとNSDateFormatterを使ったコードがけっこう出てくるけどこのクラスはちゃんと設定されているロケールに応じた日付文字列を返すのでシステムが日本語に設定してあると曜日が日本語で出力されてRFC2822にならない。書いた方が早い。 NSString* rfc2822StringFromDate(const NSDate* date) { time_t t; struct tm tm; time_t epoch = (time_t)[[NSDate date] timeIntervalSince1970]; time(&epoch); gmtime_r(&epoch, &tm); static const char* month_names[] = { "Jan", "Feb", "Mar", "Apr", "M
syslog(シスログ)は、ログメッセージをIPネットワーク上で転送するための標準規格である。"syslog" という用語は、その通信プロトコルを指すだけでなく、syslog メッセージを送信するシステム(アプリケーションやライブラリ)syslog メッセージを受信し報告・分析するシステムに対しても使われる。syslogの各メッセージには、そのメッセージを生成したシステムの種類を示すファシリティコードが付与され、重大度が設定される。 システム管理やセキュリティ監査の目的だけでなく、一般的な情報提供、分析、デバッグ用にも用いられる。多くのプラットフォームで、プリンタ、ルータ、メッセージレシーバなど、様々なデバイスがsyslog規格を使用している。これにより、異なるタイプのシステムからのログデータを1つの集中リポジトリで一括して管理することができる。syslogの実装は、多くのオペレーティング
Extensible Messaging and Presence Protocol (XMPP) (旧称 Jabber[1])は、オープンソースのインスタントメッセンジャーのプロトコルおよび、クライアント、サーバの総称である。 特徴[編集] Jabber は Jabber 社が開発した XML ベースのプロトコルである XMPP を採用している。他のメジャーなインスタントメッセンジャーはその仕様もプロトコルも非公開となっているのが普通だが、Jabber はサーバもクライアントもオープンソースであり、その仕様は全て公開されている(オープン標準)。そのため、たとえばメールサーバと同じように、ドメイン名とサーバさえあれば自分専用の XMPP サーバを立ち上げることができる。この点でほかのインスタントメッセージと異なる。 他のインスタントメッセージングサービスのゲートウェイとなる機能も持つ。この
CSVの仕様書(RFC4180)を読んだので、ずっと疑問だったことについて、ちょろっとまとめてみます。 ヘッダーの有無の判定 CSVにはヘッダーが付いている場合がある訳ですが、形式がデータ行と同じなので、文字列だけ見ても判断が付きません。これについて仕様書によると、MIME Typeのパラメータで判定しましょうとのこと。具体的には、以下のようになります ヘッダーがある場合 text/csv; charset=utf-8; header=present ヘッダーがない場合 text/csv; charset=utf-8; header=absent ちなみに、文字コードもMIME Typeパラメータで判定するという話になっています。 「"」のエスケープ カラム内で「,」や改行を使用する場合、カラム全体を「"」で囲みます(エスケープ)。さらにエスケープされたカラム内で「"」を使いたい場合、「"
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く