From discuss-bounces@apps.ietf.org Mon Jul 03 10:08:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxP5k-0001EF-DE; Mon, 03 Jul 2006 10:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw5Tb-00085D-2W for discuss@apps.ietf.org; Thu, 29 Jun 2006 18:59:11 -0400 Received: from mailhost.auckland.ac.nz ([130.216.190.13] helo=harpo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw5TY-0001m7-MO for discuss@apps.ietf.org; Thu, 29 Jun 2006 18:59:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 53F8B34E0F; Fri, 30 Jun 2006 10:59:07 +1200 (NZST) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28613-01; Fri, 30 Jun 2006 10:59:07 +1200 (NZST) Received: from [130.216.208.135] (bioeng135.bioeng.auckland.ac.nz [130.216.208.135]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 58092345BD; Fri, 30 Jun 2006 10:59:05 +1200 (NZST) Message-ID: <44A45B39.3030908@auckland.ac.nz> Date: Fri, 30 Jun 2006 10:59:05 +1200 From: Andrew Miller User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: ietf@ietf.org, iesg@ietf.org, ietf-types@iana.org, xml-dir@ietf.org, discuss@apps.ietf.org, cellml-discussion@cellml.org, lisa@osafoundation.org Subject: Revised draft of Last Call document (draft-miller-media-type-cellml) Content-Type: multipart/mixed; boundary="------------040907000206050102050604" X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.0 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 X-Mailman-Approved-At: Mon, 03 Jul 2006 10:07:57 -0400 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This is a multi-part message in MIME format. --------------040907000206050102050604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Please find attached a revised draft of the CellML Media type registration, which is in Last Call for Informational status until 19th of July 2006. The draft has been submitted to the IETF secretariat, but will not appear until on or after Monday, Jule 10 at 9:00 AM ET, due to the upcoming IETF meeting. The revised draft differs from the previous one in the following respects: 1) It fixes a few minor ID nits: a) Minor formatting changes such as fixing a 73 character line, b) Changes a "recommended" to "RECOMMENDED", and a may to "can" to avoid confusion with MAY. 2) The draft now explicitly states that utf-8 is the only acceptable character set. This has always been in the CellML Umbrella Format, but now it is in the draft as well, for clarity. 3) The Abstract is no longer redundant with the Introduction, and the Discussion section has been merged into the Introduction. 4) An ambiguous use of the word "registry" (between the IANA types registry and the CellML Umbrella Format registry) has been fixed. Please CC any comments regarding this draft to ak.miller@auckland.ac.nz Best regards, Andrew Miller --------------040907000206050102050604 Content-Type: text/plain; name="draft-miller-media-type-cellml-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-miller-media-type-cellml-04.txt" Internet Draft draft-miller-media-type-cellml-04.txt Intended Status: Network Working Group A. K. Miller Request for Comments: nnnn The University of Auckland Informational May 2006 CellML Media Type Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document standardises a new media type -- application/cellml+xml -- for use in exchanging mathematical models represented in a CellML Umbrella 1.0 compliant markup language. Miller Informational [Page 1] RFCnnnn CellML Media Type 24 May 2006 1. Introduction CellML Umbrella format is a standardised markup meta-language for the interchange of mathematical models. CellML Umbrella Format provides a common base which is supported by a number of specific formats used in the interchange of mathematical models. CellML Umbrella Format provides enough information to determine which specific language is used to express the model. The syntax and semantics of the CellML Umbrella format are defined by [CELLML-UMBRELLA]. CellML Umbrella format is an actual media format. Although CellML Umbrella documents contain elements in namespaces defined by other specifications such as [RDF] and [MATHML], the information in these namespaces do not contain sufficient information to define a mathematical model, and so CellML provides the information required to interconnect the different CellML components, as well as the information required to link CellML components to their metadata. As such, CellML Umbrella documents are more than just a collection of entities defined elsewhere, and so a new media type is required to identify CellML. As all well-formed CellML Umbrella documents are also well-formed XML documents, the convention described in Section 7 of [RFC3023] has been observed by use of the +xml suffix. The information in CellML Umbrella documents cannot be interpreted without understanding the semantics of the XML elements used to mark up the model structure. Therefore, the application top-level type is used instead of the text top-level type. 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms "element" and "document element" in this document are to be interpreted as in [XML]. The term "XML namespace" is to be interpreted as in [NAMESPACES]. 3. Media Type Registration for CellML Umbrella MIME media type name: application MIME subtype name: cellml+xml Mandatory parameters: none Optional parameters: charset The charset parameter of application/cellml+xml is handled in Miller Informational [Page 2] RFCnnnn CellML Media Type 24 May 2006 the same fashion as for application/xml, as specified in Section 3.2 of [RFC3023]. However, per conformance rule 4 of [CELLML-UMBRELLA], valid CellML Umbrella documents MUST be in the UTF-8 character set. If the charset parameter is present it MUST take the value "utf-8". CellML processing software SHOULD check the charset field, and if it is present but not equal to "utf-8", MAY attempt to recover from the error by processing the document in the specified character set. Encoding considerations: As per Section 3.2 of [RFC3023]. Security considerations: As per Section 5 of this document. Interoperability considerations: As per Section 4.1 of this document. Published specification: CellML Umbrella Specification[CELLML-UMBRELLA]. Applications which use this media type: As per Section 4.2 of this document. Additional information: Magic number(s): None. XML processing software can identify CellML Umbrella documents as XML documents which contain a document element with local name "model". File extension(s): The RECOMMENDED file extension for CellML Umbrella documents is .cellml Some older software uses the file extension .xml. Software vendors have also used the non-standard extension .cml. In contexts where the MIME type is available, or where the type has already been determined as CellML, implementations SHOULD allow files to be opened regardless of the extension. Implementations transferring models to an environment which uses file extensions SHOULD use the .cellml extension. Macintosh File Type Code(s): "TEXT" Person & email address to contact for further information: See the Author's Address section of this document. Intended usage: COMMON Author/Change controller: The CellML Umbrella 1.0 specification was authored by Andrew Miller. The CellML Umbrella 1.0 specification itself will not change. Miller Informational [Page 3] RFCnnnn CellML Media Type 24 May 2006 However, the umbrella specification defines the process for new specific formats to be registered. The Bioengineering Institute at The University of Auckland, with input from the CellML Community via the cellml-discussion@cellml.org mailing list, has control over the CellML Umbrella Format Registry. 4. Interoperability and usage 4.1. Interoperability Considerations The interoperability considerations in Section 3.1 of [RFC3023] also apply to CellML Umbrella documents. CellML Umbrella documents contain XML elements defined by each specific format, all of which are published specifications. In addition to the ability to parse XML, user agents require software support for the semantics of [RDF] and/or part or all of a specific format. As efforts are made to keep the number of specific formats small, user agents SHOULD implement all specific formats listed in the CellML Umbrella Format Registry at the time they were developed. 4.2. Applications which use CellML Umbrella Format CellML Umbrella is device-, platform-, and vendor-neutral and is supported by a wide range of CellML processing tools, including those designed to validate, edit, and/or visualise CellML models, extract MathML or RDF, translate to or from other related specifications, evaluate mathematics and ordinary differential equations, fit parameters to models, and serve, archive and annotate models. 5. Security Considerations As CellML Umbrella is an XML based markup language, all the security considerations presented in section 10 of [RFC3023] also apply to CellML Umbrella. Some types of CellML Umbrella documents can refer to other Uniform Resource Locators (URLs) in a number of places: i) References to XML document type definitions or schemas. ii) References to other models using the import features of some specific formats. iii) References to other documents embedded in user-defined data. Some types of CellML processing software may then automatically attempt to access the URL and retrieve the document. This retrieval could have several consequences, specifically, i) if a CellML document is transferred via e-mail, the fact that the recipient has opened the CellML document could be disclosed to the sender without the recipient's knowledge or consent. Miller Informational [Page 4] RFCnnnn CellML Media Type 24 May 2006 ii) where the recipient of a document transfers the document to another location using the MIME type defined in this document, the original author of the document may be notified of the second address by the attempted retrieval of further documents. iii) by performing requests on the recipient's behalf, the CellML processing software may cause actions to be performed with privileges granted to the recipient, without the recipient's knowledge or consent. CellML processing software can mitigate this threat when running in an environment where it is a concern by requiring explicit confirmation from the user before attempting to load any external documents. 6. IANA Considerations This document specifies a new media type. IANA will add this media type to the media types registry as specified in [RFC4288]. 7. References 7.1. Normative References [CELLML-UMBRELLA] Miller, A.K., "CellML Umbrella Specification 1.0", 20 April 2006, [NAMESPACES] Bray, T., et. al., "Namespaces in XML 1.1", 4 February 2004, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997 [RFC3023] Murata, M., Simon, S.L., Kohn, D., "XML Media Types", RFC 3023, January 2001 [XML] Bray, T., et. al., "Extensible Markup Language (XML) 1.0 (Third Edition)", 4 February 2004, 7.2. Informative References [MATHML] Ion, P. and Miner, R.(editors) "Mathematical Markup Language (MathML) 1.01 Specification", 7 July 1999, [RDF] Beckett, D.(editor) "RDF/XML Syntax Specification (Revised)", 10 February 2004, Miller Informational [Page 5] RFCnnnn CellML Media Type 24 May 2006 [RFC4288] Freed, N. and Klensin, J.C., "Media Type Specifications and Registration Procedures", RFC 4288, BCP 13, December 2005 Author's Address Andrew Miller The Bioengineering Institute at The University of Auckland Level 6, 70 Symonds St Auckland Central Auckland E-mail: ak.miller@auckland.ac.nz Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Miller Informational [Page 6] --------------040907000206050102050604-- From discuss-bounces@apps.ietf.org Mon Jul 10 09:23:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzvj1-0001Il-U9; Mon, 10 Jul 2006 09:22:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzvj1-0001Ig-Fi for discuss@apps.ietf.org; Mon, 10 Jul 2006 09:22:59 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fzviz-0003ys-2b for discuss@apps.ietf.org; Mon, 10 Jul 2006 09:22:59 -0400 Received: from [132.219.12.252] (unknown [132.219.12.252]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1E77014229F for ; Mon, 10 Jul 2006 06:22:56 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) To: discuss@apps.ietf.org Message-Id: Content-Type: multipart/alternative; boundary=Apple-Mail-8-284391638 References: <44B252FF.1090204@oracle.com> From: Lisa Dusseault Subject: Fwd: Il Focolaio Pizza Resto Date: Mon, 10 Jul 2006 09:22:47 -0400 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-8-284391638 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Location for Eric's Review Team Bar BoF Lisa Begin forwarded message: > From: Bernard Desruisseaux > Date: July 10, 2006 9:15:43 AM GMT-04:00 > To: Lisa Dusseault > Subject: Il Focolaio Pizza Resto > > http://english.montrealplus.ca/portal/profile.do?profileID=490912 > > Il Focolaio Pizza Resto > > 1223, rue du Square-Phillips > Montreal, QC H3B 3E9 > Phone: (514) 879-1045 --Apple-Mail-8-284391638 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Location for Eric's Review Team = Bar BoF

