atompub calsify crisp eai lemonade imapext ltru opes sieve usefor widex ipr ancp autoconf dna dnsext dhc eap hip ipdvb 16ng iporpr ipv6 6lowpan l2vpn l3vpn l2tpext monami6 mipshop mip4 mip6 magma nemo ntp netlmm pppext pana pwe3 shim6 softwire trill adslmib bmwg capwap dime dnsop hubmib grow imss ipfix ipcdn v6ops mboned netconf opsec psamp radext multi6 avt xcon ecrit geopriv ieprep iptel mmusic p2psip sipping sip speermint sigtran simple speechsc enum bfd ccamp forces idr isis l1vpn manet mpls ospf pce pim rtgwg rpsec sidr vrrp openpgp btns dkim emu hokey isms krb-wg kitten ltans msec nea pki4ipsec keyprov pkix smime syslog sasl tls behave pcn dccp fecframe ippm ips midcom nfsv4 nsis pmtud rmt rserpool rddp rohc tcpm tsvwg Atom Publishing Format and Protocol (atompub) --------------------------------------------- Charter Last Modified: 2006-03-24 Current Status: Active Working Group Chair(s): Paul Hoffman Tim Bray Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Secretary(ies): Sam Ruby Mailing Lists: General Discussion:atom-syntax@imc.org To Subscribe: atom-syntax-request@imc.org In Body: In Body: subscribe Archive: http://www.imc.org/atom-syntax/mail-archive/ Description of Working Group: Atom defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern. Atom consists of: * A conceptual model of a resource * A concrete syntax for this model * A syndication and archiving format (the Atom feed format) using this syntax * An editing protocol using this syntax The format must be able to represent: * a resource that is a Weblog entry or article (e.g., it has an author, date, identifier, and content) * a feed or channel of entries, with or without enclosed content * a complete archive of all entries in a feed * existing well-formed XML (especially XHTML) content * additional information in an user-extensible manner The editing protocol must enable: * creating, editing, and deleting feed entries * multiple authors for a feed * multiple subjects or categories in a feed * user authentication * adding, editing, and deleting users * setting and getting user preferences * creating, getting and setting related resources such as comments, templates, etc. The working group will use experience gained with RSS (variably used as a name by itself and as an acronym for "RDF Site Summary", "Rich Site Summary", or "Really Simple Syndication") as the basis for a standards-track document specifying the model, syntax, and feed format. The feed format and HTTP will be used as the basis of work on a standards-track document specifying the editing protocol. The goal for the working group is to produce a single feed format and a single editing protocol; the working group will only consider additional formats or additional protocols if those charter changes are approved by the IESG. The working group will also take steps to ensure interoperability, by: * unambiguously identifying required elements in formats * clearly nominating conformance levels for different types of software * providing clear extensibility mechanisms and constraints upon them The Atom protocol will be designed to provide security services for updating and accessing dynamic online resources. The working group will consider current known issues with requirements for remote access, along with the fact that many such resources are constrained by providers who provide the resource owners with little configuration control. The working group's primary focus will be on delivering an interoperable format and corresponding protocol; it is expected that all but the most basic, generic metadata and functions will be accommodated through extensions, rather than in the core documents. Extension development is not included in this charter. The working group will consider the need to either close or to modify the charter and document extensions once the core document set has been approved by the IESG. The working group has two mailing lists: atom-syntax@imc.org for discussing the Atom format and atom-protocol@imc.org for discussing the protocol. Description of Working Group: Atom defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern. Atom consists of: * A conceptual model of a resource * A concrete syntax for this model * A syndication and archiving format (the Atom feed format) using this syntax * An editing protocol using this syntax The format must be able to represent: * a resource that is a Weblog entry or article (e.g., it has an author, date, identifier, and content) * a feed or channel of entries, with or without enclosed content * a complete archive of all entries in a feed * existing well-formed XML (especially XHTML) content * additional information in an user-extensible manner The editing protocol must enable: * creating, editing, and deleting feed entries * multiple authors for a feed * multiple subjects or categories in a feed * user authentication * adding, editing, and deleting users * setting and getting user preferences * creating, getting and setting related resources such as comments, templates, etc. The working group will use experience gained with RSS (variably used as a name by itself and as an acronym for "RDF Site Summary", "Rich Site Summary", or "Really Simple Syndication") as the basis for a standards-track document specifying the model, syntax, and feed format. The feed format and HTTP will be used as the basis of work on a standards-track document specifying the editing protocol. The goal for the working group is to produce a single feed format and a single editing protocol; the working group will only consider additional formats or additional protocols if those charter changes are approved by the IESG. The working group will also take steps to ensure interoperability, by: * unambiguously identifying required elements in formats * clearly nominating conformance levels for different types of software * providing clear extensibility mechanisms and constraints upon them The Atom protocol will be designed to provide security services for updating and accessing dynamic online resources. The working group will consider current known issues with requirements for remote access, along with the fact that many such resources are constrained by providers who provide the resource owners with little configuration control. The working group's primary focus will be on delivering an interoperable format and corresponding protocol; it is expected that all but the most basic, generic metadata and functions will be accommodated through extensions, rather than in the core documents. Extension development is not included in this charter. The working group will consider the need to either close or to modify the charter and document extensions once the core document set has been approved by the IESG. The working group has two mailing lists: atom-syntax@imc.org for discussing the Atom format and atom-protocol@imc.org for discussing the protocol. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2004 Mar 2007 The Atom Publishing Protocol Jan 2007 Jan 2007 The application/atom+xml Type Parameter Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- Charter Last Modified: 2006-07-26 Current Status: Active Working Group Chair(s): Eliot Lear Aki Niemi Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-calsify@osafoundation.org To Subscribe: http://lists.osafoundation.org/mailman/listinfo/ietf-calsify Archive: http://lists.osafoundation.org/pipermail/ietf-calsify/ Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability has been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Revise the Calendaring and Scheduling Standards to advance the state of interoperable calendaring and scheduling by addressing the known interoperability issues, errata, and problems found based on implementation experience. (2) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (3) Provide a means to ease transition from, and to co-exist with, the earlier iCalendar standards to the new ones. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Depending on the results of the update process on the standards documents the working group will consider whether advancing the documents to draft standard is appropriate. If we decide to move the documents to draft status, milestones may get changed and/or added to allow for any additional work necessary to advance the documents. Description of Working Group: The Calendaring and Scheduling standards, defined in RFC's 2445, 2446, and 2447 were released in November 1998, and further described in RFC 3283. They were designed to progress the level of interoperability between dissimilar calendaring and scheduling systems. The Calendaring and Scheduling Core Object Specification, iCalendar, succeeded in establishing itself as the common format for exchanging calendaring information across the Internet. On the other hand, only basic interoperability has been achieved between different scheduling systems. The Calsify working group is chartered to: (1) Revise the Calendaring and Scheduling Standards to advance the state of interoperable calendaring and scheduling by addressing the known interoperability issues, errata, and problems found based on implementation experience. (2) Clarify the registration process for iCalendar extensions (i.e., the current core object specification only provides a template to register new properties). (3) Provide a means to ease transition from, and to co-exist with, the earlier iCalendar standards to the new ones. Proposing an XML representation or transformation of iCalendar objects is out of the scope of this working group. Depending on the results of the update process on the standards documents the working group will consider whether advancing the documents to draft standard is appropriate. If we decide to move the documents to draft status, milestones may get changed and/or added to allow for any additional work necessary to advance the documents. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2005 Feb 2007 iCalendar Message-Based Interoperability Protocol (iMIP) Oct 2005 Mar 2007 iCalendar Transport-Independent Interoperability Protocol (iTIP) Oct 2005 Mar 2007 Internet Calendaring and Scheduling Core Object Specification (iCalendar) Cross Registry Information Service Protocol (crisp) --------------------------------------------------- Charter Last Modified: 2006-08-16 Current Status: Active Working Group Chair(s): April Marine George Michaelson Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion:crisp@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/crisp Archive: http://www.ietf.org/mail-archive/web/crisp/index.html Description of Working Group: In the standard operation of Internet systems, various labels and data are managed globally -- domain names, IPv4 and IPv6 addresses, etc. From time to time, for operational and administrative purposes, users of the Internet need to be able to find and access registered nformation associated with those labels. The CRISP (Cross-Registry Information Service Protocol) WG will define a standard mechanism that can be used for: - finding authoritative information associated with a label, - a protocol to transport queries and responses for accessing that information, - a first profile (schema & queries) to support commonly-required queries for domain registration information, - a second profile (schema & queries) to support commonly-required queries for numbering resource information. ("numbering resources" is used to refer to IP addresses and ASNs) The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future to other types of registries beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - Backwards compatibility with existing administrative directory services such as WHOIS. - Provisioning of data into registry or registrar systems. CRISP provides a uniform access to and view of data that may be held in disparate backend servers. The CRISP service definition will define: - a standard mechanism that can be used to determine the authoritative server(s) for information about a given label - a single mandatory to implement protocol for transporting application queries and responses, including - expression of input query - expression of result sets - standard expression of error conditions - authentication and verification of data integrity - specific data types and queries to be supported in the supported registry services. Deliverables: - Requirements document as an Informational RFC. (previously submitted) - First draft of protocol (use) specification. (previously submitted) - First draft of domain registration administrative directory services required schema element specification. (previously submitted) - Document specifying a new protocol, or the use of an existing one, for providing CRISP service (application transport). - Document specifying required schema elements and queries for domain registration administrative directory queries. - Document specifying required schema elements and queries for numbering resources registration administrative directory queries. Description of Working Group: In the standard operation of Internet systems, various labels and data are managed globally -- domain names, IPv4 and IPv6 addresses, etc. From time to time, for operational and administrative purposes, users of the Internet need to be able to find and access registered nformation associated with those labels. The CRISP (Cross-Registry Information Service Protocol) WG will define a standard mechanism that can be used for: - finding authoritative information associated with a label, - a protocol to transport queries and responses for accessing that information, - a first profile (schema & queries) to support commonly-required queries for domain registration information, - a second profile (schema & queries) to support commonly-required queries for numbering resource information. ("numbering resources" is used to refer to IP addresses and ASNs) The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future to other types of registries beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - Backwards compatibility with existing administrative directory services such as WHOIS. - Provisioning of data into registry or registrar systems. CRISP provides a uniform access to and view of data that may be held in disparate backend servers. The CRISP service definition will define: - a standard mechanism that can be used to determine the authoritative server(s) for information about a given label - a single mandatory to implement protocol for transporting application queries and responses, including - expression of input query - expression of result sets - standard expression of error conditions - authentication and verification of data integrity - specific data types and queries to be supported in the supported registry services. Deliverables: - Requirements document as an Informational RFC. (previously submitted) - First draft of protocol (use) specification. (previously submitted) - First draft of domain registration administrative directory services required schema element specification. (previously submitted) - Document specifying a new protocol, or the use of an existing one, for providing CRISP service (application transport). - Document specifying required schema elements and queries for domain registration administrative directory queries. - Document specifying required schema elements and queries for numbering resources registration administrative directory queries. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 2004 Dec 2006 A Domain Availability Check (dchk) Registry Type for the Internet Registry Information Service (IRIS) Oct 2004 Mar 2007 A Lightweight UDP Transfer Protocol for the the Internet Registry Information Service May 2005 Mar 2007 A Common Schema for Internet Registry Information Service Transfer Protocols May 2005 Mar 2007 XML Pipelining with Chunks for the Information Registry Information Service Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2006-08-15 Current Status: Active Working Group Chair(s): Harald Alvestrand XiaoDong Lee Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion:ima@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ima Archive: http://www1.ietf.org/mail-archive/web/ima/index.html Description of Working Group: Since early in the effort to internationalize domain names, which resulted in the standards associated with IDNA, it has been understood that internationalization of email address local parts is required. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts by any system other than the final delivery one make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in ways that are at least compatible, suggests that this is not a simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups. Key parts of this effort include extended analyses and, if necessary, proof of concept in three areas in addition to smooth operation when all systems and components along a message path have been upgraded to support the new facilities. They are o Examination of scenarios for the appearance of these facilities to users, including ways in which alternate addresses may be specified if those are needed for downgrading. o Examination of different locations at which downgrading might be required and accomplished, differentiating between requirements and capabilities at the point of origin (at or before the submission server), those that exist while the message is in transit, and those that apply after SMTP "final delivery" or in the logical vicinity or an IMAP or POP server. o Examination of the "mailing list question", i.e., how a mixture of traditional and internationalized addresses on a mailing list will impact message flows, error reports, and delivery notifications in all plausible combinations of servers and addresses, including internationalizated and traditional reverse paths. Once the Experimental RFCs are completed and implemented, the experience gathered will be evaluated. If the approach is found to have been successful (using criteria the WG will establish as an early work item), the WG will be rechartered to update the documents for processing onto the standards track. 1.6. Deliverables The following deliverables are foreseen in this charter. The WG chairs may structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. o Overview and architecture (Info) o Interworking scenarios, including the "mailing list question" (Info) o SMTP extensions specification (Exp) o Header format specification (Exp) o Downgrading specification in SMTP (Exp) o Downgrading specification in POP servers (Exp) o Downgrading specification in IMAP servers (Exp) o Results and evaluation of experiment (Info) Going forward, it is possible that the SMTP downgrading specification will go for Informational due to the difficulty of fully specifying all necessary behavior. Additional possible documents suggested: Advice for MUA implementors (Info) Description of Working Group: Since early in the effort to internationalize domain names, which resulted in the standards associated with IDNA, it has been understood that internationalization of email address local parts is required. At the same time, email address internationalization poses a series of special problems. Constraints on the interpretation of local-parts by any system other than the final delivery one make address encoding nearly impossible. The need to use addresses in both the email envelope and in header fields, and to do so in ways that are at least compatible, suggests that this is not a simple and isolated problem. This working group will address one basic approach to email internationalization. That approach is based on the use of an SMTP extension to enable both the use of UTF-8 in envelope address local- parts and optionally in domain-parts and the use of UTF-8 in mail headers -- both in address contexts and wherever encoded-words are permitted today. Its initial target will be a set of experimental RFCs that specify the details of this approach and provide the basis for generating and testing interoperable implementations. Its work will include examining whether "downgrading" -- transforming an internationalized message to one that is compatible with unextended SMTP clients and servers and unextended MUAs -- is feasible and appropriate and, if it is, specifying a way to do so. If it is not, the WG will evaluate whether the effort is worth taking forward. Other approaches may be considered by the formation of other working groups. Key parts of this effort include extended analyses and, if necessary, proof of concept in three areas in addition to smooth operation when all systems and components along a message path have been upgraded to support the new facilities. They are o Examination of scenarios for the appearance of these facilities to users, including ways in which alternate addresses may be specified if those are needed for downgrading. o Examination of different locations at which downgrading might be required and accomplished, differentiating between requirements and capabilities at the point of origin (at or before the submission server), those that exist while the message is in transit, and those that apply after SMTP "final delivery" or in the logical vicinity or an IMAP or POP server. o Examination of the "mailing list question", i.e., how a mixture of traditional and internationalized addresses on a mailing list will impact message flows, error reports, and delivery notifications in all plausible combinations of servers and addresses, including internationalizated and traditional reverse paths. Once the Experimental RFCs are completed and implemented, the experience gathered will be evaluated. If the approach is found to have been successful (using criteria the WG will establish as an early work item), the WG will be rechartered to update the documents for processing onto the standards track. 1.6. Deliverables The following deliverables are foreseen in this charter. The WG chairs may structure the deliverables into specific documents or document sets as needed. Adding or removing documents outside of these deliverables will require a charter update. o Overview and architecture (Info) o Interworking scenarios, including the "mailing list question" (Info) o SMTP extensions specification (Exp) o Header format specification (Exp) o Downgrading specification in SMTP (Exp) o Downgrading specification in POP servers (Exp) o Downgrading specification in IMAP servers (Exp) o Results and evaluation of experiment (Info) Going forward, it is possible that the SMTP downgrading specification will go for Informational due to the difficulty of fully specifying all necessary behavior. Additional possible documents suggested: Advice for MUA implementors (Info) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2006 Mar 2007 SMTP extension for internationalized email address May 2006 Feb 2007 UTF-8 Mail: Scenarios May 2006 Feb 2007 Overview and Framework for Internationalized Email May 2006 Mar 2007 Downgrading mechanism for Email Address Internationalization May 2006 Mar 2007 IMAP Support for UTF-8 Jun 2006 Mar 2007 Internationalized Email Headers Jun 2006 Jan 2007 Mailing Lists and Internationalized Email Addresses Jun 2006 Jan 2007 POP3 Support for UTF-8 Jan 2007 Jan 2007 International Delivery and Disposition Notifications Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- Charter Last Modified: 2007-03-12 Current Status: Active Working Group Chair(s): Glenn Parsons Eric Burger Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion:lemonade@ietf.org To Subscribe: lemonade-request@ietf.org In Body: in boby 'subscribe' Archive: http://www.ietf.org/mail-archive/web/lemonade/index.html Description of Working Group: Lemonade is tasked to provide a set of enhancements and profiles of Internet email submission, transport, and retrieval protocols to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. Lemonade's work is at the crossroads of a body of work related to Internet messaging, in particular work done by the VPIM, FAX, and IMAPEXT IETF working groups. Given the potentially broad scope of activities this group could engage in, the group will focus specifically on the following work items: 0. An informational RFC or RFCs will be produced on LEMONADE architecture and the issues it seeks to address. 1. Enhance the existing IMAP4 message retrieval and message submission (RFC 2476) protocols to satisfy the requirements for handling streaming multimedia content. The existing standards-track CONNEG framework will be used if content negotiation capabilities are needed. The group will employ existing protocols (such as for streaming) with IMAP4 instead of duplicating such functionality within IMAP4. 2. Enhance the existing IMAP4 message retrieval and/or message submission (RFC 2476) protocols to satisfy the requirements for forwarding a message and/or its attachments without downloading the message to the client and subsequently uploading the message to a server. 3. Refine the existing IMAP4 message retrieval protocol to facilitate its use with devices that have limited capabilities such as mobile endpoints. At most one backwards compatible profile of IMAP4 will be produced by this effort. 4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications. 5. Create a specification describing the use of Internet message services in environments where message delivery may take place using either Internet protocols or through an MMS server using WAP to communicate with the receiving user agent. Any protocols defined by this working group will include appopriate security mechanisms, including authentication, privacy, and access control. Mandatory-to-implement security mechanisms will be specified as needed in order to guarantee secure protocol interoperability. The transport area will be consulted to deal with any transport-related issues that arise, especially in regards to items 1-4 above. The IAB is currently working on the specification of general guidelines and requirements for notification services. Once complete this work will be used as input to item 4 above. The working group is aware of several related activities in other groups: - 3GPP TSG T WG2 SWG3 Messaging - W3C Mulitmodal interaction Activity - Open Mobile Alliance - 3GPP2 TSG-X The goal is to coordinate efforts with at least these groups as required. While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the working group does not expect to coordinate with these other groups. Description of Working Group: Lemonade is tasked to provide a set of enhancements and profiles of Internet email submission, transport, and retrieval protocols to facilitate operation on platforms with constrained resources, or communications links with high latency or limited bandwidth. A primary goal of this work is to ensure that those profiles and enhancements continue to interoperate with the existing Internet email protocols in use on the Internet, so that these environments and more traditional Internet users have access to a seamless service. Lemonade's work is at the crossroads of a body of work related to Internet messaging, in particular work done by the VPIM, FAX, and IMAPEXT IETF working groups. Given the potentially broad scope of activities this group could engage in, the group will focus specifically on the following work items: 0. An informational RFC or RFCs will be produced on LEMONADE architecture and the issues it seeks to address. 1. Enhance the existing IMAP4 message retrieval and message submission (RFC 2476) protocols to satisfy the requirements for handling streaming multimedia content. The existing standards-track CONNEG framework will be used if content negotiation capabilities are needed. The group will employ existing protocols (such as for streaming) with IMAP4 instead of duplicating such functionality within IMAP4. 2. Enhance the existing IMAP4 message retrieval and/or message submission (RFC 2476) protocols to satisfy the requirements for forwarding a message and/or its attachments without downloading the message to the client and subsequently uploading the message to a server. 3. Refine the existing IMAP4 message retrieval protocol to facilitate its use with devices that have limited capabilities such as mobile endpoints. At most one backwards compatible profile of IMAP4 will be produced by this effort. 4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications. 5. Create a specification describing the use of Internet message services in environments where message delivery may take place using either Internet protocols or through an MMS server using WAP to communicate with the receiving user agent. Any protocols defined by this working group will include appopriate security mechanisms, including authentication, privacy, and access control. Mandatory-to-implement security mechanisms will be specified as needed in order to guarantee secure protocol interoperability. The transport area will be consulted to deal with any transport-related issues that arise, especially in regards to items 1-4 above. The IAB is currently working on the specification of general guidelines and requirements for notification services. Once complete this work will be used as input to item 4 above. The working group is aware of several related activities in other groups: - 3GPP TSG T WG2 SWG3 Messaging - W3C Mulitmodal interaction Activity - Open Mobile Alliance - 3GPP2 TSG-X The goal is to coordinate efforts with at least these groups as required. While there is obvious synergy, given the end-of-life of the VPIM and FAX work groups and the similar membership, the working group does not expect to coordinate with these other groups. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2005 Jan 2007 IMAP URL Scheme Oct 2005 Oct 2006 CONVERT Dec 2005 Mar 2007 Support for Sieve in Internet Message Access Protocol (IMAP4) Jan 2006 Oct 2006 LEMONADE profile bis Mar 2006 Mar 2007 Deployment Considerations for lemonade-compliant Mobile Email Mar 2006 Mar 2007 WITHIN Search extension to the IMAP Protocol Mar 2006 Jan 2007 The IMAP COMPRESS Extension Jun 2006 Mar 2007 Internet Message Store Events Jun 2006 Mar 2007 Streaming Multimedia Messaging Attachments Jun 2006 Feb 2007 IMAP4 Extensions for Quick Mailbox Resynchronization Internet Message Access Protocol Extension (imapext) ---------------------------------------------------- Charter Last Modified: 2006-03-29 Current Status: Active Working Group Chair(s): Pete Resnick Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-imapext@imc.org To Subscribe: ietf-imapext-request@imc.org Archive: http://www.imc.org/ietf-imapext/ Description of Working Group: The IETF IMAP extensions Working Group shall revise and publish standards-track extensions to IMAP4 for performing the following functions: 1. Sorting, threading, and viewing (to be dealt with by one or more mechanisms) 2. Access Control Lists 3. Message-level annotations Revising the base IMAP4rev1 specification is out of the scope of this WG. However, this WG will ensure that whatever extensions it does propose do not worsen any existing problems in the base specification of IMAP, nor do they make any such problems harder to address in the future. Description of Working Group: The IETF IMAP extensions Working Group shall revise and publish standards-track extensions to IMAP4 for performing the following functions: 1. Sorting, threading, and viewing (to be dealt with by one or more mechanisms) 2. Access Control Lists 3. Message-level annotations Revising the base IMAP4rev1 specification is out of the scope of this WG. However, this WG will ensure that whatever extensions it does propose do not worsen any existing problems in the base specification of IMAP, nor do they make any such problems harder to address in the future. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Aug 1999 Nov 2006 INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS Jul 2000 Oct 2006 IMAP ANNOTATE Extension Oct 2000 Sep 2006 IMAP4 LIST Command Extensions May 2003 Mar 2007 Internet Message Access Protocol Internationalization Language Tag Registry Update (ltru) ----------------------------------- Charter Last Modified: 2006-11-30 Current Status: Active Working Group Chair(s): Randy Presuhn Martin Duerst Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion:ltru@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ltru Archive: http://www.ietf.org/mail-archive/web/ltru/index.html Description of Working Group: The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more code elements for identifying languages. The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. Work on the drafts is planned to start before ISO 639-3 is fully approved and published. However, the WG will not finalize the drafts before ISO 639-3 is fully approved. Description of Working Group: The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more code elements for identifying languages. The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. Work on the drafts is planned to start before ISO 639-3 is fully approved and published. However, the WG will not finalize the drafts before ISO 639-3 is fully approved. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2006 Dec 2006 Tags for Identifying Languages Sep 2006 Jan 2007 Update to the Language Subtag Registry Open Pluggable Edge Services (opes) ----------------------------------- Charter Last Modified: 2006-12-29 Current Status: Active Working Group Chair(s): Tony Hansen Markus Hofmann Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Technical Advisor(s): Allison Mankin Hilarie Orman Mailing Lists: General Discussion:ietf-openproxy@imc.org To Subscribe: ietf-openproxy-request@imc.org Archive: http://www1.ietf.org/mail-archive/web/newtrk/current/ Description of Working Group: The Internet facilitates the development of networked services at the application level that both offload origin servers and improve the user experience. Web proxies, for example, are commonly deployed to provide services such as Web caching, virus scanning, and request filtering. Lack of standardized mechanisms to trace and to control such intermediaries causes problems with respect to failure detection, data integrity, privacy, and security. The OPES Working Group has previously developed an architectural framework to authorize, invoke, and trace such application-level services for HTTP. The framework follows a one-party consent model, which requires that each service be authorized explicitly by at least one of the application-layer endpoints. It further requires that OPES services are reversible by mutual agreement of the application endpoints. In particular, the WG has developed a protocol suite for invocation and tracking of OPES services inside the net. The protocol suite includes a generic, application-agnostic protocol core (OCP Core) that is supplemented by profiles specific to the application-layer protocol used between the endpoints. So far, the WG has specified an OCP profile for HTTP, which supports OPES services that operate on HTTP messages. In a next step, the WG will specify one or more OCP profiles that will support OPES services operating on SMTP. In particular, the profile to be specified will enable an SMTP server (the OPES processor) to encapsulate and forward SMTP data and metadata to a callout server for additional processing. Several kinds of agents participate in SMTP exchanges, including MSA, MTA, MDA, and MUA. The first OCP/SMTP profile will address the needs of at least the MTA and/or MDA. More profiles may be needed to address other agent-specific needs, such as for LMTP and/or SUBMIT. The security and privacy concerns of SMTP must be carefully analyzed as part of the definition of the profile. In addition, the WG will define a rules language to control selection and invocation of services by an OPES processor. This includes a mechanism allowing an OPES processor to perform a runtime check of service parameters, leveraging existing interface description standards like WSDL, if possible, or OPES-specific description otherwise. Defining language(s) for implementing OPES services is out of the WG scope. The rules language will be based on previous work of the WG on a rules language named "P". The WG will have a design goal that the language be compatible with existing policy work within the IETF (e.g. IETF Policy Framework) and be able to interface with systems automating distribution of policies to multiple endpoints. It will be out of scope for this WG to develop the policy framework and specify multiple-endpoint policy distribution. The group's new work items can be listed as: - Develop a document about "Scenarios and Use Cases for OPES Services operating on SMTP". - Define profile(s) for OCP core that handle SMTP messages or parts thereof. - Define a rules language to control the selection and invocation of HTTP-based or SMTP-based OPES services. Each deliverable must follow the previously developed OPES architecture. As each deliverable is developed, it must address the IAB considerations specified in RFC 3238. Description of Working Group: The Internet facilitates the development of networked services at the application level that both offload origin servers and improve the user experience. Web proxies, for example, are commonly deployed to provide services such as Web caching, virus scanning, and request filtering. Lack of standardized mechanisms to trace and to control such intermediaries causes problems with respect to failure detection, data integrity, privacy, and security. The OPES Working Group has previously developed an architectural framework to authorize, invoke, and trace such application-level services for HTTP. The framework follows a one-party consent model, which requires that each service be authorized explicitly by at least one of the application-layer endpoints. It further requires that OPES services are reversible by mutual agreement of the application endpoints. In particular, the WG has developed a protocol suite for invocation and tracking of OPES services inside the net. The protocol suite includes a generic, application-agnostic protocol core (OCP Core) that is supplemented by profiles specific to the application-layer protocol used between the endpoints. So far, the WG has specified an OCP profile for HTTP, which supports OPES services that operate on HTTP messages. In a next step, the WG will specify one or more OCP profiles that will support OPES services operating on SMTP. In particular, the profile to be specified will enable an SMTP server (the OPES processor) to encapsulate and forward SMTP data and metadata to a callout server for additional processing. Several kinds of agents participate in SMTP exchanges, including MSA, MTA, MDA, and MUA. The first OCP/SMTP profile will address the needs of at least the MTA and/or MDA. More profiles may be needed to address other agent-specific needs, such as for LMTP and/or SUBMIT. The security and privacy concerns of SMTP must be carefully analyzed as part of the definition of the profile. In addition, the WG will define a rules language to control selection and invocation of services by an OPES processor. This includes a mechanism allowing an OPES processor to perform a runtime check of service parameters, leveraging existing interface description standards like WSDL, if possible, or OPES-specific description otherwise. Defining language(s) for implementing OPES services is out of the WG scope. The rules language will be based on previous work of the WG on a rules language named "P". The WG will have a design goal that the language be compatible with existing policy work within the IETF (e.g. IETF Policy Framework) and be able to interface with systems automating distribution of policies to multiple endpoints. It will be out of scope for this WG to develop the policy framework and specify multiple-endpoint policy distribution. The group's new work items can be listed as: - Develop a document about "Scenarios and Use Cases for OPES Services operating on SMTP". - Define profile(s) for OCP core that handle SMTP messages or parts thereof. - Define a rules language to control the selection and invocation of HTTP-based or SMTP-based OPES services. Each deliverable must follow the previously developed OPES architecture. As each deliverable is developed, it must address the IAB considerations specified in RFC 3238. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- May 2006 Feb 2007 Integrity, privacy and security in OPES for SMTP Sieve Mail Filtering Language (sieve) ------------------------------------- Charter Last Modified: 2007-01-16 Current Status: Active Working Group Chair(s): Cyrus Daboo Alexey Melnikov Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-mta-filters@imc.org To Subscribe: ietf-mta-filters-request@imc.org In Body: body=subscribe Archive: http://www.imc.org/ietf-mta-filters/mail-archive/ Description of Working Group: The sieve mail filtering language specified in RFC 3028 has now been implemented in a wide variety of user agents (UAs), mail delivery agents (MDAs), and mail transfer agents (MTAs). Several extensions have been specified (RFCs 3431, 3598, 3685, 3894) and have also been widely implemented. Several additional sieve extensions have been defined in various internet-drafts. All of these documents are individual submissions; up to this point work on sieve has been done informally and not under the auspices of any IETF working group. The sieve working group is being chartered to: (1) Revise the base sieve specification, RFC 3028, with the intention of moving it to draft standard. Substantive additions or revisions to the base specification are out of scope of this working group. However, the need to loosen current restrictions on side effects of tests as well as the need for a normative reference to the newly-defined comparators registry may necessitate a recycle at proposed. (2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598), spamtest/virustest (RFC 3685), and copy (RFC 3894) extension specifications, again with the intention of making a move to draft standard possible. It may be necessary to recycle some or all of these documents at proposed, depending on the scope of any changes. (3) Finalize and publish the sieve extensions as proposed standards: (a) Variables (draft-homme-sieve-variables-04.txt) (b) Vacation action (draft-showalter-sieve-vacation-05.txt) (c) Message body tests (draft-degener-sieve-body-02.txt) (d) Regular expressions (draft-murchison-sieve-regex-07.txt) (e) MIME part tests (draft-daboo-sieve-mime-00.txt) (f) Notification action (draft-martin-sieve-notify-02.txt) (g) IMAP flags (draft-melnikov-sieve-imapflags-06.txt) (h) Header editing actions (draft-degener-sieve-editheader-01.txt) (i) Reject before delivery (draft-elvey-refuse-sieve-01.txt) Additional drafts may be added this list, but only via a charter revision. There must also be demonstrable willingness in the sieve development community to actually implement a given extension before it can be added to this charter. Some aspects of sieve have complex internationalization issues; the working group will seek out internationalization expertise as needed to complete its work. Description of Working Group: The sieve mail filtering language specified in RFC 3028 has now been implemented in a wide variety of user agents (UAs), mail delivery agents (MDAs), and mail transfer agents (MTAs). Several extensions have been specified (RFCs 3431, 3598, 3685, 3894) and have also been widely implemented. Several additional sieve extensions have been defined in various internet-drafts. All of these documents are individual submissions; up to this point work on sieve has been done informally and not under the auspices of any IETF working group. The sieve working group is being chartered to: (1) Revise the base sieve specification, RFC 3028, with the intention of moving it to draft standard. Substantive additions or revisions to the base specification are out of scope of this working group. However, the need to loosen current restrictions on side effects of tests as well as the need for a normative reference to the newly-defined comparators registry may necessitate a recycle at proposed. (2) Produce updated sieve relational (RFC 3431), subaddress (RFC 3598), spamtest/virustest (RFC 3685), and copy (RFC 3894) extension specifications, again with the intention of making a move to draft standard possible. It may be necessary to recycle some or all of these documents at proposed, depending on the scope of any changes. (3) Finalize and publish the sieve extensions as proposed standards: (a) Variables (draft-homme-sieve-variables-04.txt) (b) Vacation action (draft-showalter-sieve-vacation-05.txt) (c) Message body tests (draft-degener-sieve-body-02.txt) (d) Regular expressions (draft-murchison-sieve-regex-07.txt) (e) MIME part tests (draft-daboo-sieve-mime-00.txt) (f) Notification action (draft-martin-sieve-notify-02.txt) (g) IMAP flags (draft-melnikov-sieve-imapflags-06.txt) (h) Header editing actions (draft-degener-sieve-editheader-01.txt) (i) Reject before delivery (draft-elvey-refuse-sieve-01.txt) Additional drafts may be added this list, but only via a charter revision. There must also be demonstrable willingness in the sieve development community to actually implement a given extension before it can be added to this charter. Some aspects of sieve have complex internationalization issues; the working group will seek out internationalization expertise as needed to complete its work. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Nov 2004 Dec 2005 Sieve Extension: Variables Feb 2005 Jul 2006 SIEVE Email Filtering: Spamtest and Virustest Extensions Feb 2005 Feb 2007 Sieve Email Filtering: Body Extension Feb 2005 Mar 2007 Sieve Email Filtering: Editheader Extension Feb 2005 May 2006 SIEVE Email Filtering: IMAP flag Extension Feb 2005 Jun 2006 Sieve Email Filtering -- Subaddress Extension Feb 2005 Dec 2005 Sieve Extension: Relational Tests Mar 2005 Mar 2007 Sieve Email Filtering: Vacation Extension May 2005 Feb 2007 Sieve: An Email Filtering Language May 2005 Oct 2006 The SIEVE mail filtering language - reject extension Sep 2005 Feb 2007 Sieve Extension: Notifications Dec 2005 Mar 2007 Sieve Notification Mechanism: mailto Jan 2006 Mar 2007 Sieve Notification Mechanism: xmpp Mar 2006 Oct 2006 SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and Enclosure Usenet Article Standard Update (usefor) --------------------------------------- Charter Last Modified: 2007-02-13 Current Status: Active Working Group Chair(s): Harald Alvestrand Alexey Melnikov Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Editor(s): Charles Lindsey Ken Murchison Mailing Lists: General Discussion:ietf-usefor@imc.org To Subscribe: ietf-usefor-request@imc.org In Body: 'subscribe' in the body of the message Archive: http://www.imc.org/ietf-usefor/index.html Description of Working Group: Note: A charter rewrite/update is underway. Motivation The Standard for Interchange of USENET Messages, defined in RFC 1036, was released in December 1987. This RFC defines the format that format that all usenet articles must follow (similar to the way RFC 822 does for email) and also covers the algorithm that is used to distribute usenet articles. Since that time there has been no official update published despite the rapid growth in Usenet and other networks that use the RFC 1036 article format. A draft update to RFC 1036 ( "Son of RFC 1036" ) was released by Henry Spencer in June 1994 but this was not further pursued and is now itself out of date. Currently a combination of this and RFC 1036 are regarded as the de-facto standard. At the present time an urgent need has been identified to formalize and document many of the current and proposed extensions to the Usenet Article format. Many extensions are only vaguely documented and have competing and overlapping alternatives. A draft update to RFC 1036 ( "Son of RFC 1036" ) was released by Henry Spencer in June 1994 but this was not further pursued and is now itself out of date. Currently a combination of this and RFC 1036 are regarded as the de-facto standard. At the present time an urgent need has been identified to formalize and document many of the current and proposed extensions to the Usenet Article format. Many extensions are only vaguely documented and have competing and overlapping alternatives. In particular the following areas need urgent attention: - Standards for the signing of articles (sign-control and PGP-MOOSE) - Authentication of cancels. - Use of non-ASCII character sets in article headers and bodies - Standardization of article bodies and the use of MIME in articles. - Standardization and extension of 3rd party control messages affecting articles (NOCEM) - General revision of various limits (eg article size) listed in previous standards. and many other aspects of the standards need reviewing. Description The Goal of this working group is to publish a standards-track successor to RFC 1036 that with particular attention to backward compatibility, formalizes best current practice and best proposed practice. The Group shall also aid and/or oversee the production of other Usenet related Internet Drafts and Standards. The Working Group shall: 1. Produce an Internet Draft (or series of drafts) that describes the core standards for a Usenet article and the features that all Usenet software should take account of. 2. Produce a group of Internet Drafts formally describing extensions to the core standard for a Usenet article (see above). 3. Produce a further Internet Draft that incorporates the core standard for a Usenet article (see 1) plus all those extensions (see 2) that the working group believe should become part of a final standard. 4. Publish a standards-track successor to RFC 1036 that formalizes best current practice and best proposed practice. 5. Publish any other extensions to the Usenet Article Standard that warrant being formal extensions but are outside the scope of the main standard. Description of Working Group: Note: A charter rewrite/update is underway. Motivation The Standard for Interchange of USENET Messages, defined in RFC 1036, was released in December 1987. This RFC defines the format that format that all usenet articles must follow (similar to the way RFC 822 does for email) and also covers the algorithm that is used to distribute usenet articles. Since that time there has been no official update published despite the rapid growth in Usenet and other networks that use the RFC 1036 article format. A draft update to RFC 1036 ( "Son of RFC 1036" ) was released by Henry Spencer in June 1994 but this was not further pursued and is now itself out of date. Currently a combination of this and RFC 1036 are regarded as the de-facto standard. At the present time an urgent need has been identified to formalize and document many of the current and proposed extensions to the Usenet Article format. Many extensions are only vaguely documented and have competing and overlapping alternatives. A draft update to RFC 1036 ( "Son of RFC 1036" ) was released by Henry Spencer in June 1994 but this was not further pursued and is now itself out of date. Currently a combination of this and RFC 1036 are regarded as the de-facto standard. At the present time an urgent need has been identified to formalize and document many of the current and proposed extensions to the Usenet Article format. Many extensions are only vaguely documented and have competing and overlapping alternatives. In particular the following areas need urgent attention: - Standards for the signing of articles (sign-control and PGP-MOOSE) - Authentication of cancels. - Use of non-ASCII character sets in article headers and bodies - Standardization of article bodies and the use of MIME in articles. - Standardization and extension of 3rd party control messages affecting articles (NOCEM) - General revision of various limits (eg article size) listed in previous standards. and many other aspects of the standards need reviewing. Description The Goal of this working group is to publish a standards-track successor to RFC 1036 that with particular attention to backward compatibility, formalizes best current practice and best proposed practice. The Group shall also aid and/or oversee the production of other Usenet related Internet Drafts and Standards. The Working Group shall: 1. Produce an Internet Draft (or series of drafts) that describes the core standards for a Usenet article and the features that all Usenet software should take account of. 2. Produce a group of Internet Drafts formally describing extensions to the core standard for a Usenet article (see above). 3. Produce a further Internet Draft that incorporates the core standard for a Usenet article (see 1) plus all those extensions (see 2) that the working group believe should become part of a final standard. 4. Publish a standards-track successor to RFC 1036 that formalizes best current practice and best proposed practice. 5. Publish any other extensions to the Usenet Article Standard that warrant being formal extensions but are outside the scope of the main standard. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2004 Jan 2007 Netnews Article Format Aug 2004 Jan 2007 Netnews Architecture and Protocols Widget Description Exchange Service (widex) ------------------------------------------- Charter Last Modified: 2006-06-15 Current Status: Active Working Group Chair(s): Dean Willis Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:widex@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/widex Archive: http://www.ietf.org/mail-archive/web/widex/index.html Description of Working Group: With the Internet reaching out to more and more devices, people are increasingly expecting to have access to services at anytime, from anywhere and using any device. Such services are being developed using Web technologies such as XML and distributed across the network rather than resident on any one device. An example is a service to access flight arrival times, where the user interface expressed in XHTML is rendered on a client device, the application logic runs on a remote server and a technique as user interface remoting is used to keep the user interface synchronized with the application logic. What is currently lacking is a convenient means for continous fine grained synchronization rather than the one provided by a request/response protocol (e.g. HTTP) for Web pages, which occurs in between page loads. This would allow the user interface to reflect changes in application state and offer greater flexibility for applications to respond to user input events. The WiDeX (Widget Description Exchange Service) Working Group seeks to define a light weight mechanism used in an IP-based network for remoting user interfaces where the user interface is represented in XML, and synchronization involves XML DOM events and XML DOM mutation/update operations. The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future with other types of descriptive user interfaces beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - XML representation of user interface objects. - Means to establish sessions and support for device coordination. The WiDeX service definition will define: - A mechanism for synchronizing distributed XML DOM objects by propagating DOM mutations/updates and DOM events. - A set of parameters that need to be negotiated by a service discovery and session setup mechanism in order to start the UI remoting session. - A framework that enables a mechanism for remoting user interfaces represented in XML format by using distributed XML DOM synchronization, and a service discovery and session setup mechanism as building blocks. Deliverables: - Requirements document. - Document specifying the framework for remoting user interfaces represented in XML format. - Document specifying the message formats for XML DOM events and updates using XML in a way that is independent of the transport protocol. - Document(s) specifying normative binding(s) to at least one transport protocol. It is possible that work undertaken in other working groups and even other standards bodies (e.g. W3C) will be referenced by this working group. It is even possible that entire deliverables could be satisfied by the work of other working groups (e.g. discovery protocols). This working group will seek to maximize the use of existing specifications where applicable. Description of Working Group: With the Internet reaching out to more and more devices, people are increasingly expecting to have access to services at anytime, from anywhere and using any device. Such services are being developed using Web technologies such as XML and distributed across the network rather than resident on any one device. An example is a service to access flight arrival times, where the user interface expressed in XHTML is rendered on a client device, the application logic runs on a remote server and a technique as user interface remoting is used to keep the user interface synchronized with the application logic. What is currently lacking is a convenient means for continous fine grained synchronization rather than the one provided by a request/response protocol (e.g. HTTP) for Web pages, which occurs in between page loads. This would allow the user interface to reflect changes in application state and offer greater flexibility for applications to respond to user input events. The WiDeX (Widget Description Exchange Service) Working Group seeks to define a light weight mechanism used in an IP-based network for remoting user interfaces where the user interface is represented in XML, and synchronization involves XML DOM events and XML DOM mutation/update operations. The WG will strive to preserve an extensible architecture so that the work possibly be useful in the future with other types of descriptive user interfaces beyond those specifically considered by the group. Specific topics that are NOT goals of this WG are: - XML representation of user interface objects. - Means to establish sessions and support for device coordination. The WiDeX service definition will define: - A mechanism for synchronizing distributed XML DOM objects by propagating DOM mutations/updates and DOM events. - A set of parameters that need to be negotiated by a service discovery and session setup mechanism in order to start the UI remoting session. - A framework that enables a mechanism for remoting user interfaces represented in XML format by using distributed XML DOM synchronization, and a service discovery and session setup mechanism as building blocks. Deliverables: - Requirements document. - Document specifying the framework for remoting user interfaces represented in XML format. - Document specifying the message formats for XML DOM events and updates using XML in a way that is independent of the transport protocol. - Document(s) specifying normative binding(s) to at least one transport protocol. It is possible that work undertaken in other working groups and even other standards bodies (e.g. W3C) will be referenced by this working group. It is even possible that entire deliverables could be satisfied by the work of other working groups (e.g. discovery protocols). This working group will seek to maximize the use of existing specifications where applicable. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jan 2006 Jan 2007 Widget Description Exchange Service (WIDEX) Requirements Intellectual Property Rights (ipr) ---------------------------------- Charter Last Modified: 2006-03-07 Current Status: Active Working Group Chair(s): Harald Alvestrand Steven Bellovin General Area Director(s): Brian Carpenter General Area Advisor: Brian Carpenter Mailing Lists: General Discussion:ipr-wg@ietf.org To Subscribe: ipr-wg-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/ipr-wg/index.html Description of Working Group: The IETF and the Internet have greatly benefited from the free exchange of ideas and technology. For many years the IETF normal behavior was to standardize only unencumbered technology. While the "Tao" of the IETF is still strongly oriented toward unencumbered technology, we can and do make use of technology that has various encumbrances. One of the goals of the IETF IPR policy has been to make it easier for the IETF to make use of encumbered technology when it made sense to do so. This group has attempted to clarify and update that IPR policy, resulting in RFC 3978, RFC 3979 and RFC 3905. The WG has also discussed the possibility of changing the IETF's patent policy, but did not detect a consensus for doing so. At the time of this recharter (February 2006), there are two remaining items of work for the WG: - An issue with the production of derivative works has led to the realization that RFC 2026 and RFC 3978 do not specify exactly the same policy on this matter, and that neither policy, when read literally, may be optimal for the IETF's purpose, in accordance with its mission statement (RFC 3935), its policy of retaining change control of its own documents, and its desire for its documents to be openly available and useful. - The creation of the IETF Trust for managing the IETF IPR has led to the question of how the Trustees should evaluate the benefit of the IETF community as a whole and if necessary the consensus of the IETF on a given matter. Specifically the question arises whether the previous discussions of the IPR WG have led to experience that should be codified for the guidance of the Trustees. The WG will produce 3 documents: - An update to RFC 3978 (BCP) that attempts to specify a complete set of rights with respect to derivative works granted to the IETF by authors, as well as technical updates necessitated by the existence of the Trust - A document (info) giving advice to the IETF Trust on what rights in IETF contributions it should attempt to grant to the public in order to retain change control while allowing open access, resolving the discrepancy between RFC 2026 and RFC 3978 - A document (info) giving other advice to the IETF Trust on IPR handling, based on the IPR WG's experience of discussions in the area The last document may include advice to the IETF Trust on mechanisms for consulting with the community on IPR issues once the IPR WG has closed, if consensus on such advice can be found. The IPR WG may decide to drop the last document from its charter if it decides that it has nothing to say. All documents should have an IETF-wide Last Call before being approved. Description of Working Group: The IETF and the Internet have greatly benefited from the free exchange of ideas and technology. For many years the IETF normal behavior was to standardize only unencumbered technology. While the "Tao" of the IETF is still strongly oriented toward unencumbered technology, we can and do make use of technology that has various encumbrances. One of the goals of the IETF IPR policy has been to make it easier for the IETF to make use of encumbered technology when it made sense to do so. This group has attempted to clarify and update that IPR policy, resulting in RFC 3978, RFC 3979 and RFC 3905. The WG has also discussed the possibility of changing the IETF's patent policy, but did not detect a consensus for doing so. At the time of this recharter (February 2006), there are two remaining items of work for the WG: - An issue with the production of derivative works has led to the realization that RFC 2026 and RFC 3978 do not specify exactly the same policy on this matter, and that neither policy, when read literally, may be optimal for the IETF's purpose, in accordance with its mission statement (RFC 3935), its policy of retaining change control of its own documents, and its desire for its documents to be openly available and useful. - The creation of the IETF Trust for managing the IETF IPR has led to the question of how the Trustees should evaluate the benefit of the IETF community as a whole and if necessary the consensus of the IETF on a given matter. Specifically the question arises whether the previous discussions of the IPR WG have led to experience that should be codified for the guidance of the Trustees. The WG will produce 3 documents: - An update to RFC 3978 (BCP) that attempts to specify a complete set of rights with respect to derivative works granted to the IETF by authors, as well as technical updates necessitated by the existence of the Trust - A document (info) giving advice to the IETF Trust on what rights in IETF contributions it should attempt to grant to the public in order to retain change control while allowing open access, resolving the discrepancy between RFC 2026 and RFC 3978 - A document (info) giving other advice to the IETF Trust on IPR handling, based on the IPR WG's experience of discussions in the area The last document may include advice to the IETF Trust on mechanisms for consulting with the community on IPR issues once the IPR WG has closed, if consensus on such advice can be found. The IPR WG may decide to drop the last document from its charter if it decides that it has nothing to say. All documents should have an IETF-wide Last Call before being approved. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2006 Jan 2007 Advice to the IAOC on Rights to be Granted in IETF Documents Oct 2006 Oct 2006 Clarification of the 3rd Party Disclosure procedure in RFC 3979 Mar 2007 Mar 2007 Rights Contributions provide to the IETF Trust Access Node Control Protocol (ancp) ----------------------------------- Charter Last Modified: 2006-12-15 Current Status: Active Working Group Chair(s): Matthew Bocci Wojciech Dec Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Technical Advisor(s): Dan Romascanu Mailing Lists: General Discussion:ancp@ietf.org To Subscribe: ancp-request@ietf.org In Body: In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/ancp/index.html Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates acess loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM) Network Access Server (NAS) - Network device which aggregates multiplexedSubscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subsciber policy enforcement and QoS. Often referred to as an Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS, over a DSL access and aggregation network. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of DSL access and aggregation networks. Security: The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalabilty: A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables: The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so the the management framewoirk and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM work, and with IEEE 802.1ag. Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates acess loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM) Network Access Server (NAS) - Network device which aggregates multiplexedSubscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subsciber policy enforcement and QoS. Often referred to as an Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS, over a DSL access and aggregation network. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of DSL access and aggregation networks. Security: The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalabilty: A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables: The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so the the management framewoirk and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM work, and with IEEE 802.1ag. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Oct 2006 Feb 2007 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Jan 2007 Jan 2007 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Mar 2007 Mar 2007 Protocol for Access Node Control Mechanism in Broadband Networks Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Charter Last Modified: 2006-12-18 Current Status: Active Working Group Chair(s): Thomas Clausen Shubhranshu Singh Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:autoconf@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/autoconf Archive: http://www.ietf.org/mail-archive/web/autoconf/current/index.html Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, a MANET presents itself as a L3 multi-hop network formed over a collection of links. Thus, each ad hoc node in the MANET is, potentially, acting as a L3 router in order to provide connectivity to other nodes within the MANET. Each ad hoc node maintains host routes to other ad hoc nodes within the MANET - in addition to network routes to destinations outside the MANET. If connected to the Internet, MANETs are edge networks, i.e. their boundary is defined by their edge routers. Due to the nature of the links over which a MANET is formed, ad hoc nodes within a MANET do not share access to a single multicast-capable link for signaling. This implies that the usual delivery semantics of link-local multicast and broadcast are not preserved within a MANET. The address autoconfiguration related protocol specifications such as RFCs 2462, 2461, as used in traditional IP networks, assume that subnet-local signals (e.g. link-local multicast signals) are received by each of the hosts on the particular subnet without being forwarded by the routers defining the subnet boundary. Hence, ad hoc networks (as defined and understood by the IETF MANET WG) cannot use these protocol specifications as-is. The main purpose of the AUTOCONF WG is to standardize mechanisms to be used by ad hoc nodes for configuring unique local and/or globally routable IPv6 addresses. The ad hoc nodes under consideration are, once configured, expected to be able to support multi-hop communication by running MANET routing protocols as developed by the IETF MANET WG. An AUTOCONF mechanism should not be dependent on any specific MANET routing protocol, however the routing protocol may provide for optimizations. With this in mind, the goals of AUTOCONF WG are to: - Produce a "MANET architecture" document defining the MANET architecture as is related to IP networks and the Internet. - Produce a "terminology and problem statement" document, defining the problem statement and goals for AUTOCONF. - Develop an IPv6 address autoconfiguration mechanism to be used by ad hoc nodes for configuring unique local addresses as well as, in cases where Internet connectivity exists, globally routable unique addresses. - Develop a mechanism to promote configured address uniqueness in the situation where different ad hoc networks merge. Issues and requirements related to prefix and/or address providing entities, such as an Internet gateway, will be addressed within the group to the extent that they are directly related to the AUTOCONF mechanisms. Security concerns related to AUTOCONF mechanisms will also be discussed within the group. The working group will reuse existing specifications whenever reasonable and possible. Description of Working Group: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. From the IP layer perspective, a MANET presents itself as a L3 multi-hop network formed over a collection of links. Thus, each ad hoc node in the MANET is, potentially, acting as a L3 router in order to provide connectivity to other nodes within the MANET. Each ad hoc node maintains host routes to other ad hoc nodes within the MANET - in addition to network routes to destinations outside the MANET. If connected to the Internet, MANETs are edge networks, i.e. their boundary is defined by their edge routers. Due to the nature of the links over which a MANET is formed, ad hoc nodes within a MANET do not share access to a single multicast-capable link for signaling. This implies that the usual delivery semantics of link-local multicast and broadcast are not preserved within a MANET. The address autoconfiguration related protocol specifications such as RFCs 2462, 2461, as used in traditional IP networks, assume that subnet-local signals (e.g. link-local multicast signals) are received by each of the hosts on the particular subnet without being forwarded by the routers defining the subnet boundary. Hence, ad hoc networks (as defined and understood by the IETF MANET WG) cannot use these protocol specifications as-is. The main purpose of the AUTOCONF WG is to standardize mechanisms to be used by ad hoc nodes for configuring unique local and/or globally routable IPv6 addresses. The ad hoc nodes under consideration are, once configured, expected to be able to support multi-hop communication by running MANET routing protocols as developed by the IETF MANET WG. An AUTOCONF mechanism should not be dependent on any specific MANET routing protocol, however the routing protocol may provide for optimizations. With this in mind, the goals of AUTOCONF WG are to: - Produce a "MANET architecture" document defining the MANET architecture as is related to IP networks and the Internet. - Produce a "terminology and problem statement" document, defining the problem statement and goals for AUTOCONF. - Develop an IPv6 address autoconfiguration mechanism to be used by ad hoc nodes for configuring unique local addresses as well as, in cases where Internet connectivity exists, globally routable unique addresses. - Develop a mechanism to promote configured address uniqueness in the situation where different ad hoc networks merge. Issues and requirements related to prefix and/or address providing entities, such as an Internet gateway, will be addressed within the group to the extent that they are directly related to the AUTOCONF mechanisms. Security concerns related to AUTOCONF mechanisms will also be discussed within the group. The working group will reuse existing specifications whenever reasonable and possible. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Feb 2007 Mar 2007 Mobile Ad hoc Network Architecture Detecting Network Attachment (dna) ---------------------------------- Charter Last Modified: 2006-09-07 Current Status: Active Working Group Chair(s): Greg Daley Suresh Krishnan Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:dna@eng.monash.edu.au To Subscribe: majordomo@ecselists.eng.monash.edu.au In Body: subscribe dna Archive: http://ecselists.eng.monash.edu.au/~warchive/dna/ Description of Working Group: When an IPv6 node detects or suspects that its underlying link layer (L2) connectivity has or may have undergone a change, it needs to check whether its IP layer (L3) addressing and routing configurations are still valid or have changed. In the case that the L3 connectivity has changed, the node needs to reconfigure and may need to initiate mobility procedures, such as sending Mobile IP binding updates. Changes in an L2 connection do not necessarily mean that there has been change in L3 connectivity. For the purposes of detecting network attachment, an L3 link is defined as the topological range within which IP packets may be sent without resorting to forwarding. In other words, a link is the range where a given IP configuration is valid. In IPv6, the IP layer configuration information includes the set of valid unicast addresses[RFC 2462, RFC 3315], the Duplicate Address Detection (DAD) status of the addresses[RFC 2462], valid routing prefixes[RFC 2461], set of default routers[RFC 2461], neighbor and destination caches[RFC 2461], multicast listener (MLD) state[RFC 2710]. The current IPv6 stateless and stateful autoconfiguration procedures may take a fairly long time due to delays associated with Router Discovery and Duplicate Address Detection. The main goal of this WG is to develop mechanisms that reduce or avoid such delays, in cases where they are not necessary. For example if an interface comes back up after having been down momentarily, it can be quicker to verify that one is still attached to the same link than rerunning the full reconfiguration as if one were connecting to a new L3 link and had no previous configuration information cached. In some wireless technologies, the link layer state and events may not give an accurate indication of whether or not the IP addressing configuration and routability have changed. For example, a host may be able to see a base station but still be unable to deliver or receive IP packets within the L3 link. Moreover, a hardware indication that a radio link is up does not necessarily mean that all link layer configuration, such as authentication or virtual LAN connectivity has been completed. Therefore detecting network attachment requires not only change detection but IP layer connectivity testing. The purpose of the DNA working group is to define standards track and BCP documents that allow hosts to detect their IP layer configuration and connectivity status quickly, proposing some optimization to the current specifications that would allow a host to reconfigure its IPv6 layer faster than today. The group will define a set of goals for detecting network attachment, describing existing issues and important properties of potential solutions. The working group will describe best current practice for nodes making use of existing information for detecting network attachment. The working group will define a set of extensions to the current IPv6 configuration protocols [RFC 2461, 2462, possibly RFC 3315] that allow the nodes to discover whether L3 configuration or connectivity may have changed more reliably and easily than today. Initiation of L3 link change detection procedures can be achieved either through reception (or lack of reception) of messages at the IP layer or through indications from other layers. The working group will produce an informational document that contains a catalogue of the indications currently available from a subset of wireless link layer technologies. The DNA WG will not define new procedures or APIs related to link layers. Documents * Define goals for detecting network attachment in IPv6 (Informational). * Specify recommendations for detecting network attachment and L3 link change in IPv6 networks (BCP). * Define a protocol extension for detecting network attachment and L3 link change in IPv6 networks more reliably and easily (Standards Track). * Document existing link layer (L2) information which is useful to start detecting network attachment (Informational). Description of Working Group: When an IPv6 node detects or suspects that its underlying link layer (L2) connectivity has or may have undergone a change, it needs to check whether its IP layer (L3) addressing and routing configurations are still valid or have changed. In the case that the L3 connectivity has changed, the node needs to reconfigure and may need to initiate mobility procedures, such as sending Mobile IP binding updates. Changes in an L2 connection do not necessarily mean that there has been change in L3 connectivity. For the purposes of detecting network attachment, an L3 link is defined as the topological range within which IP packets may be sent without resorting to forwarding. In other words, a link is the range where a given IP configuration is valid. In IPv6, the IP layer configuration information includes the set of valid unicast addresses[RFC 2462, RFC 3315], the Duplicate Address Detection (DAD) status of the addresses[RFC 2462], valid routing prefixes[RFC 2461], set of default routers[RFC 2461], neighbor and destination caches[RFC 2461], multicast listener (MLD) state[RFC 2710]. The current IPv6 stateless and stateful autoconfiguration procedures may take a fairly long time due to delays associated with Router Discovery and Duplicate Address Detection. The main goal of this WG is to develop mechanisms that reduce or avoid such delays, in cases where they are not necessary. For example if an interface comes back up after having been down momentarily, it can be quicker to verify that one is still attached to the same link than rerunning the full reconfiguration as if one were connecting to a new L3 link and had no previous configuration information cached. In some wireless technologies, the link layer state and events may not give an accurate indication of whether or not the IP addressing configuration and routability have changed. For example, a host may be able to see a base station but still be unable to deliver or receive IP packets within the L3 link. Moreover, a hardware indication that a radio link is up does not necessarily mean that all link layer configuration, such as authentication or virtual LAN connectivity has been completed. Therefore detecting network attachment requires not only change detection but IP layer connectivity testing. The purpose of the DNA working group is to define standards track and BCP documents that allow hosts to detect their IP layer configuration and connectivity status quickly, proposing some optimization to the current specifications that would allow a host to reconfigure its IPv6 layer faster than today. The group will define a set of goals for detecting network attachment, describing existing issues and important properties of potential solutions. The working group will describe best current practice for nodes making use of existing information for detecting network attachment. The working group will define a set of extensions to the current IPv6 configuration protocols [RFC 2461, 2462, possibly RFC 3315] that allow the nodes to discover whether L3 configuration or connectivity may have changed more reliably and easily than today. Initiation of L3 link change detection procedures can be achieved either through reception (or lack of reception) of messages at the IP layer or through indications from other layers. The working group will produce an informational document that contains a catalogue of the indications currently available from a subset of wireless link layer technologies. The DNA WG will not define new procedures or APIs related to link layers. Documents * Define goals for detecting network attachment in IPv6 (Informational). * Specify recommendations for detecting network attachment and L3 link change in IPv6 networks (BCP). * Define a protocol extension for detecting network attachment and L3 link change in IPv6 networks more reliably and easily (Standards Track). * Document existing link layer (L2) information which is useful to start detecting network attachment (Informational). Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Sep 2004 Feb 2007 Link-layer Event Notifications for Detecting Network Attachments Feb 2006 Mar 2007 Detecting Network Attachment in IPv6 Networks (DNAv6) DNS Extensions (dnsext) ----------------------- Charter Last Modified: 2007-01-31 Current Status: Active Working Group Chair(s): Olafur Gudmundsson Olaf Kolkman Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Mark Townsley Mailing Lists: General Discussion:namedroppers@ops.ietf.org To Subscribe: namedroppers-request@ops.ietf.org Archive: http://ops.ietf.org/lists/namedroppers/ Description of Working Group: DNS was originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are DNS protocol issues, including the specification of message formats, message handling, and data formats used for DNS client-server and server-server communication. This WG is focused on advancing the zone transfer, update, notify and DNSSECbis documents to Draft standard. The WG works on solutions for DNSSEC deployment issues that may require protocol modifications. Two of these issues are identified and are worked on under the umbrella of this WG. 1] (a) method(s) to prevent the possibility of trivial zone enumeration and 2] a method for automated rollover of trust-anchors configured in validating resolvers. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of scope for this Working Group. These issues are considered in other venues, such as the DNS Operations Working Group. The DNSEXT Working Group sometimes uses an additional mailing list for discussion of DNS Security related issues. This list is open to all Discussion: dnssec@cafax.se To Subscribe: dnssec-request@cafax.se Archive: http://www.cafax.se/dnssec/ and ftp://ftp.cafax.se/pub/archives/dnssec.list The 2535bis document set was edited by a team. This team was chartered with making editorial changes only, with all substantiative changes discussed on the WG list. The archive of this editors-only mailing list is available at: http://www.east.isi.edu/projects/DNSSEC Specific work items are: o Advance the DNSSECbis document set through the standards process. o Clarification of RFC1034/1035 relating to DNSEXT ongoing work. + Clarification of wildcard processing rules. o After the work items above have been completed the working group will continue on reviewing the following existing proposed standard and examine if there is a possibility to progress them on the standards track. + RFC1995 (IXFR) to Draft standard. + RFC1996 (Notify) to Draft standard. + RFC2136bis (Dynamic Update) to Draft Standard. + RFC2181 (Clarify) to IESG for advancement to Draft Standard. + RFC2308 (Neg Caching) to Draft Standard. + RFC2671 (EDNS0) to Draft Standard. + RFC2672 (DNAME) to Draft Standard, or revision. + RFC2845 (TSIG)to Draft standard. + RFC2930 (TKEY) to Draft standard. + RFC3007 (Secure Update) to Draft standard. + RFC3645 GSS/TSIG to Draft Standard + RFC3??? AXFR clarify to Draft Standard. o Identify (a) method(s) to prevent the possibility of trivial zone enumeration. o Define a method for automated rollover of trust-anchors configured in validating resolvers. o Foster the development of Link Local Multicast Name Resolution (LLMNR) standard. The WG has taken up this work since LLMNR it is very similar to the DNS protocol. LLMNR is targeted as proposed standard. The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks: o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions. Description of Working Group: DNS was originally specified in RFC's 1034 and 1035, with subsequent updates. Within the scope of this WG are DNS protocol issues, including the specification of message formats, message handling, and data formats used for DNS client-server and server-server communication. This WG is focused on advancing the zone transfer, update, notify and DNSSECbis documents to Draft standard. The WG works on solutions for DNSSEC deployment issues that may require protocol modifications. Two of these issues are identified and are worked on under the umbrella of this WG. 1] (a) method(s) to prevent the possibility of trivial zone enumeration and 2] a method for automated rollover of trust-anchors configured in validating resolvers. Issues surrounding the operation of DNS, recommendations concerning the configuration of DNS servers, and other issues with the use of the protocol are out of scope for this Working Group. These issues are considered in other venues, such as the DNS Operations Working Group. The DNSEXT Working Group sometimes uses an additional mailing list for discussion of DNS Security related issues. This list is open to all Discussion: dnssec@cafax.se To Subscribe: dnssec-request@cafax.se Archive: http://www.cafax.se/dnssec/ and ftp://ftp.cafax.se/pub/archives/dnssec.list The 2535bis document set was edited by a team. This team was chartered with making editorial changes only, with all substantiative changes discussed on the WG list. The archive of this editors-only mailing list is available at: http://www.east.isi.edu/projects/DNSSEC Specific work items are: o Advance the DNSSECbis document set through the standards process. o Clarification of RFC1034/1035 relating to DNSEXT ongoing work. + Clarification of wildcard processing rules. o After the work items above have been completed the working group will continue on reviewing the following existing proposed standard and examine if there is a possibility to progress them on the standards track. + RFC1995 (IXFR) to Draft standard. + RFC1996 (Notify) to Draft standard. + RFC2136bis (Dynamic Update) to Draft Standard. + RFC2181 (Clarify) to IESG for advancement to Draft Standard. + RFC2308 (Neg Caching) to Draft Standard. + RFC2671 (EDNS0) to Draft Standard. + RFC2672 (DNAME) to Draft Standard, or revision. + RFC2845 (TSIG)to Draft standard. + RFC2930 (TKEY) to Draft standard. + RFC3007 (Secure Update) to Draft standard. + RFC3645 GSS/TSIG to Draft Standard + RFC3??? AXFR clarify to Draft Standard. o Identify (a) method(s) to prevent the possibility of trivial zone enumeration. o Define a method for automated rollover of trust-anchors configured in validating resolvers. o Foster the development of Link Local Multicast Name Resolution (LLMNR) standard. The WG has taken up this work since LLMNR it is very similar to the DNS protocol. LLMNR is targeted as proposed standard. The lifetime of the group is set by the work items above but while these are ongoing the working group has additional tasks: o Reviewing and providing recommendations about the specification, by other working groups, of RR types that do not require any special processing and that do not require any special naming conventions. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2001 Jun 2006 DNSSEC Opt-In Jul 2001 Oct 2006 DSA Keying and Signature Information in the DNS Jul 2001 Oct 2006 Storage of Diffie-Hellman Keying Information in the DNS Jul 2001 Mar 2007 Elliptic Curve Keys and Signatures in the Domain Name System (DNS) Oct 2004 Nov 2006 Automated Updates of DNSSEC Trust Anchors Jan 2005 Mar 2007 DNSSEC Hashed Authenticated Denial of Existence Feb 2005 Apr 2006 DNSSEC Experiments May 2005 Mar 2007 Clarifications and Implementation Notes for DNSSECbis Jul 2005 Dec 2006 Domain Name System (DNS) IANA Considerations Sep 2005 Jun 2006 DNS Name Server Identifier Option (NSID) Feb 2006 Nov 2006 Requirements related to DNSSEC Trust Anchor Rollover Sep 2006 Jan 2007 Update to DNAME Redirection in the DNS Jan 2007 Jan 2007 Measures for making DNS more resilient against forged answers Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2006-03-30 Current Status: Active Working Group Chair(s): Ralph Droms Stig Venaas Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:dhcwg@ietf.org To Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg Archive: http://www.ietf.org/mail-archive/web/dhcwg/index.html Description of Working Group: The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * Address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through DHCPFORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC 2131, RFC 2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG. * Assess the requirements for informing DHCPv6 clients of changes in configuration information. The DHCPv6 specification in RFC 3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6" and is specified in RFC 3736. RFC 3315 includes no provision for notifying DHCPv6 clients using stateless DHCPv6 of changes in the configuration information supplied to the client or any recommendations as to when a client should obtain possibly updated information. The DHC WG will evaluate solutions for informing DHCPv6 clients of changes in configuration information and select a solution that will be developed and published by the WG. Description of Working Group: The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications. The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option. The DHC WG has the following main objectives: * Address security in DHCP o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include: - Improved key management and scalability - Security for messages passed between relay agents and servers - Threats of DoS attacks through DHCPFORCERENEW - The increased usage of DHC on unsecured (e.g., wireless) and public LANs - The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server. o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP * Write an analysis of the DHCP specification, including RFC 2131, RFC 2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification. * Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG. * Assess the requirements for informing DHCPv6 clients of changes in configuration information. The DHCPv6 specification in RFC 3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6" and is specified in RFC 3736. RFC 3315 includes no provision for notifying DHCPv6 clients using stateless DHCPv6 of changes in the configuration information supplied to the client or any recommendations as to when a client should obtain possibly updated information. The DHC WG will evaluate solutions for informing DHCPv6 clients of changes in configuration information and select a solution that will be developed and published by the WG. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jul 2001 Mar 2007 Virtual Subnet Selection Sub-Option for the Relay Agent Information Option for DHCPv4 Feb 2003 Oct 2006 DHCP Server Identifier Override Suboption Feb 2003 Oct 2006 Subnet Allocation Option Oct 2005 Dec 2006 DHCP options for PANA Authentication Agents Oct 2005 Dec 2006 Domain Suffix Option for DHCPv6 Jan 2006 Nov 2006 DHCPv6 Relay Agent Assignment Notificati