From owner-pint-outgoing@lists.research.bell-labs.com  Mon Jan  3 10:35:25 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02857
	for <pint-archive@odin.ietf.org>; Mon, 3 Jan 2000 10:35:24 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id C831552E3; Mon,  3 Jan 2000 10:29:34 -0500 (EST)
Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id E6EB452E8; Mon,  3 Jan 2000 10:29:33 -0500 (EST)
Delivered-To: pint-local@paperless.dnrc.bell-labs.com
To: pint@lists.research.bell-labs.com
Date: Mon, 3 Jan 2000 10:25:33 -0500
Message-ID: <003001bf55fe$7b90bb00$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
Sender: owner-pint@lists.research.bell-labs.com
Precedence: bulk

To: <Undisclosed-Recipient:@smtp2.cluster.oleane.net;>
Subject: VoDSL 2000 Conference 
Date: Mon, 3 Jan 2000 16:23:02 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002D_01BF5606.CEA9F2E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_002D_01BF5606.CEA9F2E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
=20
The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key =
speakers, case studies: take a look at:  =
http://www.upperside.fr/bavodsl.htm
=20
Regards



------=_NextPart_000_002D_01BF5606.CEA9F2E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>Hello,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>The VoDSL 2000 Conference will stand =
in Paris=20
next 28-31 March. Key speakers, case studies: take a look at:&nbsp; <A=20
href=3D"http://www.upperside.fr/bavodsl.htm">http://www.upperside.fr/bavo=
dsl.htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Regards</FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_002D_01BF5606.CEA9F2E0--


---------
This message came from the IETF PINT Working Group Mailing List.


From owner-pint-outgoing@lists.research.bell-labs.com  Fri Jan  7 06:44:14 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14225
	for <pint-archive@odin.ietf.org>; Fri, 7 Jan 2000 06:44:14 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 58C8252F2; Fri,  7 Jan 2000 06:41:23 -0500 (EST)
Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id BD91C52F7; Fri,  7 Jan 2000 06:41:22 -0500 (EST)
Delivered-To: pint-local@paperless.dnrc.bell-labs.com
Message-Id: <200001071139.GAA14129@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: pint@lists.research.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pint-conf-01.txt
Date: Fri, 07 Jan 2000 06:39:30 -0500
Sender: owner-pint@lists.research.bell-labs.com
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the PSTN and Internet Internetworking Working Group of the IETF.

	Title		: A proposal for new PINT building blocks with 
                          applications to Conference Calling
	Author(s)	: L. Slutsman
	Filename	: draft-ietf-pint-conf-01.txt
	Pages		: 8
	Date		: 06-Jan-00
	
The main purpose of this document is to propose new Conference Call 
Service for the PINT WG. This document contains a description of a 
Conference Call Service for PINT (CCSP), provides a non-exhaustive 
list of PINT requests (PINT Conference Building Blocks) to support 
them, and describes the needed extensions to the current PINT 
architecture.  Current PINT services, such as Request to Call, use 
the Internet only to deliver service requests from an IP host to the 
PSTN to be executed there.  However, limiting the PINT Conference 
service to  just delivering the request to allocate the conference 
bridge to the PSTN, would hardly justify the practicality of the 
service.  The PINT Conference Service described in this document 
allows for the following functionality: 
o manual or automated negotiation of conference parameters, such as 
date, agenda, etc., before the PSTN resources are committed;  
o requesting the PSTN to allocate the conference bridge; 
o requesting the PSTN to start the conference automatically by 
calling each participant at the specified time;  
A proposal for new PINT building blocks with applications to Conference Calling    
o monitoring real-time conference events by keeping track of the 
current speaker as well as of participants leaving or joining the 
conference bridge.  
Unlike the current PINT services, which require exactly one request 
per service, the proposed Conference Call Service with the above 
functionality, needs to be mapped into a number of PINT requests.  In 
this paper we propose a non-exhaustive list of PINT requests to 
support the basic CCSP functionality.  We also discuss the extensions 
to the current PINT architecture that are needed to support the CCSP. 
If the service proposal is approved by the PINT WG, the protocol 
issues such as profiling SIP, SDP, etc.  will be addressed in the 
forthcoming documents.  
This document is intended for the PSTN-Internet Interworking (PINT) 
worki

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pint-conf-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pint-conf-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pint-conf-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000106131252.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-pint-conf-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pint-conf-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000106131252.I-D@ietf.org>