Lisa

Begin = forwarded message:

From: = Bernard Desruisseaux <bernard.desruisseaux@oracl= e.com>
Date: July 10, 2006 9:15:43 AM = GMT-04:00
To: Lisa Dusseault <lisa@osafoundation.org>
Subject: Il Focolaio Pizza = Resto

=

Il Focolaio Pizza Resto

1223, rue du = Square-Phillips
Montreal, QC H3B 3E9
Phone: =A0 (514) 879-1045
=

= --Apple-Mail-8-284391638-- From discuss-bounces@apps.ietf.org Wed Jul 12 13:50:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iqy-0007qd-76; Wed, 12 Jul 2006 13:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0iqx-0007qY-LU for discuss@apps.ietf.org; Wed, 12 Jul 2006 13:50:27 -0400 Received: from mxout-04.mxes.net ([205.237.194.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0iqv-00021P-Dw for discuss@apps.ietf.org; Wed, 12 Jul 2006 13:50:27 -0400 Received: from [127.0.0.1] (unknown [216.145.54.158]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 31404A3297 for ; Wed, 12 Jul 2006 13:50:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) References: <60C48030-123C-496C-9F94-A7E0BF964089@mnot.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E51B704-A3E9-4212-9BC5-DCD016DF0081@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Fwd: Reminder: HTTP Bar BoF Date: Wed, 12 Jul 2006 13:50:24 -0400 To: discuss@apps.ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org If you're interested in HTTP, we're holding a Bar/Restaurant BoF tonight. Begin forwarded message: > Resent-From: ietf-http-wg@w3.org > From: Mark Nottingham > Date: 12 July 2006 11:51:02 AM > To: HTTP Working Group > Subject: Reminder: HTTP Bar BoF > X-Archived-At: http://www.w3.org/mid/60C48030-123C-496C-9F94- > A7E0BF964089@mnot.net > > > We'll be meeting tonight in room 518C after the plenary; 8pm at the > latest. > > After a *short* discussion, we'll go for dinner nearby; location TBD. -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Thu Jul 13 13:18:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14pE-0006vX-97; Thu, 13 Jul 2006 13:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14pD-0006vS-91 for discuss@apps.ietf.org; Thu, 13 Jul 2006 13:18:07 -0400 Received: from mxout-04.mxes.net ([205.237.194.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14pB-00087I-VW for discuss@apps.ietf.org; Thu, 13 Jul 2006 13:18:07 -0400 Received: from [132.219.23.89] (unknown [132.219.23.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 3B910A3291; Thu, 13 Jul 2006 13:18:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A51BD0C-EA1A-4FB6-80DC-CCC25FCB390D@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: HTTP Bar BoF Summary Date: Thu, 13 Jul 2006 13:18:08 -0400 To: HTTP Working Group X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org We talked about potential work on 2616. Everyone seemed to agree that cleaning up the document (e.g., folding in errata, documenting the extensibility model) is a clear win. There was also considerable interest in going a bit further; e.g., exploring implementation divergence, potentially deprecating features that have proven to be interoperability problem, and generating operational documentation. When asked, no one thought that this level of activity was a bad idea, several stated keen interest, and some indicated that they would be willing to contribute actively. No one indicated interest in working on "HTTP/1.2," but rather just more clearly documenting 1.1. There was also interest in defining extensions to HTTP, but those who spoke supported focusing on the 2616 cleanup first. 2617 was also discussed, in particular Digest authentication; while there are some errata that could be incorporated in a backwards- compatible fashion, several people raised issues that they thought could only be addressed by a backwards-incompatible revision to Digest (i.e., a new Digest-like HTTP authentication scheme within the HTTP authentication framework). Again, there was broad support for such work, and no detractors spoke up. There was some discussion of whether this would be relevant to the activities in the WAE BoF, but those who spoke felt that this effort had a different scope, and would be most appropriate in an HTTP-focused WG. It was agreed that the next steps to explore these items is to: * Engage implementers, ideally holding an interop (either virtual or real) to discover and explore various problem areas * Write a problem statement exploring the issues to be addressed more deeply * Prepare a straw-man charter for an umbrella HTTP WG * Request a BoF in San Diego We then recessed to drink beer and eat French fries covered in gravy and cheese. Attendees: - Phillip Hallam-Baker - Scott Lawrence - Lisa Dusseault - Mark Baker - Dave Raggett - Carsten Bormann - Cyrus Daboo - Thomas Roessler - Yngve Pettersen - Alexei Melkinov - Mark Nottingham -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Thu Jul 13 13:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15IR-0002A1-TI; Thu, 13 Jul 2006 13:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G15IQ-00029w-IG for discuss@apps.ietf.org; Thu, 13 Jul 2006 13:48:18 -0400 Received: from mxout-04.mxes.net ([205.237.194.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G15IP-0001HY-A4 for discuss@apps.ietf.org; Thu, 13 Jul 2006 13:48:18 -0400 Received: from [132.219.23.89] (unknown [132.219.23.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id DF736A32A4; Thu, 13 Jul 2006 13:48:16 -0400 (EDT) In-Reply-To: <6A51BD0C-EA1A-4FB6-80DC-CCC25FCB390D@mnot.net> References: <6A51BD0C-EA1A-4FB6-80DC-CCC25FCB390D@mnot.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: HTTP Bar BoF Summary Date: Thu, 13 Jul 2006 13:48:19 -0400 To: HTTP Working Group X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org s/Melkinov/Melnikov/ Apologies to Alexei. Did I mangle anyone else's name, or miss anyone? On 2006/07/13, at 1:18 PM, Mark Nottingham wrote: > > We talked about potential work on 2616. > > Everyone seemed to agree that cleaning up the document (e.g., > folding in errata, documenting the extensibility model) is a clear > win. There was also considerable interest in going a bit further; > e.g., exploring implementation divergence, potentially deprecating > features that have proven to be interoperability problem, and > generating operational documentation. When asked, no one thought > that this level of activity was a bad idea, several stated keen > interest, and some indicated that they would be willing to > contribute actively. > > No one indicated interest in working on "HTTP/1.2," but rather just > more clearly documenting 1.1. There was also interest in defining > extensions to HTTP, but those who spoke supported focusing on the > 2616 cleanup first. > > 2617 was also discussed, in particular Digest authentication; while > there are some errata that could be incorporated in a backwards- > compatible fashion, several people raised issues that they thought > could only be addressed by a backwards-incompatible revision to > Digest (i.e., a new Digest-like HTTP authentication scheme within > the HTTP authentication framework). Again, there was broad support > for such work, and no detractors spoke up. There was some > discussion of whether this would be relevant to the activities in > the WAE BoF, but those who spoke felt that this effort had a > different scope, and would be most appropriate in an HTTP-focused WG. > > It was agreed that the next steps to explore these items is to: > * Engage implementers, ideally holding an interop (either virtual > or real) to discover and explore various problem areas > * Write a problem statement exploring the issues to be addressed > more deeply > * Prepare a straw-man charter for an umbrella HTTP WG > * Request a BoF in San Diego > > We then recessed to drink beer and eat French fries covered in > gravy and cheese. > > Attendees: > - Phillip Hallam-Baker > - Scott Lawrence > - Lisa Dusseault > - Mark Baker > - Dave Raggett > - Carsten Bormann > - Cyrus Daboo > - Thomas Roessler > - Yngve Pettersen > - Alexei Melkinov > - Mark Nottingham > > -- > Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/ From discuss-bounces@apps.ietf.org Sat Jul 15 14:56:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1pJM-00016j-42; Sat, 15 Jul 2006 14:56:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1pJK-00016d-3G for discuss@apps.ietf.org; Sat, 15 Jul 2006 14:56:18 -0400 Received: from mxout-04.mxes.net ([205.237.194.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1pJI-0003BQ-Os for discuss@apps.ietf.org; Sat, 15 Jul 2006 14:56:18 -0400 Received: from [192.168.1.5] (unknown [71.131.35.13]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 58906A3206; Sat, 15 Jul 2006 14:56:15 -0400 (EDT) In-Reply-To: References: <6A51BD0C-EA1A-4FB6-80DC-CCC25FCB390D@mnot.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2921FADA-A59E-4DA0-8DBA-6C328F19709F@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham Subject: Re: HTTP Bar BoF Summary Date: Sat, 15 Jul 2006 11:56:14 -0700 To: HTTP Working Group X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: discuss@apps.ietf.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org + John Klensin On 2006/07/13, at 10:48 AM, Mark Nottingham wrote: > s/Melkinov/Melnikov/ > > Apologies to Alexei. Did I mangle anyone else's name, or miss anyone? > > > On 2006/07/13, at 1:18 PM, Mark Nottingham wrote: > >> >> We talked about potential work on 2616. >> >> Everyone seemed to agree that cleaning up the document (e.g., >> folding in errata, documenting the extensibility model) is a clear >> win. There was also considerable interest in going a bit further; >> e.g., exploring implementation divergence, potentially deprecating >> features that have proven to be interoperability problem, and >> generating operational documentation. When asked, no one thought >> that this level of activity was a bad idea, several stated keen >> interest, and some indicated that they would be willing to >> contribute actively. >> >> No one indicated interest in working on "HTTP/1.2," but rather >> just more clearly documenting 1.1. There was also interest in >> defining extensions to HTTP, but those who spoke supported >> focusing on the 2616 cleanup first. >> >> 2617 was also discussed, in particular Digest authentication; >> while there are some errata that could be incorporated in a >> backwards-compatible fashion, several people raised issues that >> they thought could only be addressed by a backwards-incompatible >> revision to Digest (i.e., a new Digest-like HTTP authentication >> scheme within the HTTP authentication framework). Again, there was >> broad support for such work, and no detractors spoke up. There was >> some discussion of whether this would be relevant to the >> activities in the WAE BoF, but those who spoke felt that this >> effort had a different scope, and would be most appropriate in an >> HTTP-focused WG. >> >> It was agreed that the next steps to explore these items is to: >> * Engage implementers, ideally holding an interop (either >> virtual or real) to discover and explore various problem areas >> * Write a problem statement exploring the issues to be addressed >> more deeply >> * Prepare a straw-man charter for an umbrella HTTP WG >> * Request a BoF in San Diego >> >> We then recessed to drink beer and eat French fries covered in >> gravy and cheese. >> >> Attendees: >> - Phillip Hallam-Baker >> - Scott Lawrence >> - Lisa Dusseault >> - Mark Baker >> - Dave Raggett >> - Carsten Bormann >> - Cyrus Daboo >> - Thomas Roessler >> - Yngve Pettersen >> - Alexei Melkinov >> - Mark Nottingham >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > > > -- > Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/