GIST: General Internet Signalling Transport
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, nsis mailing list <firstname.lastname@example.org>, nsis chair <email@example.com> Subject: Document Action: 'GIST: General Internet Signalling Transport' to Experimental RFC The IESG has approved the following document: - 'GIST: General Internet Signalling Transport ' <draft-ietf-nsis-ntlp-20.txt> as an Experimental RFC This document is the product of the Next Steps in Signaling Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-20.txt
Technical Summary This draft proposes a general signaling transport protocol. It is based on the use of existing transport and security protocols under a common messaging layer. GIST does not handle signaling application state itself; in that crucial respect, it differs from application signaling protocols such as SIP, RTSP, and the control component of FTP, but this follows the basic NSIS 2-layer signaling model defined in RFC 4080. Working Group Summary This document was previously sent back from the IESG. The WG has now addressed the issue raised by the IESG review and thinks it ready to progress. Protocol Quality Magnus Westerlund was the responsible AD. This document was reviewed by the working group chair as well as the WG. There are 6 or more independent implementations of GIST, and there was an interop event prior to the Paris IETF meeting. IETF Last call comments was received and has been incorporated. Then it was sent back to the WG to take care of a number of important to resolve issues. It has now gone through the WG process, and a second IETF last call. RFC-editor Note Section 5.1, third paragraph: OLD: Messages with missing, duplicate or invalid objects for the message type MUST be rejected with an "Object Type Error" message with the appropriate subcode (Appendix A.4.4.9). NEW: Messages with missing, duplicate or invalid objects for the message type MUST be rejected with an "Object Type Error" message with the appropriate subcode (Appendix A.4.4.9). Note that unknown objects indicate explicitly how they should be treated and are not covered by the above statement.