--OtherAccess--

--NextPart--



---------
This message came from the IETF PINT Working Group Mailing List.


From owner-pint-outgoing@lists.research.bell-labs.com  Fri Jan  7 19:57:39 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29596
	for <pint-archive@odin.ietf.org>; Fri, 7 Jan 2000 19:57:39 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id C951452B6; Fri,  7 Jan 2000 19:53:36 -0500 (EST)
Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 4ACA952C4; Fri,  7 Jan 2000 19:53:36 -0500 (EST)
Delivered-To: pint-local@paperless.dnrc.bell-labs.com
Date: Fri, 7 Jan 2000 19:51:45 -0500 (EST)
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Message-Id: <200001080051.TAA16209@tune.cs.columbia.edu>
To: pint@lists.research.bell-labs.com
Subject: CFP on JCN Special Issue on Internet QOS - Deadline Extended
List: pint@lists.research.bell-labs.com
Sender: owner-pint@lists.research.bell-labs.com
Precedence: bulk

         JOURNAL OF COMMUNICATIONS AND NETWORKING (JCN)

 CALL FOR PAPERS - SPECIAL ISSUE ON QoS IN IP NETWORKS
                        JUNE, 2000

 ---> DEADLINE EXTENDED to January 31, 2000

A Special Issue of JCN dedicated to the realization of QoS-sensitive
services in IP networks will be published in June, 2000.  It will be
Guest Edited by Prof. Henning Schulzrinne of Columbia University,
Prof. Hideo Miyahara of Osaka University, and Prof. Luigi Fratta of
the University of Milan.  The topics include but are not limited to:

Differentiated Services
Integrated Services
MPLS
Real-time multicast
IP network traffic engineering
Performance measurement and evaluation
Pricing and billing
User perception of QOS
QOS policy management
Adaptive and other new service models
Light-weight reservation protocols and aggregation

Continuing JCN's tradition of fast turnaround together with full peer
reviews, the following schedule has been set:

Jan. 31, 2000   Submit manuscript via web page (see below)

Mar. 31, 2000   First reviews returned to author, revisions returned
                within three weeks

June, 2000      Special Issue published

The guest editors are
Prof. Luigi Fratta  <fratta@elet.polimi.it>
Prof. Hideo Miyahara <miyahara@mercury.nal.ics.es.osaka-u.ac.jp>
Prof. Henning Schulzrinne <hgs@cs.columbia.edu>

Papers should be submitted via the procedure described at

http://www.cs.columbia.edu/~hgs/edas/JCN

Only PostScript and PDF formats are accepted.

Further information about JCN is available at http://JCN.snu.ac.kr. 
JCN is a high-quality quarterly archival journal, published by the
Korean Institute of Communications Sciences with the technical
cosponsorship of the IEEE Communications Society, covering the fields of
Communication Theory and Systems, Wireless Communications, and Networks
and Services.  JCN began publication in March, 1999.


---------
This message came from the IETF PINT Working Group Mailing List.


From owner-pint-outgoing@lists.research.bell-labs.com  Sun Jan  9 23:18:16 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14312
	for <pint-archive@odin.ietf.org>; Sun, 9 Jan 2000 23:18:15 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3BE3A52C4; Sun,  9 Jan 2000 23:15:23 -0500 (EST)
Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id AFA4952D6; Sun,  9 Jan 2000 23:15:22 -0500 (EST)
Delivered-To: pint-local@paperless.dnrc.bell-labs.com
User-Agent: Microsoft Outlook Express Macintosh Edition - 5.01 (1630)
Date: Sun, 09 Jan 2000 23:13:59 -0500
Subject: Discussion on PINT Conference Call Draft
From: David Shrader <DShrader@EyeForTheFuture.com>
To: PINT List <pint@lists.research.bell-labs.com>,
        "Slutsman, Lev A, ALSVC" <lslutsman@att.com>
