[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
53rd IETF - Service in the PSTN/IN Requesting InTernet Service WG (spirits)
- To: IETF-Announce: ;
- Subject: 53rd IETF - Service in the PSTN/IN Requesting InTernet Service WG (spirits)
- From: firstname.lastname@example.org
- Date: Tue, 12 Mar 2002 15:07:23 -0500
- Delivery-date: Tue, 12 Mar 2002 22:47:25 +0200
- Envelope-to: email@example.com
- Sender: firstname.lastname@example.org
Service in the PSTN/IN Requesting InTernet Service WG (spirits)
Tuesday, Match 19 at 1300-1400
CHAIRS: Steve Bellovin <email@example.com>
Alec Brusilovsky <firstname.lastname@example.org>
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:
a. v.01 of the SPIRITS Protocol I-D has absorbed the SIP Event Package for SPIRITS I-D.
In the interest of speeding up the process of the SPIRITS Protocol definition,
it might be necessary to have Event Package I-D and Protocol I-D developed separately.
These I-Ds are then to be merged into a single Protocol I-D prior to its submission
to the IESG.
b. The issue of using XML Schema instead of DTDs was discussed at he last meeting.
So far, no work there has been done.
c. A list of the values of the parameters associated with the Event detection point
to be carried in the SUBSCRIBE body. We need to define DTDs or Schema for
these parameter lists.
d. MIME type: do we need a new MIME type (application/spirits-events) or
does an existing one suffice?
e. IANA Issues. Do we need to register anything else, besides mime types:
application/spirits-event, tokens: spirits.INDPs, spirits.user-prof]?
Should SPIRITS have 2 packages and no template packages?
I.e. spirits-INDPs and spirits-user-prof would be the two packages instead of spirits.
INDPs and spirits.user-prof (INDPs and user-prof being a template-package of the
f. Security Considerations. Need to expand and address SPIRITS specific threats,
i.e. SUBSCRIBE and/or NOTIFY spoofing.
Can SPIRITS leverage the security mechanisms developed for SIP in the SIP WG for
most of our work (augmented by Section 6 of the -05 SIP Events I-D)?
4. Conclusions - Chairs - 5 min.
Background information for the meeting:
The following three I-D's are published and available from the IETF repository:
1. SPIRITS Protocol Requirements
This is our new IESG approved Informational RFC. The status of this document in the
RFC Editor queue RFC as of 3/5/02 is: "EDIT = approved by IESG,
awaiting processing and publishing"
2. Toward the Definition of the SIP Events Package for SPIRITS Protocol
This I-D was discussed at the SLC meeting in December. This current version has
all the issues raised at the SLC meeting resolved.
3. The SPIRITS Protocol
This I-D is a union of:
SIP Event Package I-D, <draft-ietf-spirits-sip-evt-package-02.txt>,
IN Parameters I-D, <draft-ietf-spirits-in-02.txt>, and
Internet Caller-ID delivery example SPIRITS message flow.
This is our first attempt to describe and define SPIRITS protocol,
according to the architecture in RFC 3136 and requirements
in draft-ietf-spirits-reqs-04.txt, current Informational RFC Candidate