Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)
draft-saintandre-impp-call-info-04
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-07-29
|
04 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-07-18
|
04 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-07-01
|
04 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-06-12
|
04 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-06-10
|
04 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-06-10
|
04 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-06-10
|
04 | (System) | IANA Action state changed to In Progress |
2013-06-07
|
04 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-06-07
|
04 | (System) | RFC Editor state changed to EDIT |
2013-06-07
|
04 | (System) | Announcement was received by RFC Editor |
2013-06-07
|
04 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-06-07
|
04 | Amy Vezza | IESG has approved the document |
2013-06-07
|
04 | Amy Vezza | Closed "Approve" ballot |
2013-06-07
|
04 | Amy Vezza | Ballot approval text was generated |
2013-06-07
|
04 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-05-31
|
04 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss |
2013-05-31
|
04 | Stephen Farrell | [Ballot comment] Thanks for considering my discuss point. S. |
2013-05-31
|
04 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-05-31
|
04 | Gonzalo Camarillo | Intended Status changed to Informational from Proposed Standard |
2013-05-30
|
04 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-05-30
|
04 | Peter Saint-Andre | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-05-30
|
04 | Peter Saint-Andre | New version available: draft-saintandre-impp-call-info-04.txt |
2013-05-30
|
03 | Cindy Morgan | State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2013-05-30
|
03 | Joel Jaeggli | [Ballot comment] no objection on the basis of the revised id that will be coming |
2013-05-30
|
03 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-05-30
|
03 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-05-30
|
03 | Stephen Farrell | [Ballot discuss] I think tihs is a relatively simple discuss. I think section 2 should mention privacy, e.g. say that "This specification provides a new … [Ballot discuss] I think tihs is a relatively simple discuss. I think section 2 should mention privacy, e.g. say that "This specification provides a new way to correlate otherwise possibly unconnected identifiers and doing so can be privacy sensitive. User agents SHOULD provide a means for users to control whether or not these values are sent." |
2013-05-30
|
03 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-05-29
|
03 | Richard Barnes | [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes |
2013-05-29
|
03 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-05-28
|
03 | Pete Resnick | [Ballot discuss] I'll clear this on Thursday, or before if there is a simple answer: Why is this PS instead of Informational? I can't figure … [Ballot discuss] I'll clear this on Thursday, or before if there is a simple answer: Why is this PS instead of Informational? I can't figure out how this could progress along the standards track, and I can't figure out what standard it's specifying. |
2013-05-28
|
03 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2013-05-28
|
03 | Spencer Dawkins | [Ballot comment] This is more for the RAI ADs than anything else (no action requested from the document authors). In 2. Security Considerations Advertising … [Ballot comment] This is more for the RAI ADs than anything else (no action requested from the document authors). In 2. Security Considerations Advertising an endpoint's XMPP address over SIP could inform malicious entities about an alternative attack vector. Because the "purpose" header field parameter could be spoofed, the receiving endpoint ought to check the value against an authoritative source such as a user directory. Clients can integrity protect and encrypt this header field using end-to-end mechanisms such as S/MIME or hop- by-hop mechanisms such as TLS. We're talking about a SIP client (with an XMPP address in a SIP header field parameter), is that right? Has S/MIME gotten much deployment to date? I know we didn't even mention S/MIME in SIPconnect 1.1 (http://www.sipforum.org/component/option,com_docman/task,doc_download/gid,476/Itemid,261/) |
2013-05-28
|
03 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2013-05-28
|
03 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-05-27
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-05-26
|
03 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-05-24
|
03 | Sean Turner | [Ballot comment] Would there be other capabilities that you'd want to advertise? Like here's my certificate? |
2013-05-24
|
03 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-05-24
|
03 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-05-23
|
03 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2013-05-23
|
03 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2013-05-22
|
03 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-05-21
|
03 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-05-16
|
03 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-05-15
|
03 | (System) | IANA Review state changed to IANA - Review Needed from Version Changed - Review Needed |
2013-05-15
|
03 | Gonzalo Camarillo | Placed on agenda for telechat - 2013-05-30 |
2013-05-15
|
03 | Gonzalo Camarillo | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-05-15
|
03 | Gonzalo Camarillo | Document shepherd changed to (None) |
2013-05-15
|
03 | Gonzalo Camarillo | Changed document writeup |
2013-05-15
|
03 | Gonzalo Camarillo | Ballot has been issued |
2013-05-15
|
03 | Gonzalo Camarillo | [Ballot Position Update] New position, Yes, has been recorded for Gonzalo Camarillo |
2013-05-15
|
03 | Gonzalo Camarillo | Created "Approve" ballot |
2013-05-15
|
03 | Gonzalo Camarillo | Ballot writeup was changed |
2013-05-14
|
03 | Peter Saint-Andre | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-05-14
|
03 | Peter Saint-Andre | New version available: draft-saintandre-impp-call-info-03.txt |
2013-05-14
|
02 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-05-02
|
02 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Glen Zorn. |
2013-04-24
|
02 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-04-24
|
02 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-saintandre-impp-call-info-02. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-saintandre-impp-call-info-02. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the Header Field Parameters and Parameter Values subregistry of the Session Initiation Protocol (SIP) Parameters registry located at: www.iana.org/assignments/sip-parameters/sip-parameters.xml a reference to this approved document, [ RFC-to-be ] will be added to the existing registration: Header Field: Call-Info Parameter Name: purpose Predefined Values: Yes Reference: [RFC3261][RFC5367][RFC6910][ RFC-to-be ] IANA understands that this is the only action required to be completed by IANA upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2013-04-24
|
02 | Elwyn Davies | Request for Last Call review by GENART Completed: Ready. Reviewer: Elwyn Davies. |
2013-04-18
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2013-04-18
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2013-04-18
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Glen Zorn |
2013-04-18
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Glen Zorn |
2013-04-16
|
02 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-04-16
|
02 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (Instant Messaging and Presence Purpose for the … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Subject: Last Call: (Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP). The file can be obtained via http://datatracker.ietf.org/doc/draft-saintandre-impp-call-info/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-saintandre-impp-call-info/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-04-16
|
02 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-04-16
|
02 | Gonzalo Camarillo | Last call was requested |
2013-04-16
|
02 | Gonzalo Camarillo | Ballot approval text was generated |
2013-04-16
|
02 | Gonzalo Camarillo | Ballot writeup was generated |
2013-04-16
|
02 | Gonzalo Camarillo | State changed to Last Call Requested from Publication Requested |
2013-04-16
|
02 | Gonzalo Camarillo | Last call announcement was generated |
2013-04-16
|
02 | Peter Saint-Andre | New version available: draft-saintandre-impp-call-info-02.txt |
2013-04-16
|
01 | Gonzalo Camarillo | Notification list changed to : psaintan@cisco.com, draft-saintandre-impp-call-info@tools.ietf.org, yana@jitsi.org |
2013-04-16
|
01 | Cindy Morgan | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. Yes, the type of the requested RFC is indicated in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP). Working Group Summary This draft was discussed in the DISPATCH working group. The conclusion of those discussions was that it was appropriate to AD sponsor it given that it was not controversial. The document is simply about the registration of an additional call-info header token and as such could even be viewed as a formality. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document shepherd isn't aware of current implementations. However there was interest in this work by vendors already implementing I-D.ivov-xmpp-cusax draft and there is a general interest in improving the interoperability among real-time communication endpoints that support combined use of SIP and XMPP, which is the purpose of the newly proposed header parameter value. Personnel The document shepherd is Yana Stamcheva. The responsible area director is Gonzalo Camarillo. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document, and believe it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? I do not have any specific concerns regarding this document. The document has been presented and discussed adequately by key WG members in the DISPATCH working group. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The author confirmed that he won't be filing any IPR disclosures on this document. (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures. No IPR disclosure that references this document has been filed. (9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? The proposition was seen as a fairly straightforward solution and there was a complete consensus on the subject. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. I have run the I-D through the ID nits tool and found no issues. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes, all references in the document exist either in the normative or the informative sections. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? The normative references are published RFCs. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA consideration section is completely consistent with the body of the document. I confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2013-04-16
|
01 | Cindy Morgan | Note added 'The document shepherd is Yana Stamcheva (yana@jitsi.org).' |
2013-04-16
|
01 | Cindy Morgan | IESG process started in state Publication Requested |
2013-04-16
|
01 | Gonzalo Camarillo | Shepherding AD changed to Gonzalo Camarillo |
2013-04-16
|
01 | Gonzalo Camarillo | Intended Status changed to Proposed Standard from None |
2013-04-16
|
01 | Gonzalo Camarillo | Stream changed to IETF from None |
2013-04-16
|
01 | Gonzalo Camarillo | Shepherding AD changed to Gonzalo Camarillo |
2013-04-07
|
01 | Peter Saint-Andre | New version available: draft-saintandre-impp-call-info-01.txt |
2013-03-10
|
00 | Peter Saint-Andre | New version available: draft-saintandre-impp-call-info-00.txt |