Message-ID: <B49EC6B7.7EA%DShrader@EyeForTheFuture.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-pint@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Lev,

Thanks for bringing up the conference call topic. I find it to be an
interesting service that I think could be quite useful.

I think, however, that there are many things specified here that don't
really belong in PINT. All of the material related to the committing of
actions and coordination of the conference session prior to setup is really
application specific and is outside the scope of a protocol like PINT, in my
opinion. I think the capabilities to the have an IP host which is
implementing such a conferencing service to request the PSTN to actually set
up the call is the type of capability for PINT to address.

One additional point, the discussion related to fax data. It seems to me
that from the PINT Client to PSTN point of view this could be seen as simply
another multiparty call requesting the fax to multiple destinations (which,
the PSTN would translate to a one-many broadcast arrangement and not really
a muliparty conference due to the bilateral handshakes required for a
standard fax). From the PINT server perspective, this does not need to be
related to the voice conference at all and may, in fact, be offered via
another PSTN provider.

David






---------
This message came from the IETF PINT Working Group Mailing List.


From owner-pint-outgoing@lists.research.bell-labs.com  Tue Jan 11 05:56:00 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03244
	for <pint-archive@odin.ietf.org>; Tue, 11 Jan 2000 05:56:00 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 93A7052D6; Tue, 11 Jan 2000 05:45:46 -0500 (EST)
Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 1C9A152DB; Tue, 11 Jan 2000 05:45:44 -0500 (EST)
Delivered-To: pint-local@paperless.dnrc.bell-labs.com
To: pint@lists.research.bell-labs.com
Date: Tue, 11 Jan 2000 05:43:02 -0500
Message-ID: <008501bf5c20$6b51e020$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
Sender: owner-pint@lists.research.bell-labs.com
Precedence: bulk

To: <Undisclosed-Recipient:@smtp1.cluster.oleane.net;>
Subject: SIP 2000 Call for Paper
Date: Tue, 11 Jan 2000 11:41:20 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0082_01BF5C28.C79F0D00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0082_01BF5C28.C79F0D00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

SIP 2000: beyond H.323?=20
Discussing and debating in Paris May 10-12.
A CFP is online at:
http://www.upperside.fr/basip.htm
=20


------=_NextPart_000_0082_01BF5C28.C79F0D00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>SIP 2000: beyond H.323? =
</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Discussing and debating in Paris May =

10-12.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>A CFP is online at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0082_01BF5C28.C79F0D00--


---------
This message came from the IETF PINT Working Group Mailing List.


From owner-pint-outgoing@lists.research.bell-labs.com  Tue Jan 11 09:09:30 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09808
	for <pint-archive@odin.ietf.org>; Tue, 11 Jan 2000 09:09:28 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 7CDE552DD; Tue, 11 Jan 2000 08:56:56 -0500 (EST)
Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B1A7552DC; Tue, 11 Jan 2000 08:56:55 -0500 (EST)
Delivered-To: pint-local@paperless.dnrc.bell-labs.com
Message-ID: <387A298D.625BD7B5@bell-labs.com>
Date: Mon, 10 Jan 2000 13:48:45 -0500
From: Igor Faynberg <faynberg@bell-labs.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Shrader <DShrader@EyeForTheFuture.com>
Cc: PINT List <pint@lists.research.bell-labs.com>,
        "Slutsman, Lev A, ALSVC" <lslutsman@att.com>
Subject: Re: Discussion on PINT Conference Call Draft
References: <B49EC6B7.7EA%DShrader@EyeForTheFuture.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pint@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



David Shrader wrote:
> 

> I think, however, that there are many things specified here that don't
> really belong in PINT. All of the material related to the committing of
> actions and coordination of the conference session prior to setup is really
> application specific and is outside the scope of a protocol like PINT, in my
> opinion. 

It is absolutley true that the subject is OUTSIDE of the PINT charter, which is
why we have paid little attention to it while completing the work of the
charter.

Steve and I have discussed this subject with the ADs six months ago, and as the
result of the discussion we admitted the first copy of this draft to PINT as a
PINT WG document. The present document is a follow-up to replace the expiring
draft.  

