53rd. IETF SPIRITS Working Group Meeting Notes Reported by Alec Brusilovsky. SPIRITS WG met in the afternoon of Tuesday, March 19, 2002. There were 100 registered attendees. Chairs: Steve Bellovin, Alec Brusilovsky Agenda 1. Agenda bashing - Chairs - 5 min. 2. ICIDD service in SPIRITS - example call flows and issues - V. Gurbani - 5 minutes 3. SPIRITS Protocol Issues - discussion - 45 minutes: 4. Conclusions - Chairs - 5 min. Agenda item 1: Chair (A.B.) went through the changes in the agenda and the agenda bashing. A.B. proposed an addition to the agenda item 2 - Protocol Issues. Proposed agenda was accepted. Agenda item 2: Vijay Gurbany went along call flows for he example SPIRITS service - ICIDD (Internet Caller ID Delivery), that utilized TAA DP. ICIDD is explained in detail in RFC 3136 . For the purpose of SPIRITS example ICIDD is better suited than ICW because PSTN terminal and SPIRITS server are spacially disjoined. Question: What about PARLAY call control? Are there any plans to work with PARLAY? Answer: All APIs, including PARLAY have some sort of protocol to ride on. We deal with SPIRITS protocol specifications here. PARLAY is free to use SPIRITS specifications to develop PARLAY SPIRITS API. Agenda item 3: The discussion at the meeting stemmed from the SPIRITS Protocol I-D: http://www.ietf.org/internet-drafts/draft-gurbani-spirits-protocol-01.txt a. Keep SPIRITS Event package as part of the SPIRITS protocol I-D, as opposed to splitting it into a separate I-D to develop in parallel; b. Split IN description, parameters, information flows, etc. from the protocol I-D, combine this material with IN and XML encoding related material from draft-ietf-spirits-in-02.txt and draft-unmehopa-spirits-parameter-generation-00 Both of these I-D's have valuable information on PSTN/IN, INAP parameters description, examples of INAP encoding into XML and examples of using automatic tools from ITU-T to generate XML DTDs from INAP ASN.1. Advantages: localized changes, easier maintenance, reduction in size of the protocol specification, uniform reference from other I-Ds (or RFCs) (SIN?), speeding up SPIRITS specs development. Disadvantages: dependency. The resulting I-D to be submitted to the IESG as an Informational RFC candidate before the next meeting. Musa Unmehopa and Kumar Vemuri volunteered to lead this work. c. It as an open issue. If there is a MIME type we can (re)use in SPIRITS, we will do so. Otherwise, we will have to register application/spirits-event as a new MIME type. d. There is an urgent need to define parameter lists, corresponding XML DTDs and Schemas for SUBSCRIBE methods. These parameter lists will be subsets of NITIFY parameter lists. e. SPIRITS security might rely on SIP security with the exception of Interface B that traverses both administrative and PSTN/IP domains. f. When dealing with IANA issues, protocol document editors have to be explicitly clear and define sufficiently what needs to be registered by IANA; All of the items above need to be reconfirmed on the SPIRITS mailing list. Agenda item 4: What's next? Continue protocol development. We plan to submit SPIRITS Protocol I-D to the IESG in three to six months, preferably, together with SPIRITS MIB I-D. WG needs help with Wireless events and their specific parameters, need help with expanding the Security Considerations section, and WG really needs volunteers to assist/drive with MIB. Respectfully submitted, Alec Brusilovsky