RFC 7386: JSON Merge Patch
Internet Engineering Task Force (IETF) P. Hoffman Request for Comments: 7386 VPN Consortium Category: Standards Track J. Snell ISSN: 2070-1721 October 2014 JSON Merge Patch Abstract This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target r
メールアドレスの正規表現
更新日 2019/5/3 戻る Perlメモへ - メールアドレスの正規表現へ Perl正規表現雑技へ 更新履歴 2019/05/03 「制御文字を除去する」「参考文献」RFC5321日本語訳のリンク修正 2009/08/13 $atextのバグ修正 2009/05/06 「正規表現を簡略化する」追記 2009/04/29 「旧形式を削除する」追記 2009/04/13 「IPアドレスを除去する」追記 目次 RFCに準拠したメールアドレスの正規表現 コメントと空白文字を除去する 制御文字を除去する IPアドレスを除去する 旧形式を除去する 正規表現を簡略化する 参考文献 RFCに準拠したメールアドレスの正規表現 メールアドレスについては RFC 5322 に addr-spec として書かれています． 下記は RFC 5322 に従って導き出した正規表現です． 14,277バイトあります．
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様
今日では HTTP(s) で API が公開されることは当たり前の時代ですが、エラーをアプリケーションにどう伝えるかは、個々の API の設計に依存していました。特に、HTTP ステータスコードは有限であり、元々持っている意味があるので、自由に使うことはできません。API はそのドメインごとにもっと複雑で細かなエラー情報があるはずで、それらはレスポンスボディに載せてアプリケーションに伝えることになりますが、その書式に規定は今までありませんでした。 HTTP API にて、アプリケーションにエラー情報を伝達するための（レスポンスボディに載せられる）標準的な形式が、RFC7807 Problem Details for HTTP APIs で定められています。適用例としては、以下のようになります。 HTTP/1.1 403 Forbidden Content-Type: application
RFCの正規文書がXMLに:Geekなぺーじ
インターネットに関連するプロトコルなどを規定するRFC(Request For Comments)の正規文書のフォーマットが、これまでのplain-text ASCIIからXMLへと変わります。そのためのRFCが、RFC 7990 - RFC 7998として策定されました。 RFC 7990 RFC Format Framework RFC 7991 The "xml2rfc" Version 3 Vocabulary RFC 7992 HTML Format for RFCs RFC 7993 Cascading Style Sheets (CSS) Requirements for RFCs RFC 7994 Requirements for Plain-Text RFCs RFC 7995 PDF Format for RFCs RFC 7996 SVG Drawings for R
RFC 6238: TOTP: Time-Based One-Time Password Algorithm
Internet Engineering Task Force (IETF) D. M'Raihi Request for Comments: 6238 Verisign, Inc. Category: Informational S. Machani ISSN: 2070-1721 Diversinet Corp. M. Pei Symantec J. Rydell Portwise, Inc. May 2011 TOTP: Time-Based One-Time Password Algorithm Abstract This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm,
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
メールアドレスのバリデーション崩壊のお知らせ、もしくは、全てが UTF-8 になる, 「エンジニアのためのイベント映像活用方法」の第2回が gihyo.jp に掲載されました - 雑文発散(2013-01-24)
▼ [雑] メールアドレスのバリデーション崩壊のお知らせ、もしくは、全てが UTF-8 になる JANOG31 のページをつらつら見てたら気になるセッションがあった。 「メールアドレスの国際化(JANOG25からの変更点)」というものだ。（多用されているかはともかく）Web で使われるドメイン名では国際化が進んでいたけど、メールアドレスに関してはほとんど進んでいなかった印象だったのに、どうも RFC での標準化がほぼ完了したらしい。 セッションページからダウンロードできる「IETF 85 報告 DNS, 国際化関連」という資料を見てみたら、次のような記述があった。 ほとんどすべてのメールヘッダにUTF-8を許可 – メールアドレス部 <ローカルパート@ドメイン名> – Display-name, (コメント), SubjectヘッダにもUTF-8 (従来はMIME) 資料には具体例も記載さ
LocationヘッダのURIにフラグメント識別子はNG - maru.cc@はてな
Location時にフラグメント識別子を付けられるのか？ d:id:maru_cc:20080207:1202385497 こちらがRFC的にどうなっているのか調べてみた。 確信は持てないがおそらく、RFC的にNGということでいいのかな？ まず、#XXXと書くのの正式名称がわからなかったので調査。 http://www.7key.jp/rfc/2396/rfc2396_4.html#li28 4.1. Fragment Identifier URI参照が識別されたリソースの取得動作を行う際、URIを"#"で区切ることによってフラグメント識別子を任意で付けることができる。フラグメント識別子は、リソースの取得動作が成功した後にユーザエージェントが解釈する付加的な参照情報である。このため、フラグメント識別子はURIではないが、 URIと共に用いられることが少なくない。 フラグメント識別子と言うら
一般的なサービス、役割、機能に対するメールボックス名(RFC2142) - JPNIC
RFC2142-JP.txt 2000/09/27 (initial version) (C)JPNIC RFC-JP project, 2000. All rights reserved. Network Working Group D. Crocker Request for Comments: 2142 Internet Mail Consortium Category: Standards Track May 1997 一般的なサービス、役割、機能に対するメールボックス名 本文書の位置づけ 本文書では、インターネットコミュニティに対するインターネット標準化過 程プロトコルを定義し、改良のための議論と提案を求めている。標準化の状 態と本プロトコルの状態については"Internet Official Protocol Standards" (STD 1)の最新版を参照してほしい。本文書
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Deeper look at RFC7159 the JSON
GitHub - nst/JSONTestSuite: A comprehensive test suite for RFC 8259 compliant JSON parsers
Loading...
RFC3029 Etymology of "Foo" 「foo」の語源
http://www-vacia.media.is.tohoku.ac.jp/member/o/s-yamane2004/articles/crypto/rfc2804-jp-yamane.html