I personally would like to finish whatever little is left to finish with the
present charter (see the Chairs' State of The Group Address, which will be sent
today) before embarking full speed on a new project, but the discussion is
welcome.

My view of Lev's proposal is that it is consistent with the spirit of the
present PINT charter (i.e., services initated with the PSTN),  and I have a
clear understanding of the need for the protocol as proposed by Lev. We must,
however, make sure that the protocol can INTERWORK with the IN Call Party
Handling (CPH) standardized in the ITU-T IN CS-2. A few experts had looked at
Lev's proposal, which was brought to ITU SG 11 by Hui-Lan, and told me they
agree with it and felt it could interwork with the CPH.

So, yes, we can discuss the draft--although let us concentrate on technical
issues, and when it is clear where we are going we will decide whether this
should be done in re-chartered PINT, or another group, or independent of any
group.

But we also need to finish the work WITHIN the charter!

With best regards,

Igor

---------
This message came from the IETF PINT Working Group Mailing List.


From owner-pint-outgoing@lists.research.bell-labs.com  Tue Jan 11 18:50:30 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23372
	for <pint-archive@odin.ietf.org>; Tue, 11 Jan 2000 18:50:29 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id AE09652AB; Tue, 11 Jan 2000 18:47:28 -0500 (EST)
Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 16F4552DF; Tue, 11 Jan 2000 18:47:27 -0500 (EST)
Delivered-To: pint-local@paperless.dnrc.bell-labs.com
Message-ID: <387BC0F6.737407F6@bell-labs.com>
Date: Tue, 11 Jan 2000 18:47:02 -0500
From: Igor Faynberg <faynberg@bell-labs.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pint <pint@lists.research.bell-labs.com>
Cc: sob@harvard.edu, vern@aciri.org, smb@research.att.com
Subject: State of the Working Group
X-Priority: 2 (High)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pint@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Dear Members of PINT WG:

Steve and I wish you best for the New Year!

It is time to review the state of our working group, which is what we do in this
message. There are still two items in our charter (the PINT Protocol RFC and the
PINT MIB RFC) that we need to complete, and we address those items first. Then,
there is a proposal for the new work outside of our old charter, and we address
that, too. Finally, there is an on-going liaison with ITU-T SG 11, carried by
ever-energetic Hui-Lan, and we will attach the latest news.

So, here we go.

1. PINT Protocol

Our RFC candidate "The PINT Service Protocol: Extensions to SIP and SDP for IP
Access to Telephone Call Services" (draft-ietf-pint-protocol-02.txt) has
undergone a thorough IESG review (pretty much positive), with a number of issues
had been fed back. We have been discussing those with Scott and Lawrence, who
are working on addressing them right now. With the omission of purely editorial
comments and what the authors of comments identified as "nits," here are what we
thing most important IESG suggestions:

> It is better if the multipart types have a specific subtype and not use 
> mixed. For example multipart/pint. The fallback is always mixed for unknown 
> multipart subtypes, so this should not create any problems with 
> implementations.
> 
> They should look at RFC 2387, which is multipart/related, which is supposed 
> to be used when more than one bodypart should be "grouped" together. That 
> is fine with me as a specific MIME-type. This should be checked with Ned 
> Freed as the "expert" on mimetypes.
> 
> 2387 The MIME Multipart/Related Content-type. E. Levinson. August
>      1998. (Format: TXT=18864 bytes) (Obsoletes RFC2112) (Status: PROPOSED
>      STANDARD)
> 

