Standardizing JSON
Update 4/2/2013: in an email to the IETF JSON mailing list, Barry Leiba (Applications Area director in IETF) noted that discussions had started with ECMA and ECMA TC 39 to reach agreement on where JSON will be standardized, before continuing with the chartering of an IETF working group. JSON (JavaScript Object Notation) is a text representation for data interchange. It is derived from the JavaScri
RFC 6919: Further Key Words for Use in RFCs to Indicate Requirement Levels
Independent Submission R. Barnes Request for Comments: 6919 S. Kent Category: Experimental BBN ISSN: 2070-1721 E. Rescorla RTFM, Inc. 1 April 2013 Further Key Words for Use in RFCs to Indicate Requirement Levels Abstract RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced
RFC 5789: PATCH Method for HTTP
Internet Engineering Task Force (IETF) L. Dusseault Request for Comments: 5789 Linden Lab Category: Standards Track J. Snell ISSN: 2070-1721 March 2010 PATCH Method for HTTP Abstract Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal
Principles of the Same-Origin Policy
Principles of the Same-Origin Policy draft-abarth-principles-of-origin-00 Abstract The security model of the web platform has evolved over time to meet the needs of new applications and to correct earlier mistakes. Although web security has evolved largely organically, the security model has converged towards a handful of key concepts. This document presents those concepts and provides advice to d
RFC 822 と RFC 2822 - あどけない話
Email Security Conference 2007 で、ある講演である人が、こんなことを言っていました。 メールのプロトコルである RFC 822 は Standard ですが、改訂版の RFC 2822 は Proposed Standard です。つまり、格下げされたんです。このころからも、メールよりも web の方がセキュアだということは明らかです。 僕はプログラム委員という立場なので、スポンサーの人のこういう間違った発言を正すと角が立つと思い、その場では黙っていました。技術を分っていないことは明らかだったので、放っておこうと思う気持ちもありました。 しかし、よく考えると IETF の標準化プロセスは、IETF 外の人にとって分りにくいのではないかと思い直しました。そこで、IETF に関わりのある人たちと議論して、どう伝えるべきか分ってきましたので、この記事を書いておきます
IETFにおける標準化プロセス - JPNIC
Internet-Draft、RFC Internet-Draftは、各個人が自由に投稿することができ、6か月間、 IETFのFTPサーバおよびWebサーバに置かれる。 Internet-Draftは、 6ヶ月でArchive から消えていくWorking-in-Progressのドキュメントである。 各個人および各Working Groupは、Internet-Draftが、 広くインターネット業界に有用な情報を含んでいると判断すると、 これを、RFC(あるいはBCP, Best Current Practice)にするようIESGに申請する。 申請が承認されると、 ドキュメントにはRFC番号(あるいはBCP番号)が割り当てられ、 公式にIETFのFTPおよび Webサーバを通じて恒常的に参照可能なドキュメントとなる。 なお、RFCには、4種類のドキュメント種別が存在していおり、 情報の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Deprecating the "X-" Prefix and Similar Constructs in Application Protocols
W3C TPAC, Lyon
http://www.net.intap.or.jp/INTAP/information/journal/62.pdf