Subject: RE: [PINT] RE: [SPIRITS] Half-Pint

From: "Michael O'Doherty" <[email-masked]>
Date: Mon, 10 Sep 2001 12:05:37 +0100

Bobby,
 
Sorry about the delay replying.
 
I am not sure if we need to have the formal definition of AVP's and the
mechanism for allocation that Diameter uses, but it may be useful to look at
a similar approach for extensibility (although half-Pint is really intended
to be a quick solution developers can use as soon as possible rather than a
fully extensible one).
 
Cheers,
 
Mick.

-----Original Message-----
From: Bobby Sardana [mailto:[email-masked]]
Sent: 30 August 2001 08:38
To: O'Doherty, Michael [MDN05:MD01:EXCH]
Cc: [email-masked]'; [email-masked]
Subject: Re: [PINT] RE: [SPIRITS] Half-Pint

Greetings: 

The draft seems interesting for PSTN service initiation. However, it follows
the AVP (Attribute Value Pair) model where an action is followed by its
value. You can model it like RADIUS or DIAMETER, (AAA WG) which provide
definitions for AVPs and their usage, to  allow addition of new actions &
values. 

Regards, 

Bobby Sardana. 
[email-masked] 

Michael O'Doherty wrote: 

 I thought I would try again with this message as I realize most people were
probably tied up in the IETF meetings when I sent it last.In case it is not
clear below, I am interested in whatever is the best way to tackle the
requirements that the half-pint protocol addresses, whether that be by
refining half-pint or by evolving PINT or a SPIRITS like protocol.I think
this clearly lines up with the goals of these groups so I'm very keen to get
feedback/direction from the
lists.----------------------------------------------------------------------
---------The Half-Pint internet draft is now properly formatted (more or
less) and available at: 

http://search.ietf.org/internet-drafts/draft-odoherty-half-pint-00.txt
<http://search.ietf.org/internet-drafts/draft-odoherty-half-pint-00.txt>  

The idea behind the protocol is to try to provide something relatively
lightweight which will still provide a useful set of services for a
developer tying together web and PSTN services. The approach is to trade off
flexibility and completeness for simplicity - hence the name (which is not
cast in stone). 

My feeling is that this protocol, while not having the same ultimate
flexibility is simpler to get up and running today than a Pint/Spirits like
approach, especially from the perspective of a web developer. Part of the
thinking is that it is relatively well bounded and part of it is that it
avoids using SIP as a transport as SIP is not quite mature enough or
deployed enough today for the task - I'd be very interested to hear comments
on this view - is there anyone who feels that it would be better to use SIP
as the transport, maybe extending Pint ? 

The main aim is to get something working quickly (say within four months as
a goal) that provides the type of functionality contained in the half-pint
draft and allows service developers to start their work, and that has some
sort of consensus behind it from a standards point of view. 

If anybody has views on this approach or on better ways to achieve the same
goal, I'd be very happy to work with you to try to meet these objectives. 

Cheers, 

Mick.