Subject: [SPIRITS] Issues for the 3/19/02 meeting

From: Alec Brusilovsky <[email-masked]>
Date: Wed, 06 Mar 2002 16:24:51 -0600

Ladies and Gentlemen,

The following three I-D's are published and available from the IETF 
repository:

1. SPIRITS Protocol Requirements
http://www.ietf.org/internet-drafts/draft-ietf-spirits-reqs-04.txt
This is our new IESG approved Informational RFC. The status of this 
document in the RFC Editor queue RFC as of yesterday is: "EDIT = 
approved by IESG, awaiting processing and publishing"

2. Toward the Definition of the SIP Events Package for SPIRITS Protocol
http://www.ietf.org/internet-drafts/draft-ietf-spirits-sip-evt-package-02.txt
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
http://www.ietf.org/internet-drafts/draft-gurbani-spirits-protocol-01.txt
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

Issues for the 3/19 meeting:

1. 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.

2. The issue of using XML Schema instead of DTDs was discussed at he 
last meeting. So far, no work there has been done.

3. 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 Shema for these parameter lists.

4. MIME type: do we need a new MIME type (application/spirits-events) or 
does an existing one suffice?

5. IANA Issues. Do we need to register anything else, besides mime 
types:application/spirits-event, tokens: spirits.INDPs, spirits.user-prof]?

6. Security Considerations. Need to expand and address SPIRITS specific 
threats, i.e. SUBSCRIBE and/or NOTIFY spoofing.

Any other issues for the 3/19 meeting?

Kind regards,
Alec

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 06 Mar 2002 17:14:26 -0600

> Issues for the 3/19 meeting:
[...] 
> DTDs or Shema for these parameter lists.

Also, don't forget the NOTIFY bodies as well; these will contain the 
information that results when the subscribed event occurred.  The 
information has to be carried back to the subscriber in some format.

As it stands right now, in the I-D
http://www.ietf.org/internet-drafts/draft-gurbani-spirits-protocol-01.txt
we do list the INAP parameters for the DPs in Appendices A and B.  Do we 
codify these DTDs in the RFC or leave them open-ended?  The overall 
issue in (3) is very important and will probably benefit from some 
interaction at the Minneapolis IETF.

> types:application/spirits-event, tokens: spirits.INDPs, spirits.user-prof]?

This kind of ties into the email I posted a couple of days ago to the 
list -- the email between myself and Adam Roach.  The gist of the email 
was that SPIRITS should 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 "spirits" package).  I am still struggling to 
make sense of this (I had initially envisioned user-prof and INDPs as a 
template-package of the "spirits" package -- Adam indicated that this is 
not the correct usage of template packages).  Probably worth some time 
at the Minneapolis IETF.

> threats, i.e. SUBSCRIBE and/or NOTIFY spoofing.

I think that we can 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) .  Of more interest will be the interface that straddles 
the PSTN and the Internet...

> Any other issues for the 3/19 meeting?

Not right now; I am sure something else will strike me later...

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184