> 3.4.2. Support for Data Objects within PINT
>     ...
>     The Media sub-field definition is relaxed to accept all of the discrete
>     "top-level" media types defined in [4]. In the milestone services the
>     discrete type "video" is not used, and the extra types "data" and "control"
>     are likewise not needed. The use of these types is not precluded, but the
>     behaviour expected of a PINT Gateway receiving a request including such a
>     type is not defined here.
> 
> given the preceeding
> 
>     3.3. REQUIRED and OPTIONAL elements for PINT compliance
>     ...
>     The "Require:" SIP header and the "require" attribute provide a mechanism
>     that can be used by clients and servers to signal their need and/or
>     ability to support specific "new" PINT protocol elements.
> 
> has vague echos of a mandatory extensions loophole.  especially given
> 
>     3.4.4. The "require" attribute
> 
>     According to the SDP specification, a PINT server is allowed simply to
>     ignore attribute parameters that it does not understand. In order to
>     force a server to fail a request if it does not understand one of the
>     PINT attributes, a client should use the "require" attribute, specified
>     as follows:
> 
> possibly s/fail/decline/ and let the requestor fail.
> 
> and the server gets the blame in
> 
>     3.5.4. The "Require:" header for PINT
>     ...
>     A client should only include a Require: header where it truly requires the
>     server to fail the request if the option is not supported.
> 
> again s/fail/decline/ or something similar.
> 
> ---
> 
>     3.4.2.3. Support for GSTN-based Data Objects in PINT
> 
> perpetuates the pull as opposed to push model in
> 
>     For example:
>           c= TN RFC2543 +1-201-406-4090
>           m= text 1  fax plain
>           a=fmtp:plain  opr:APPL.123.456
> 
>     means send me the data that is indexed ON THE GSTN by the reference value
> 
> seems to assume that +1-201-406-4090 == me, where it could be anybody to
> whom the requestor wishes to receive the data object.

>  3.5.3.1. Opening a monitoring session with a SUBSCRIBE request
> 
> neglects to say to what entity SUBSCRIBE requests are sent.  one would
> assume a gateway, and this is reinforced by text in that section
> 
>     A successful response to the SUBSCRIBE request includes the session
>     description, according to the Gateway.
> 
> but that is mildly ambiguous.  i would let it pass, except that
> 
>     3.5.3.3. Closing a monitoring session with an UNSUBSCRIBE request
>     At some point, either the Client's representative User Agent Server or the
>     Gateway may decide to terminate the monitoring session. This is achieved
>     by sending an UNSUBSCRIBE request to the correspondent server.
> 
> i.e. a gateway may send an UNSUBSCRIBE?  this seems quite odd, when it would
> seem more sensible to send a NOTIFY with Expires: 0.
> 
> i think the answer is hidden behind
> 
>     If the subscription period specified by the Client has expired, then the
>     Gateway may send an immediate UNSUBSCRIBE request to the Client's
>     representative User Agent Server. This ensures that the monitoring session
>     always completes with a UNSUBSCRIBE/response exchange, and that the
>     representative User Agent Server can avoid maintaining state in certain
>     circumstances.
> 
> but it's all a bit confusing.  maybe state transition diagrams would help.
> 

>
> ---
> 
>     1. A BYE indicates that the requesting client will clear out all call
>     state as soon as it receives a successful response. A client SHOULD NOT
>     send a SUBSCRIBE request after it has sent a BYE.
> 
> is contradicted by
> 
>     2. A server may return an Expires: header within a successful response
>     to a BYE request. This indicates for how long the server will retain
>     session state about the telephone network session. At any point during
>     this time, a client may send a SUBSCRIBE request to the server to learn
>     about the session state.
> 
> ---

> 3. When engaged in a SUBSCRIBE/NOTIFY monitoring session, PINT servers
>     that send BYE to a URL listed in the Contact: header of a client request
> 
> but the server sending a BYE was never mentioned in the [UN]SUBSCRIBE/NOTIFY
> description!
> 
> this thing REALLY needs a complete state machine description so it is very
> clear what messages may be sent to whom and when.
> 

> 
>     The SUBSCRIBE request indicates that a user wishes to receive information
>     about the status of a session. The request identifies the session of
>     interest normally by including the original session description along
>     with the request.
> 
> truely unambiguous?  i send a page.  it is not answered.  i, being a very
> impatient type, resend the same message to cause a second page.  i wish to
> monitor the second, or maybe check on progress of the first
> 
> or, if this is an sdp global session id, then say so in literal words.  or,
> is it a sip session id as implied in
> 
>     3.5.3.4. Timing of SUBSCRIBE requests
>     As it relies on the Gateway having a copy of the INVITEd session
>     description ...
> 

