calsify crisp eai lemonade httpbis idnabis ltru sieve usefor vcarddav ipr ancp autoconf csi dna dnsext dhc hip ipdvb 16ng iporpr 6man 6lowpan l2vpn l2tpext mext mipshop mip4 magma ntp netlmm pppext pana pwe3 shim6 softwire tictoc trill adslmib bmwg capwap dime dnsop grow imss ipfix ipcdn v6ops mboned netmod netconf opsec opsawg psamp pmol radext avt bliss xcon drinks ecrit geopriv iptel mediactrl mmusic p2psip sipping sip speermint sigtran simple speechsc enum bfd ccamp forces idr isis l1vpn l3vpn manet mpls ospf pce pim rtgwg roll rpsec sidr vrrp btns dkim emu hokey isms ipsecme krb-wg kitten ltans msec nea keyprov pkix smime syslog sasl tls behave pcn dccp fecframe ippm nfsv4 nsis rmt rserpool rohc tcpm tsvwg Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- Charter Last Modified: 2008-04-23 Current Status: Active Working Group Chair(s): Aki Niemi Eliot Lear Applications Area Director(s): Chris Newman 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 Jun 2008 iCalendar Message-Based Interoperability Protocol (iMIP) Oct 2005 Jul 2008 iCalendar Transport-Independent Interoperability Protocol (iTIP) Oct 2005 Feb 2008 Internet Calendaring and Scheduling Core Object Specification (iCalendar) Cross Registry Information Service Protocol (crisp) --------------------------------------------------- Charter Last Modified: 2007-03-29 Current Status: Active Working Group Chair(s): April Marine George Michaelson Applications Area Director(s): Chris Newman Lisa Dusseault Applications Area Advisor: Chris Newman 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: No Current Internet-Drafts. Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2008-04-23 Current Status: Active Working Group Chair(s): Harald Alvestrand XiaoDong Lee Applications Area Director(s): Chris Newman Lisa Dusseault Applications Area Advisor: Chris Newman 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 specificatio n 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 specificatio n 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 Jul 2008 SMTP extension for internationalized email address May 2006 Jan 2008 UTF-8 Mail: Scenarios May 2006 Jul 2008 Downgrading mechanism for Email Address Internationalization May 2006 Apr 2008 IMAP Support for UTF-8 Jun 2006 Jul 2008 Internationalized Email Headers Jun 2006 Feb 2008 Mailing Lists and Internationalized Email Addresses Jun 2006 Jul 2008 POP3 Support for UTF-8 Jan 2007 Jan 2008 Internationalized Delivery Status and Disposition Notifications Feb 2008 Feb 2008 An update to the mailto URI scheme for Email Address Internationalization Enhancements to Internet email to Support Diverse Service Environments (lemonade) --------------------------------------------------------------------------------- Charter Last Modified: 2008-07-21 Current Status: Active Working Group Chair(s): Glenn Parsons Eric Burger Applications Area Director(s): Chris Newman Lisa Dusseault Applications Area Advisor: Chris Newman Secretary(ies): Alexey Melnikov 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 ------ ------- -------------------------------------------- Dec 2005 Feb 2008 Support for Sieve in Internet Message Access Protocol (IMAP4) Jan 2006 Jul 2008 Lemonade Notifications Architecture Jan 2006 Jul 2008 The Lemonade Profile Mar 2006 Jun 2007 Deployment Considerations for lemonade-compliant Mobile Email Jun 2006 Jul 2008 Internet Message Store Events Jun 2006 Jun 2008 Streaming Internet Messaging Attachments Sep 2006 Jul 2008 IMAP4 extension for named searches (filters) Aug 2007 Jun 2008 The IMAP NOTIFY Extension Nov 2007 Jul 2008 LEMONADE Architecture - Supporting OMA Mobile Email (MEM) using Internet Mail Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- Charter Last Modified: 2007-12-26 Current Status: Active Working Group Chair(s): Mark Nottingham Applications Area Director(s): Chris Newman Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:ietf-http-wg@w3.org To Subscribe: http://lists.w3.org/Archives/Public/ietf-http-wg/ Archive: Description of Working Group: HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated echanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic The Working Group's specification deliverables are: * A document that is suitable to supersede RFC 2616 * A document cataloguing the security properties of HTTP Description of Working Group: HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated echanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic The Working Group's specification deliverables are: * A document that is suitable to supersede RFC 2616 * A document cataloguing the security properties of HTTP Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Dec 2007 Jun 2008 HTTP/1.1, part 1: URIs, Connections, and Message Parsing Dec 2007 Jun 2008 HTTP/1.1, part 2: Message Semantics Dec 2007 Jun 2008 HTTP/1.1, part 3: Message Payload and Content Negotiation Dec 2007 Jun 2008 HTTP/1.1, part 4: Conditional Requests Dec 2007 Jun 2008 HTTP/1.1, part 5: Range Requests and Partial Responses Dec 2007 Jun 2008 HTTP/1.1, part 6: Caching Dec 2007 Jun 2008 HTTP/1.1, part 7: Authentication Jan 2008 Jul 2008 Security Requirements for HTTP Internationalized Domain Names in Applications (Revised) (idnabis) ------------------------------------------------------------------ Charter Last Modified: 2008-04-15 Current Status: Active Working Group Chair(s): Vinton Cerf Applications Area Director(s): Chris Newman Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion:idna-update@alvestrand.no To Subscribe: http://www.alvestrand.no/mailman/listinfo/idna-update Archive: http://www.alvestrand.no/pipermail/idna-update/ Description of Working Group: The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen (?-?) in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as ?IDNA2003?). These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified. This WG is chartered to decouple IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time (insertion of names into DNS zone files), vs. at resolution time (looking up those names) - Review, and if necessary revise, the algorithms and rules for handling right to left character sequences in an IDN context to allow labels based on additional scripts and languages and to make presentation as predictable as reasonably possible. - Permit use of some scripts that were inadvertently excluded by the original protocols. - Ensure practical stability of validity algorithms for IDNs. The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The specifications are initially organized as four documents: overview and rationale, protocol, table algorithm, and improvements to the bidirectional algorithm. These documents are to be used as the basis for the discussion of the general direction of the work. This working group will be providing extended public review of the output of a design team that has been working on improvement of the IDNA specifications. This review-based approach is being used in part because of the way the work was undertaken by the team; in particular, the design team has been working with IETF visibility and has solicited and received significant amounts of technical review already from IETF participants and from others including experts in the Unicode specifications and the use of scripts in languages. If the public review provided by this Working Group confirms the basic method outlined in the input documents, it is expected that the working group will be able to respond with any needed changes and close in a short period of time. If technical issues arise that indicate a fundamentally different approach must be taken from the one outlined above, it is anticipated that this working group would close, and a new one with an appropriate charter would be considered. This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers. There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the "phishing" problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes. While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work. The work will update or obsolete RFC 3490. It is not expected to continue to use Nameprep (RFC 3491). Nameprep is used by other specifications; determining how (or whether) to update those specifications and, consequently, the long-term status of Nameprep, are not part of this effort. The method for ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC 3492) will not be revised by this WG. Subject to the more general constraints described above, the WG is permitted to consider changes that are not strictly backwards-compatible. For any such change that is recommended, it is expected to document the reasons for the change, the characters affected, and possible transition strategies. The assumptions outlined above are considered critical to the WG constituted by this charter. The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: (i) A change to the "punycode" algorithm or to the ACE approach to encoding names in the DNS. (ii) A change to the ACE prefix from "xn--" (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and elimination of character mapping in the protocol) Description of Working Group: The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen (?-?) in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as ?IDNA2003?). These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified. This WG is chartered to decouple IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time (insertion of names into DNS zone files), vs. at resolution time (looking up those names) - Review, and if necessary revise, the algorithms and rules for handling right to left character sequences in an IDN context to allow labels based on additional scripts and languages and to make presentation as predictable as reasonably possible. - Permit use of some scripts that were inadvertently excluded by the original protocols. - Ensure practical stability of validity algorithms for IDNs. The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the "xn--" prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The specifications are initially organized as four documents: overview and rationale, protocol, table algorithm, and improvements to the bidirectional algorithm. These documents are to be used as the basis for the discussion of the general direction of the work. This working group will be providing extended public review of the output of a design team that has been working on improvement of the IDNA specifications. This review-based approach is being used in part because of the way the work was undertaken by the team; in particular, the design team has been working with IETF visibility and has solicited and received significant amounts of technical review already from IETF participants and from others including experts in the Unicode specifications and the use of scripts in languages. If the public review provided by this Working Group confirms the basic method outlined in the input documents, it is expected that the working group will be able to respond with any needed changes and close in a short period of time. If technical issues arise that indicate a fundamentally different approach must be taken from the one outlined above, it is anticipated that this working group would close, and a new one with an appropriate charter would be considered. This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers. There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the "phishing" problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes. While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work. The work will update or obsolete RFC 3490. It is not expected to continue to use Nameprep (RFC 3491). Nameprep is used by other specifications; determining how (or whether) to update those specifications and, consequently, the long-term status of Nameprep, are not part of this effort. The method for ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC 3492) will not be revised by this WG. Subject to the more general constraints described above, the WG is permitted to consider changes that are not strictly backwards-compatible. For any such change that is recommended, it is expected to document the reasons for the change, the characters affected, and possible transition strategies. The assumptions outlined above are considered critical to the WG constituted by this charter. The WG will stop work and recommend that a new charter be generated if it concludes that any of the following are necessary to meet its goals: (i) A change to the "punycode" algorithm or to the ACE approach to encoding names in the DNS. (ii) A change to the ACE prefix from "xn--" (iii) A change to the basic approach taken in the design team documents (Namely: independence from Unicode version and elimination of character mapping in the protocol) Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Apr 2008 Jul 2008 The Unicode Codepoints and IDNA May 2008 Jul 2008 Internationalized Domain Names for Applications (IDNA): Definitions, Background and Rationale May 2008 Jul 2008 Internationalized Domain Names in Applications (IDNA): Protocol May 2008 Jul 2008 An updated IDNA criterion for right-to-left scripts Language Tag Registry Update (ltru) ----------------------------------- Charter Last Modified: 2008-01-21 Current Status: Active Working Group Chair(s): Randy Presuhn Martin Duerst Applications Area Director(s): Chris Newman Lisa Dusseault Applications Area Advisor: Chris Newman 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 Jul 2008 Tags for Identifying Languages Sep 2006 May 2008 Update to the Language Subtag Registry Sieve Mail Filtering Language (sieve) ------------------------------------- Charter Last Modified: 2008-06-19 Current Status: Active Working Group Chair(s): Cyrus Daboo Alexey Melnikov Applications Area Director(s): Chris Newman 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 ------ ------- -------------------------------------------- Feb 2005 Mar 2008 Sieve Email Filtering: Editheader Extension May 2005 May 2008 Sieve Email Filtering: Reject and Extended Reject Extensions Sep 2005 Dec 2007 SIEVE Email Filtering: Extension for Notifications Dec 2005 Jul 2008 Sieve Notification Mechanism: mailto Jan 2006 Feb 2008 Sieve Notification Mechanism: xmpp Mar 2006 Jul 2008 Sieve Email Filtering: MIME part Tests, Iteration, Extraction, Replacement and Enclosure Usenet Article Standard Update (usefor) --------------------------------------- Charter Last Modified: 2007-02-13 Current Status: Active Working Group Chair(s): Alexey Melnikov Harald Alvestrand Applications Area Director(s): Chris Newman 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 vCard and CardDAV (vcarddav) ---------------------------- Charter Last Modified: 2008-04-22 Current Status: Active Working Group Chair(s): Kurt Zeilenga Marc Blanchet Applications Area Director(s): Chris Newman Lisa Dusseault Applications Area Advisor: Chris Newman Mailing Lists: General Discussion:vcarddav@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/vcarddav Archive: http://www1.ietf.org/pipermail/vcarddav Description of Working Group: A personal address book (PAB) contains a read/write copy of attributes describing a user's interpersonal contacts. This is distinct from a directory which contains a primarily read-only copy of users within an organization. While these two data objects share a large number of common attributes, their use and access patterns are fundamentally different. The IETF has a standards-track data format (vCard) which has been successfully used to interchange both personal-address-book and user directory entry data objects. However, due to the lack of a standard access control model for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB objects, and the different access patterns for PAB data (as opposed to directory data), the use of LDAP as an access protocol for PABs has had mixed results in practice. Moreover, the vCard format has been extended by many parties and the current specification is ambiguous for some objects. If the deployed protocols related to interpersonal communication are viewed as a component-based system, there are a number of points in the system that would benefit from a standards track access protocol for personal address book data. This includes: * Mail User Agents use PAB data to assist outgoing email addressing and may use vCard attachments to transport PAB data between users. * Calendar User Agents use PAB data to invite attendees to events * Instant Messaging User Agents can provide additional information about a user's buddies if they can be associated with a user's PAB entry. * A server-side Sieve engine with the spamtest/virustest extension would benefit from access to a user's PAB to provide per-user white list capabilities. * Various deployed challenge-response mechanisms for email present in Mail Transfer Agents, such as TMDA, would be improved by a PAB-based white list. * Mobile device synchronization software might be simplified by a single cross-platform PAB access protocol. * A voice conference or IP telephony system could access a user's PAB to provide name-based or nickname-based dialing. This WG will produce the following outputs: (1) A revision of the vCard specification (RFC2426) at proposed standard status. This revision shall include other vCard standardized extensions (RFC 2739, 4770) and extensions assisting synchronization technologies (for example, a per-entry UUID or per-attribute sequence number). Other extensions shall be considered either in the base specification or in additional documents. (2) An address book access protocol leveraging the vCard data format. The Internet-draft draft-daboo-carddav will be the starting point. The WG is explicitly cautioned to keep the base specification feature set small with an adequate extension mechanism, as failure to do so was a problem for previous PAB efforts (ACAP). The WG will consider arguments of the form "feature X must be in the base feature set because ..." with great skepticism. These documents will consider security implications carefully. The WG will consider developing a mechanism that provides the ability to check if an email address (or im address, etc) is in the user's PAB without providing unrestricted access to all of the user's PAB data. The WG should also consider developing a mechanism that allows the user to grant this limited permission to a third-party service (such as a server-based Sieve engine) for white-list purposes. Once the primary outputs are complete, the WG will consider the following secondary outputs: (3) An XML schema which is semantically identical to vCard in all ways and can be mechanically translated to and from vCard format without loss of data. While vCard has deployed successfully and will remain the preferred interchange format, a standard XML schema which preserves vCard semantics might make vCard data more accessible to XML- centric technologies such as AJAX and XSLT. Such a standard format would be preferable to multiple proprietary XML schemas, particularly if vCard semantics were lost by some of them and a lossy gateway problem resulted. (4) Identifying useful deployed vCard vendor extensions and creating standards track versions of those extensions. (5) Cooperate with the Sieve WG to produce a Sieve extension for address book Sieve tests. (6) LDAP mapping to the new vCard format without loss of data. Description of Working Group: A personal address book (PAB) contains a read/write copy of attributes describing a user's interpersonal contacts. This is distinct from a directory which contains a primarily read-only copy of users within an organization. While these two data objects share a large number of common attributes, their use and access patterns are fundamentally different. The IETF has a standards-track data format (vCard) which has been successfully used to interchange both personal-address-book and user directory entry data objects. However, due to the lack of a standard access control model for LDAP, the lack of a standard LDAP schema and DIT-model for vCard PAB objects, and the different access patterns for PAB data (as opposed to directory data), the use of LDAP as an access protocol for PABs has had mixed results in practice. Moreover, the vCard format has been extended by many parties and the current specification is ambiguous for some objects. If the deployed protocols related to interpersonal communication are viewed as a component-based system, there are a number of points in the system that would benefit from a standards track access protocol for personal address book data. This includes: * Mail User Agents use PAB data to assist outgoing email addressing and may use vCard attachments to transport PAB data between users. * Calendar User Agents use PAB data to invite attendees to events * Instant Messaging User Agents can provide additional information about a user's buddies if they can be associated with a user's PAB entry. * A server-side Sieve engine with the spamtest/virustest extension would benefit from access to a user's PAB to provide per-user white list capabilities. * Various deployed challenge-response mechanisms for email present in Mail Transfer Agents, such as TMDA, would be improved by a PAB-based white list. * Mobile device synchronization software might be simplified by a single cross-platform PAB access protocol. * A voice conference or IP telephony system could access a user's PAB to provide name-based or nickname-based dialing. This WG will produce the following outputs: (1) A revision of the vCard specification (RFC2426) at proposed standard status. This revision shall include other vCard standardized extensions (RFC 2739, 4770) and extensions assisting synchronization technologies (for example, a per-entry UUID or per-attribute sequence number). Other extensions shall be considered either in the base specification or in additional documents. (2) An address book access protocol leveraging the vCard data format. The Internet-draft draft-daboo-carddav will be the starting point. The WG is explicitly cautioned to keep the base specification feature set small with an adequate extension mechanism, as failure to do so was a problem for previous PAB efforts (ACAP). The WG will consider arguments of the form "feature X must be in the base feature set because ..." with great skepticism. These documents will consider security implications carefully. The WG will consider developing a mechanism that provides the ability to check if an email address (or im address, etc) is in the user's PAB without providing unrestricted access to all of the user's PAB data. The WG should also consider developing a mechanism that allows the user to grant this limited permission to a third-party service (such as a server-based Sieve engine) for white-list purposes. Once the primary outputs are complete, the WG will consider the following secondary outputs: (3) An XML schema which is semantically identical to vCard in all ways and can be mechanically translated to and from vCard format without loss of data. While vCard has deployed successfully and will remain the preferred interchange format, a standard XML schema which preserves vCard semantics might make vCard data more accessible to XML- centric technologies such as AJAX and XSLT. Such a standard format would be preferable to multiple proprietary XML schemas, particularly if vCard semantics were lost by some of them and a lossy gateway problem resulted. (4) Identifying useful deployed vCard vendor extensions and creating standards track versions of those extensions. (5) Cooperate with the Sieve WG to produce a Sieve extension for address book Sieve tests. (6) LDAP mapping to the new vCard format without loss of data. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2008 Jul 2008 vCard Format Specification May 2008 Jul 2008 vCard Extensions to WebDAV (CardDAV) May 2008 May 2008 Extended MKCOL for WebDAV Intellectual Property Rights (ipr) ---------------------------------- Charter Last Modified: 2007-07-23 Current Status: Active Working Group Chair(s): Harald Alvestrand General Area Director(s): Russ Housley General Area Advisor: Russ Housley 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 Jul 2008 Advice to the Trustees of the IETF Trust on Rights to be Granted in IETF Documents Mar 2007 May 2008 Rights Contributors provide to the IETF Trust Access Node Control Protocol (ancp) ----------------------------------- Charter Last Modified: 2008-06-04 Current Status: Active Working Group Chair(s): Wojciech Dec Matthew Bocci 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 May 2008 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Jan 2007 Apr 2008 Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Mar 2007 Jul 2008 Protocol for Access Node Control Mechanism in Broadband Networks Jun 2007 Jun 2008 Access Node Control Protocol (ANCP) MIB module for Access Nodes Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- Charter Last Modified: 2008-04-23 Current Status: Active Working Group Chair(s): Shubhranshu Singh Thomas Heide Clausen 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 Nov 2007 Mobile Ad hoc Network Architecture Jun 2007 Feb 2008 Address Autoconfiguration for MANET: Terminology and Problem Statement Cga & Send maIntenance (csi) ---------------------------- Charter Last Modified: 2008-04-23 Current Status: Active Working Group Chair(s): Marcelo Bagnulo Gabriel Montenegro Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion:cga-ext@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/cga-ext Archive: http://www.ietf.org/mail-archive/web/cga-ext/current/index.html Description of Working Group: The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 provides security mechanisms protecting different functions of the Neighbor Discovery (ND) protocol defined by RFC 2461. This includes address resolution (discovering link layer address of another node attached to the link), router discovery (discovering routers attached to the link), and neighbor unreachability detection (detecting that a node attached to the link is no longer reachable). SEND protection of address resolution and neighbor unreachability detection functions relies on IPv6 address proof-of-ownership and message integrity protection provided respectively via Cryptographically Generated Addresses (CGAs) and RSA Digital Signatures. CGAs are defined in RFC 3972, and are extended with a CGA extension format defined in RFC 4581, and a support for multiple hash functions defined in RFC 4982. While CGAs were originally defined for the SEND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. While there is very little deployment of SEND to date, there are a number of implementations, recommendations in the NIST and DOD profiles call for use of SEND, and operating system vendors are considering adding SEND to their next releases. As a result, it is desirable to review the current state of the SEND and CGA specifications, maintain and complement them where necessary. Up to date cryptographic algorithms are needed, and the protocols need to be able to deal with certain common situations currently not supported. Specifically, the WG will look at the following issues: - Develop an informational document analyzing the implications of recent attacks on hash functions used by SeND protocol. Current SeND specification uses the SHA-1 hash algorithm and does not provides support for hash algorithm agility, hence the critical need for understanding the impact of the attacks on the SeND protocol. In addition, if as a result of the aforementioned analysis it is deemed necessary, standard-track extensions to the SeND protocol to support multiple hash algorithms will be defined. - Specify a standards-track CGA and SeND extensions to support multiple public key algorithms. As currently defined CGA and SeND can only use RSA keys, and they lack support for other public key algorithms (e.g. Elliptic Curve Cryptography -- ECC). - Develop X.509 certificate management tools for SeND. SeND utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. Since the IP addresses extension does not explicitly mention what functions the node can perform for the IP addresses it becomes impossible to know the reason for which the certificate was allowed. In order to facilitate issuance of certificates for specific functions, we need to encode the functions permitted for the certificate into the certificate itself. The WG will develop a certificate profile, including a definition of X.509 Extended Key Usage for SeND . In addition, the WG will recommend best practices for (1) enrollment, (2) revocation checking, and (3) publishing of certificates. This WG will ensure that the profile and recommended practices will cover usage by hosts in addition to routers. The working group will coordinate this activity with the PKIX and SIDR WGs. Prior to IESG submission of the certificate profile, the working group will seek input from and coordinate with other groups enabling cryptographic identification of device-related properties (e.g., IEEE 802.1ar, IEEE 802.16, WiMAX Forum, IETF CAPWAP WG). - Develop a standard track document defining a mechanism to perform SeND certificate provisioning for routers. SeND protocol as defined in RFC3971 specifies how IPv6 nodes can trust the prefixes advertised by a router. The solution is based on the use of the IP Address Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280). This work will provide the tools require to provision with the certificates to the routers in an automatic manner. The working will coordinate this activity with the PKIX WG. - Produce a problem statement document for Neighbor Discovery Proxies and then specify standards-track SEND Extensions to support Neighbor Discovery Proxies: SEND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 3775 and RFC 4389. Extensions to the SEND protocol will be defined in order to provide equivalent SEND security capabilities to ND Proxies. - Develop an informational document analysing different approaches to allow SeND and CGAs to be used in conjunction with DHCP, and making recommendations on which are the best suited. Recharter based on the result of the analysis. - Update base specifications (RFC 3971 and 3972). Description of Working Group: The Secure Neighbor Discovery (SEND) protocol defined by RFC 3971 provides security mechanisms protecting different functions of the Neighbor Discovery (ND) protocol defined by RFC 2461. This includes address resolution (discovering link layer address of another node attached to the link), router discovery (discovering routers attached to the link), and neighbor unreachability detection (detecting that a node attached to the link is no longer reachable). SEND protection of address resolution and neighbor unreachability detection functions relies on IPv6 address proof-of-ownership and message integrity protection provided respectively via Cryptographically Generated Addresses (CGAs) and RSA Digital Signatures. CGAs are defined in RFC 3972, and are extended with a CGA extension format defined in RFC 4581, and a support for multiple hash functions defined in RFC 4982. While CGAs were originally defined for the SEND protocol, they have proved to be a useful security tool in other environments too, and its usage has been proposed to secure other protocols such as the Shim6 multihoming protocol and the Mobile IPv6 protocol. While there is very little deployment of SEND to date, there are a number of implementations, recommendations in the NIST and DOD profiles call for use of SEND, and operating system vendors are considering adding SEND to their next releases. As a result, it is desirable to review the current state of the SEND and CGA specifications, maintain and complement them where necessary. Up to date cryptographic algorithms are needed, and the protocols need to be able to deal with certain common situations currently not supported. Specifically, the WG will look at the following issues: - Develop an informational document analyzing the implications of recent attacks on hash functions used by SeND protocol. Current SeND specification uses the SHA-1 hash algorithm and does not provides support for hash algorithm agility, hence the critical need for understanding the impact of the attacks on the SeND protocol. In addition, if as a result of the aforementioned analysis it is deemed necessary, standard-track extensions to the SeND protocol to support multiple hash algorithms will be defined. - Specify a standards-track CGA and SeND extensions to support multiple public key algorithms. As currently defined CGA and SeND can only use RSA keys, and they lack support for other public key algorithms (e.g. Elliptic Curve Cryptography -- ECC). - Develop X.509 certificate management tools for SeND. SeND utilizes X.509v3 certificates for performing router authorization. It uses the X.509 extension for IP addresses to verify whether the router is authorized to advertise the mentioned IP addresses. Since the IP addresses extension does not explicitly mention what functions the node can perform for the IP addresses it becomes impossible to know the reason for which the certificate was allowed. In order to facilitate issuance of certificates for specific functions, we need to encode the functions permitted for the certificate into the certificate itself. The WG will develop a certificate profile, including a definition of X.509 Extended Key Usage for SeND . In addition, the WG will recommend best practices for (1) enrollment, (2) revocation checking, and (3) publishing of certificates. This WG will ensure that the profile and recommended practices will cover usage by hosts in addition to routers. The working group will coordinate this activity with the PKIX and SIDR WGs. Prior to IESG submission of the certificate profile, the working group will seek input from and coordinate with other groups enabling cryptographic identification of device-related properties (e.g., IEEE 802.1ar, IEEE 802.16, WiMAX Forum, IETF CAPWAP WG). - Develop a standard track document defining a mechanism to perform SeND certificate provisioning for routers. SeND protocol as defined in RFC3971 specifies how IPv6 nodes can trust the prefixes advertised by a router. The solution is based on the use of the IP Address Delegation extension (RFC3779) in X.509 v3 certificates (RFC3280). This work will provide the tools require to provision with the certificates to the routers in an automatic manner. The working will coordinate this activity with the PKIX WG. - Produce a problem statement document for Neighbor Discovery Proxies and then specify standards-track SEND Extensions to support Neighbor Discovery Proxies: SEND protocol as currently defined in RFC 3971 lacks of support for ND Proxies defined in RFC 3775 and RFC 4389. Extensions to the SEND protocol will be defined in order to provide equivalent SEND security capabilities to ND Proxies. - Develop an informational document analysing different approaches to allow SeND and CGAs to be used in conjunction with DHCP, and making recommendations on which are the best suited. Recharter based on the result of the analysis. - Update base specifications (RFC 3971 and 3972). Internet-Drafts: No Current Internet-Drafts. Detecting Network Attachment (dna) ---------------------------------- Charter Last Modified: 2008-04-23 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 ------ ------- -------------------------------------------- Feb 2006 Jul 2008 Design document for Detecting Network Attachment in IPv6 Networks (DNAv6 Design) Feb 2006 Jul 2008 Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery Apr 2008 Jul 2008 Simple procedures for Detecting Network Attachment in IPv6 DNS Extensions (dnsext) ----------------------- Charter Last Modified: 2008-06-16 Current Status: Active Working Group Chair(s): Olafur Gudmundsson Andrew Sullivan 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: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions, clarification to the DNS protocol, including DNSSEC, and review of DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working groups. Adoption of new DNSEXT standards track working group items will require changes to this charter. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. The DNSEXT WG will conduct the specified RFC2929bis review of RR templates as they are posted and also maintain a living ID of errata for the DNSSEC document set. Description of Working Group: The DNS has a large installed base and repertoire of protocol specifications. The DNSEXT WG group will actively advance DNS protocol-related RFCs on the standards track while thoroughly reviewing further proposed extensions. The scope of the DNSEXT WG is confined to the DNS protocol, particularly changes that affect DNS protocols "on the wire" or the internal processing of DNS data. DNS operations are out of scope for the WG. The WG will limit itself to review of proposals for new extensions, clarification to the DNS protocol, including DNSSEC, and review of DNS protocol related work which may originate elsewhere in the IETF, including AD-sponsored submissions or drafts in other working groups. Adoption of new DNSEXT standards track working group items will require changes to this charter. The WG does not intend to hold face to face meetings, though may do so if deemed necessary for resolution of a specific issue at hand. The DNSEXT WG will conduct the specified RFC2929bis review of RR templates as they are posted and also maintain a living ID of errata for the DNSSEC document set. Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Mar 2000 Jul 2008 DNS Zone Transfer Protocol (AXFR) Jun 2004 Jul 2008 Evaluating DNSSEC Transition Mechanisms May 2005 Jul 2008 Clarifications and Implementation Notes for DNSSECbis Jul 2005 Jul 2008 Domain Name System (DNS) IANA Considerations Feb 2006 Apr 2008 Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC Sep 2006 Jul 2008 Update to DNAME Redirection in the DNS Jan 2007 Jun 2008 Measures for making DNS more resilient against forged answers Dec 2007 Mar 2008 Revised extension mechanisms for DNS (EDNS0) Jan 2008 Jan 2008 The Modern DNS Implementation Guide Jun 2008 Jun 2008 Deprecation of HMAC-MD5 in DNS TSIG and TKEY Resource Records Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 2008-04-23 Current Status: Active Working Group Chair(s): Ralph Droms John Jason Brzozowski 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 o