Subject: Re: [SPIRITS] Some Thoughts On Protocol Requirements

From: Bruce Chapman <[email-masked]>
Date: Tue, 27 Mar 2001 10:20:24 +1200 (NZST)

Good Morning all,

Some replies to Jorge, Kumar and Lawrence,

Jorge wrote
-----------

> Your proposal to use XML is very interesting, and I agree it needs to be
> considered a candidate protocol for SPIRITS. By the way, I understand that
> you mean XML based on HTTP (since XML is just about contents and needs a
> protocol) .. or do you mean XML using SIP?.

The suggestion of using XML was at the presentation layer, rather than the 
transport layer. (but if we use SIP the two get very blurred since it does both),
maybe it would be XML over TCP/IP but that collides with the B interface requirements. 
(we are implementing B using a reliable layer over WTLS). The B interface is a 
problem here because the initial pointers are toward a secure reliable packet transport
layer. TLS/SSL without the 64K ports limit. WTLS maps quite well to these requirements.

> After a very quick thought (and not being a SIP expert), I think that the
> use of XML would be preferrable if we decide to map a lot of INAP protocol
> information into SPIRITS protocol (and not if the amount of information we
>pass to SPIRITS is limited).

If we pass a limited amount of INAP data into the SPIRITS protocol we potentially limit
the possibilities for new services. That is, for each item we omit, we may later find that
it would have been useful to have had it for some service. We probably don't need to 
include everything, 

but if we do a good job on SPIRITS then it should be possible to include everything. 
Think of this as foreshadowed extensions. In the case of INAP/XML, then the SPIRITS protocol 
would say how we map the data back and forth, and which data was mandatory. Anyone extending 
SPIRITS to use additional parameters would do so in exactly the same way as someone else wanting the same parameter. Although this does not guarantee interoperability per se, it goes most of the way. 

> P.D. By the way, did you send the proposal to use XML to transfer ISUP
> messages using SIP (instead that using MIME) to the SIP group ?.

No, 

But ISUP encoded by XML in SIP would still be MIME, it would just be a new MIME type in the SIP body. The difference is that the SIP proposals for ISUP puts the bare binary ISUP as a MIME type.

Kumar wrote
----------

> Alternatives:
> 1. Extend the traditional SDP as defined, to encode Spirits data 
>   as well. This is (sort of) supported by the SDP draft. To 

This is, I think, the only thing I have a very strong view on. 
SPIRITS should not extend SDP. in a word it would be UGLY. I am 
not convinced about using SIP, but if that is the choice, the 
SPIRITS information can be carried in one (or both) of two ways. 
Either as a (probably new) MIME type in the body of the SIP message, 
and/or using the extension mechanisms defined in SIP such as  
other-param(s) in a SIP URL  (see RFC-2543 section 2).

Lawrence wrote
--------------

> I'm intrigued by the comment that:
> >  "These sessions need to have the characteristic that the Gateway can
> >  determine if the session is still active.
>
> Perhaps an expansion would be useful?

The spirits servers will in many cases be running over a dial up 
connection to an ISP (the whole reason for the ICW service), and 
will have dynamically allocated IP addresses. 

This means that any requirement for the SPIRITS server to close 
the (real or virtual) session, either by deregistering or whatever, 
before the server closes down, is completely unreasonable. Servers 
WILL just disappear (not just occassionally but in fact in most cases).
We can't do anything about that, we must design for it.

The SPIRITS protocol must be robust against the following scenario:

	A server starts a 'session' with the gateway, 
	then the dial up connection through which  the server is connnected 
	to the internet is broken. 
	Another ISP customer then is allocated that same IP address, 
	This new machine (same IP address) starts a SPIRITS server running.
	The gateway must not confuse this new 'session' with the old one.

Also, to manage resources effectively at the gateway, we need to know 
when a server is no longer available so that those resources can be 
released, and we cannot rely on the server telling the gateway when it 
is about to become unavailable. Remember a gateway may have in the order 
of tens of thousands (or more) servers with active 'sessions' at any one time.

regards

Bruce

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

---

From: "Kumar V. Vemuri" <[email-masked]>
Date: Wed, 28 Mar 2001 10:45:37 -0600

