Subject: RE: [SPIRITS] Half-Pint

From: "Michael O'Doherty" <[email-masked]>
Date: Fri, 20 Jul 2001 15:48:50 +0100

Igor,

Thanks for the comments and good to see the PINT list still exists.

The idea with Half-Pint was that the protocol is happy to be transported on
whatever is available - we have tested it using UDP, but anything that can
wrap it up and deliver it to a Half-Pint parser should be fine.

To keep it as simple as possible we wanted to avoid making it necessary to
run it with SIP and SDP also, but as you point out it may be worth looking
at how it could be combined with this type of approach if people think this
would be useful. If others are interested in this, let me know.

I've added some other answers in line below.

Cheers,

Mick.

P.S. I think this thread is probably interesting to both Pint and Spirits,
but if anybody is concerned with the cross-posting let me know.

-----Original Message-----
From: Igor Faynberg [mailto:[email-masked]]
Sent: 19 July 2001 17:33
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [SPIRITS] Half-Pint

Mick,

Actually, the PINT mailing list (copied here) remains open for the
discussion. Yet, the scope of your draft, which I had read with
interest, also includes SPIRITS--in my opinion--inasmuch as it discusses
notifications. (By the way, for some reason, your draft makes no
references to any of the PINT or SPIRITS RFCs, nor does it reference
ther architecture.)

>>>>  Oppps - those references should definitely be in there ...

You explain the draft as a "ligthweight, restricted take on the
functionality provided by the PINT protocol)," but I think that what
draft describes is effectively an API, not a protocol, and at that it
extends rather than restricts the present PINT services. [You may want
to look at an earlier draft by Lev Slutsman ([email-masked]), which
you could obtain from him directly, since it expired, where he proposed
the requirements for PINT conference calling.] I would not call the API
you describe  "half-PINT"; to me it really looks like "seven-PINT"
(e.g., you describe capabilities for much more than ordering a two-party
call or sending fax from the web).

I use the word API, because what you describe is primitives and
parameters for invoking the services. The protocol, on the other hand,
would address the transport of the information among the involved
entities  (hence the need for the architecture). 

>>>> Not sure about this - still seems like a protocol to me, but I know
what you are saying here so the label is not too important. I take your
point about the half-Pint vs. Seven Pint name - I guess we thinking more of
its 'quick and simple' rather than flexible and scalable approach (the good
think about Pint is it allows lots of interesting names for related
protocols ...).

Finally, your draft does not have a security section, and does not
mention security at all, which is again an indication that the
application interface (rather than the protocol) is being discussed.

>>>> Security is obviously very important for this type of application - the
intent is to use the authorization info field to convey enough information
to allow the receiver of the message identify and verify the sender. We
haven't fixed on the best way top do this yet which is why it was left for
further study for now (although it is a 'must' so needs to be addressed
ASAP). I am assuming this is the type of security you mean rather than
message encryption etc which I hadn't really given much thought to.

Having said all that, I believe that your draft presents an interesting
and potentially useful set of framework requirements that would allow to
re-use the existing PINT and in-progress SPIRITS building blocks to
deliver many new services while using the existing protocol.
(Incidentally, SIP was chosen as PINT transport vehicle primarily
because it had already solved security and addressing problems.)

Personally, I would like your work to progress. I would suggest that you
look at the PINT protocol RFC and the present SPIRITS requirements and
see whether the existing protocol could satisfy the requirements of your
API. If not, you should suggest modifications. Then, if Lawrence Conroy
and Scott Petrack agree, the PINT protocol could be extended. At the
same time, if the SPIRITS chairmen agree, the SPIRITS could take your
work in account, too.

Note that PINT has been already implemented as is. (And, in addition,
there are PINT-like services supported by other protocols.)

Respectfully,

Igor Faynberg