タグ

rfcに関するtarchanのブックマーク (35)

  • RFC日本語訳一覧

    RFC文書を自動翻訳したページ一覧 翻訳の正確性は保証しません。必ず英文と比較してお読みください。 稀に原文の一部が抜けるので、右上の原文へのリンク「Orig」から原文も読むようにしてください。 図や表が複数ページにわたるときや、間に空行が含まれるときは、上手に解釈できないことがあります。 翻訳物に関してはRFCの著作権の関係で RFC 2220 以降のみを公開しています。 RFCを翻訳するツール群は github.com/tex2e/rfc-translater に置いてあります。

    tarchan
    tarchan 2023/04/08
  • RFC 9401: The Addition of the Death (DTH) Flag to TCP

    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

  • RFC 7540「Hypertext Transfer Protocol Version 2(HTTP/2)」がリリースされる | スラド IT

    HTTP/2 は Google の SPDY がもとになるなど、RFC制定にもGoogleが関わっている、Googleの陰謀ともいえる規格です。実は、HTTP/2 の 広告ブロックが困難というか事実上不可能になるというデメリット(Googleにとっては最大限のメリットであることから)が隠されています。Google は 表向きはユーザのプライバシーを理由に TLS 化を推進していますが、裏に広告ブロックを妨害したいという陰謀が隠れていると思います。 まず、Microsoft が反対したこともあって RFC では TLS は必須とはなりませんでしたが、Chrome と Firefox(Firefox の最大のスポンサーは残念なことに Google です)の実装においては TLS 必須のため、事実上 HTTP/2 では TLS が必須ですから、プロキシやVPNAndroid における広告ブロッ

  • HTTP/2、IETFの標準化プロセスが完了しRFCに。16年ぶりにHTTPがバージョンアップ

    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

    HTTP/2、IETFの標準化プロセスが完了しRFCに。16年ぶりにHTTPがバージョンアップ
  • HTTP/1.1、公開から15年の時を経て改訂 | スラド IT

    「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

  • Pecinta Drama

    Your are seeing this error because the page you attempted to access was not found. If you think that's an error please inform the website owner.

    Pecinta Drama
  • 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を - 若くない何かの悩み

    メールアドレスのルールのまとめ系のサイトの内容が間違っています。 なので、この類のまとめは安易に信じないように 、という注意喚起をしておきます。 追記(2013/11/27) twitterやはてブをみていたところ、「ユーザーへの啓蒙という観点ではまとめの内容間違ってない」というご意見をたくさんいただきましたので、補足をしておきますね。 どうも「ルール」と「トラブルを避けるためのガイドライン」が混同されているように思います。まとめで紹介されている内容がユーザ向けの「ガイドライン」なのであれば、「+ 記号使わせてよ」ぐらいしか文句はありません。 ですが、ほとんどのまとめは上記の内容を「ルール」として説明しています。ひどいものにはRFCに基づいてまとめを書いたようにミスリードさせる記事もありました。このような現状を憂い、このような記事を書いたのです。 そもそもこれに気づいた発端は@kusano

  • 「メールアドレスのルール」なんて使ってはいけない3つの理由 - めもおきば

    定期的に繰り返される話題ですがまた盛り上がっているのできちんと書いておきます。 「通るべきメールアドレスが弾かれると激おこ」という前提で話を進めます。 問題点1. メールアドレスに関して、RFCなんてそもそも守られていない 2009年以前に登録されたDoCoMo携帯のメールアドレスなど、quoted-stringじゃないのにピリオド連続するものが実在している以上、彼らを許容するべきです。 今そこにある実装 >>(越えられない壁)>> RFC です。 問題点2. メールアドレスの国際化 @の左側(addr-spec)でUTF-8を利用できるようにするRFC5335が発行されています。これにより、通すべき文字が一気に増えます。 RFC5335 Internationalized Email Headers JPRSが国際化電子メールアドレスの標準化活動に貢献 / 株式会社日レジストリサービス

    「メールアドレスのルール」なんて使ってはいけない3つの理由 - めもおきば
    tarchan
    tarchan 2013/11/28
    >メールアドレスの確認はそこにメールを送る事で確認を行いましょう。/通るべきメールアドレスが弾かれると激おこ
  • 電子メールあれこれ

    ここに掲載するニュースレターは山和彦がIIJの社内誌、およびインターネット・マガジンに執筆した文章です。IIJ 社内誌の編集者、IIJ の広報、およびインターネット・マガジンの許可を得て、若干加筆訂正した形でここに転載します。 メールと日語 ヘッダあれこれ MIMEの基礎 間違いだらけのメールリーダ 暗号メールと電子署名 ASCII

  • HTTP Cookies

    このウェブサイトは販売用です! studyinghttp.net は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、studyinghttp.netが全てとなります。あなたがお探しの内容が見つかることを願っています!

  • Comma-Separated Values - Wikipedia

    comma-separated values(略称:CSV)は、テキストデータをいくつかのフィールド(項目)に分け、区切り文字であるカンマ「,」で区切ったデータ形式。拡張子は .csv、MIMEタイプは text/csv。 「comma-separated variables」とも言う。日語では広く普及した訳語はないが、「カンマ区切り」「コンマ区切り」などとも呼ばれる。Microsoft Excelの日語版では「CSV (カンマ区切り)」としている。 概要[編集] データ交換用のデファクトスタンダードとして、古くから多くの表計算ソフトやデータベースソフトで使われている。CSV形式の細部の実装はソフトウェアによって異なるため(例えば項目を単一引用符「'」や二重引用符「"」で括ったり、ファイルの一行目をヘッダとして予約したりなど)、他のソフトウェアで表(テーブル)として読み込む際に互換性で

  • IETF、今年のApril Fools' Day RFCは TCPパケットの「気持ち」を記載するオプションを提案

    CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

    IETF、今年のApril Fools' Day RFCは TCPパケットの「気持ち」を記載するオプションを提案
  • MozillaZine.jp フォーラム • トピック - [解決済み] 「全員に返信」でメールアドレスが消える場合がある

    Aさんから自分とBさん、Cさんに宛てたメールを受信し、「全員に返信」をします。 当然、Aさん、Bさん、Cさん宛てににメールが作成されます。 このとき、Cさんのアドレス登録(プロパティ)をたとえば「三田さん(もじら組)」とかにしていて、しかも、このカッコの前が半角、後ろが全角になっている場合、このCさんのメールアドレスは消えてしまい、送信してもエラーで帰ってきてしまいます。(送信せずに「保存」でも確かめることができます) 通常「三田さん(もじら組)<○○○@×××.com>」となるところが、「三田さん(もじら組)」だけになってしまいアドレス部分が消えます。 これは何度でも再現します。 両方全角だと大丈夫なようです。前と後ろが逆の場合は試していません。 私だけの現象でしょうか? この「カッコの前が半角、後ろが全角」というのは、普通に書いていてよく起こりうるパターンなので、ちょっとイヤです。 環

  • Windows Live メールでドコモ・auに送信できない。 : パソコントラブル出張修理・サポート日記

    こちらはWindows7への買い替えのお客様。 セットアップ自体は問題なく完了しましたが、問題はメール設定の完了後に起こった。 一通りのセットアップが完了してから、メールソフトがWindowsLiveメールに変わりましたので…と説明をしていたら、 「じゃ、とりあえずここに送ってみて」 と渡された、ドコモ携帯のメールアドレス。 …うーむ、こ、コレは…。なんかイヤ~な予感が…。 (コレに関しては後述) ま、まぁ、とりあえずコレで送信してみましょう。 メールの新規作成画面から、渡されたメールアドレスを入力してみたら。 (こちらはVista環境での再現画面です) メッセージを送信できませんでした。 受信者の中に、電子メールアドレスが指定されていないユーザーが存在します。すべての受信者の電子メールアドレスがアドレス帳に入力されていることを確認してください。…∑( ̄△ ̄; な、なんだとぅ~? ----

  • OSXでRFC2822をフォーマットする « ku

    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

    tarchan
    tarchan 2009/11/20
    ロケールに影響されない
  • syslog - Wikipedia

    syslog(シスログ)は、ログメッセージをIPネットワーク上で転送するための標準規格である。"syslog" という用語は、その通信プロトコルを指すだけでなく、syslog メッセージを送信するシステム(アプリケーションやライブラリ)syslog メッセージを受信し報告・分析するシステムに対しても使われる。syslogの各メッセージには、そのメッセージを生成したシステムの種類を示すファシリティコードが付与され、重大度が設定される。 システム管理やセキュリティ監査の目的だけでなく、一般的な情報提供、分析、デバッグ用にも用いられる。多くのプラットフォームで、プリンタ、ルータ、メッセージレシーバなど、様々なデバイスがsyslog規格を使用している。これにより、異なるタイプのシステムからのログデータを1つの集中リポジトリで一括して管理することができる。syslogの実装は、多くのオペレーティング

  • 原稿・資料 ― ありえるえりあ

    アスキー NETWORK MAGAZINE原稿 アスキー NETWORK MAGAZINE 2005年3月号(http://nmag.jp/modules/xfsection/article.php?articleid=3)の「いま改めて知っておきたいこれからのP2P」の原稿です。 Read More…

  • Extensible Messaging and Presence Protocol - Wikipedia

    Extensible Messaging and Presence Protocol (XMPP) (旧称 Jabber[1])は、オープンソースのインスタントメッセンジャーのプロトコルおよび、クライアント、サーバの総称である。 特徴[編集] Jabber は Jabber 社が開発した XML ベースのプロトコルである XMPP を採用している。他のメジャーなインスタントメッセンジャーはその仕様もプロトコルも非公開となっているのが普通だが、Jabber はサーバもクライアントもオープンソースであり、その仕様は全て公開されている(オープン標準)。そのため、たとえばメールサーバと同じように、ドメイン名とサーバさえあれば自分専用の XMPP サーバを立ち上げることができる。この点でほかのインスタントメッセージと異なる。 他のインスタントメッセージングサービスのゲートウェイとなる機能も持つ。この

    Extensible Messaging and Presence Protocol - Wikipedia
  • http://www.softfront.co.jp/tech/ietfdoc/trans/rfc3265j.txt

  • CSVのあれやこれや - うなの日記

    CSVの仕様書(RFC4180)を読んだので、ずっと疑問だったことについて、ちょろっとまとめてみます。 ヘッダーの有無の判定 CSVにはヘッダーが付いている場合がある訳ですが、形式がデータ行と同じなので、文字列だけ見ても判断が付きません。これについて仕様書によると、MIME Typeのパラメータで判定しましょうとのこと。具体的には、以下のようになります ヘッダーがある場合 text/csv; charset=utf-8; header=present ヘッダーがない場合 text/csv; charset=utf-8; header=absent ちなみに、文字コードもMIME Typeパラメータで判定するという話になっています。 「"」のエスケープ カラム内で「,」や改行を使用する場合、カラム全体を「"」で囲みます(エスケープ)。さらにエスケープされたカラム内で「"」を使いたい場合、「"

    CSVのあれやこれや - うなの日記