Bruce, I must say I agree with you that "Alternative 1" I listed
  in my email is UGLY. IMHO, it is important and interesting
  to consider all alternatives that occur to us, and capture
  the reasoning for or against, so that we may build concensus
  on the mailing list.

  Please elaborate on the use of SIP URIs to transport this
  information. An example would help me understand this better.
  Are you suggesting adding support for new params in the
  "sip:<name>;..." structure? Seems interesting. Alternative 5.
  Any others occur to anyone? Does SIP with an XML body seem the 
  most favorable option?
regards,
Kumar.
--
Bruce Chapman wrote:
> --
> Jorge wrote:
>> Your proposal to use XML is very interesting, and I agree it 
>> needs to be considered a candidate protocol for SPIRITS. By 
>> the way, I understand that you mean XML based on HTTP (since 
>> XML is just about contents and needs a protocol) .. or do you 
>> mean XML using SIP?.
> 
> The suggestion of using XML was at the presentation layer, 
> rather than the transport layer. (but if we use SIP the two get 
> very blurred since it does both), maybe it would be XML over 
> TCP/IP but that collides with the B interface requirements. 
> (we are implementing B using a reliable layer over WTLS). The
> B interface is a problem here because the initial pointers are 
> toward a secure reliable packet transport layer. TLS/SSL 
> without the 64K ports limit. WTLS maps quite well to these 
> requirements.

<snip>

> Kumar wrote:
>> Alternatives:
>> 1. Extend the traditional SDP as defined, to encode Spirits 
>>   data as well. This is (sort of) supported by the SDP draft. 
>> 
> SPIRITS information can be carried in one (or both) of two 
> ways. Either as a (probably new) MIME type in the body of the 
> SIP message, and/or using the extension mechanisms defined in 
> SIP such as other-param(s) in a SIP URL (see RFC-2543 
> section 2).
[...]

---

From: Alec Brusilovsky <[email-masked]>
Date: Wed, 28 Mar 2001 11:28:07 -0600

Bruce, Jorge, Kumar and Lawrence,

Thanks for starting a good and much needed discussion!
Obviously, we cannot complete SPIRITS protocol without specifying the
exact way to transport SPIRITS parameters.

Let me do (maybe preliminary) summary of this discussion:
1. There is definite drive towards utilizing XML ("XML may well be
the best way to encode the structured data in
the INAP messages at the boundary of the architecture into a text
based protocol for use within the architecture" - JG; "define an XML
encoding with suitable DTD to encode the information Spirits
requires." - KV);

2. SIP seems to be a "natural" transport vehicle for SPIRITS
parameters ("We based PINT on SIP - it works for
us, so you may need to give some details on why it doesn't work for
SPIRITS. . . we didn't have to re-invent a
worldwide infrastructure" - LC).

I, personally, think that there is a way to use both of these
approaches (i.e. XML encoded parameters transported over SIP).

Regards,
Alec

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 28 Mar 2001 11:38:10 -0800

Greetings:

A popular transport for XML documents is HTTP.  Has any thought being
given to use HTTP?

Regards,

[email-masked]

---

From: "Kumar V. Vemuri" <[email-masked]>
Date: Wed, 28 Mar 2001 15:39:34 -0600

Bobby, 
  IMHO, the question becomes one of whether or not one needs
 the use of SIP semantics in addition to the meaning conveyed
 by the XML content in the body.

 One way we could make use of that semantic content is where
 we use the INVITE, or SUBSCRIBE and NOTIFY primitives from 
 SIP to register interest in specific events, and request 
 notifications when they occur.

 Is there an analogous mechanism in HTTP to accomplish similar
 goals?
regards,
Kumar.
--
Bobby Sardana wrote:
> Greetings:
> A popular transport for XML documents is HTTP.  Has any 
> thought being given to use HTTP?
> Regards,

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 28 Mar 2001 16:13:08 -0800

Greetings:

Comments inline!

>  notifications when they occur.

INVITE, SUBSCRIBE, NOTIFY have been defined for certain specific
purposes. Trying to convey a different behavior
for a simplistic operation like XML document exchange is an overkill
(MHO). HTTP on the other hand is being used
for much complicated XML document exchange(s). Look or study any BtoB --
any exchange, and that will outline the
benefits.

Several issues, for which many proposals exist for SIP, regarding
firewall traversal, TLS, have already been solved and matured
with regards to HTTP.

>  Is there an analogous mechanism in HTTP to accomplish similar

Yes. I would recommend an analysis of PUSH framework of WAP to
understand how asynchronous events can be managed and
executed using HTTP.

Regards,