Subject: State of the Working Group

From: Igor Faynberg <[email-masked]>
Date: Tue, 11 Jan 2000 18:47:02 -0500

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.