> ...[Security considerations] seem a delicate balance that i am not sure would make conservatives
> completely comfortable.  e.g.
> 
>     A Requesting User has a reasonable expectation that their requests for
>     service are confidential. For some PINT services, no content data is
>     carried over the Internet; however, the telephone or fax numbers of the
>     parties to a resulting service calls may be considered sensitive. As a
>     result, it is likely that the Requestor (and their PINT service
>     provider) will require that any request that is sent across the
>     Internet be protected against eavesdroppers; in short, the requests
>     should to be encrypted.
> 
> /should to/SHOULD/  maybe even MUST
> 
> and should
> 
>     Thus, to ensure that the session identifier is not guessable the
>     techniques described in section 6.3 of [17] can be used when generating
>     the origin-field for a session description to be used inside a PINT
>     INVITE message. If all requests from (and responses to) a particular
>     PINT requesting entity are protected, then this is not needed. Where
>     such a situation is not assured, AND where session monitoring is
>     supported, then a method by which an origin-field within a session
>     description is not guessable SHOULD be used.
> 
> specify HOW the protection is done so implementations are compatible?
> 
> ---

Many thanks to those who read the document so carefully!  

2. PINT MIB.

Well, the draft "Management Information Base for the PINT Services Architecture" 
(<draft-ietf-pint-mib-00.txt>) has been published by Dan and Myrali in October.
Please read it; it will go for the WG last call as soon as we clear the protocol
RFC.

3. New proposed PINT work item (Conference Calling)

A new version of "A proposal for new PINT building blocks with applications to
Conference Calling"           (<draft-ietf-pint-conf-01.txt>) was just issued by
Lev and posted to our Web site. Again, this work proposes the building blocks
for services that are outside of the present PINT charter; however, with these
blocks about ANY service may be constructed, and, in addition it fully . This
particular work got much (positive) interest from call party handling experts in
SG 11, of which later. Please feel free to comment on this.

4. Liaison with SG 11

Hui-Lan has introduced--on  behalf of ISOC--the PINT Protocol, MIB, and new
building blocks to WP 4/11, and Q.5/11. (She also introduced the SPIRITS draft
and Antti's draft.) All material was received well. The new ITU Recommendation
Q.1231 will describe supported PINT services. The architecture will be presented
in CS-4 (Draft ITU-T Recommendation Q.1244). Hui-Lan will report on this in more
detail in due time.

So, that is where we are right now.

With thanks for your support and best wishes for the year 2000,

Steve Bellovin
Igor Faynberg

---------
This message came from the IETF PINT Working Group Mailing List.


From owner-pint-outgoing@lists.research.bell-labs.com  Wed Jan 26 07:18:06 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01430
	for <pint-archive@odin.ietf.org>; Wed, 26 Jan 2000 07:18:06 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3A28752E7; Wed, 26 Jan 2000 07:15:24 -0500 (EST)
Delivered-To: pint-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A1A6752E8; Wed, 26 Jan 2000 07:15:23 -0500 (EST)
Delivered-To: pint-local@paperless.dnrc.bell-labs.com
To: pint@lists.research.bell-labs.com
Date: Wed, 26 Jan 2000 07:11:24 -0500
Message-ID: <008c01bf67f6$3f458680$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
Sender: owner-pint@lists.research.bell-labs.com
Precedence: bulk

To: <Undisclosed-Recipient:@smtp1.cluster.oleane.net;>
Subject: SIP 2000 Call for Papaer
Date: Wed, 26 Jan 2000 13:09:46 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0089_01BF67FE.9E62EA60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0089_01BF67FE.9E62EA60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

SIP 2000: Beyond H.323? A scientific committe composed of the most =
eminent experts in this technology will review the abstracts submitted =
from the Call For Papers:
http://www.upperside.fr/basip.htm
Take a look at the exhibition list.


------=_NextPart_000_0089_01BF67FE.9E62EA60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>SIP 2000: Beyond H.323? A scientific =
committe=20
composed of the most eminent experts in this technology will review the=20
abstracts submitted from the Call For Papers:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Take a look at the exhibition=20
list.</FONT></FONT></DIV></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0089_01BF67FE.9E62EA60--


---------
This message came from the IETF PINT Working Group Mailing List.