Subject: Editors' Response to the IESG Comments

From: Igor Faynberg <[email-masked]>
Date: Mon, 21 Feb 2000 21:54:19 -0500

Ladies and Gentlemen:

In our State of the WG message, Steve and I informed you about the IESG comments
in the Last Call process.

We are happy to say now that these comments have been addressed by our
editors--severe flu, terrible snowstorms, and heavy travel in addition to day
jobs--notwithstanding.

The new (version 3) PINT Protocol draft is now available (please see
http://www.ietf.org/internet-drafts/draft-ietf-pint-protocol-03.txt; you can
also pick it up from the IETF PINT page). In addition, Lawrence and Scott--to
whom many thanks!--provided detailed responses to specific comments and
suggestions as well as the summary of changes, which I am attaching to this
note.

Since we are not quite done with the immediate charter work, Steve and I see no
reason to meet in Adelaide.

With best regards,

Igor

ATTACHMENT:

Lawrence's responses (marked LWC)

Re mimetype comments:
LWC> Many thanks for the pointer to RFC2387.
LWC> multipart/related seems to be designed to indicate the kind of
LWC> situation we have in PINT, where sub-parts holding content are to be
LWC> processed along with a sub-part that holds the session description.
LWC> I've added a recommendation that it should be used, and a reference to
LWC> the RFC.

Re. minor typos:
LWC> Thanks for pointing them out. Fixed throughout. e.g. I've corrected
LWC> the spelling of call center. Duh!
LWC> Likewise, have changed should to SHOULD, fail to decline/reject, and
LWC> other small changes as suggested.
LWC> The rest is intended to be English, so if there are still
LWC> lapses into Swahili, please remind me.
LWC> On the same theme, I've tweaked the descriptions that follow a
LWC> couple of the examples; they were making assumptions that were not
LWC> warranted for the examples given.

Re. layout:
LWC> The document should now be in valid layout.

Re. major typos:
LWC> I must appologise for a great deal of confusion spread by my missing
LWC> the outdated "BYE" references thoughout the section on SUB/NOT/UNSUB.
LWC> These should ALL have been replaced with UNSUB.

LWC> The state model is really that simple, honest. I have not ASCIIfied
LWC> the SUB/NOT/UNSUB message sequence charts (I have then in PDF format
LWC> if that's useful, but they lose a lot in the conversion to ASCII).

Re.clarity of descriptions
LWC> I've taken the oppertunity (fixing major typo) to tweak the text in
LWC> 3.5.3 and in 3.5.8.; I hope that they are clearer now.

Re. Introduction
LWC> Similarly, the descrition of what PINT is trying to do in the
LWC> introduction has thrown some people, so I've tidied it up.
LWC> I've also put in a pointer to the summary lists in section 3.2,
LWC> so people can jump right to that rather than wading through
LWC> the service descriptions.

Re. Request-to-Fax and Request-to-Hear-Content service descriptions:
LWC> The service descriptions are a little terse, and so are open
LWC> confusion. I've added a couple of sentences to the Request-to-
LWC> -Hear-Content description, emphasising that how the PINT request
LWC> is formulated is not our problem, and the aim of a user is to
LWC> hear a translation of some content, or to have that content spoken.

LWC> I believe that it's called Request To Hear Content in the ITU
LWC> service description (if you look, you may notice some similarities)
LWC> so unless there's a good reason not to, perhaps it would be a good
LWC> idea to keep the heading name as is.

LWC> The Request-to-Fax description has obviously bemused people. The
LWC> aim is to ask for a fax to be sent to a fax machine that appears
LWC> to be connected to the PSTN. It was originally two services (Click
LWC> -to-Fax and Click-to-Fax-Back) and I believe that it still is
LWC> described as two services in the ITU docs.
LWC> The goal of either variant is to have a facsimile generated from
LWC> some content appear on a fax machine on the PSTN. If the content
LWC> is originally available "on the Internet" then by definition it
LWC> must be accessible to the PINT Gateway - it has to be transferred
LWC> to the destination fax machine somehow. If the information is
LWC> held on the PSTN, then it's a case of specifying that content and
LWC> where the facsimile is to be sent. The effect is the same, however.

Re. the use of UNSUB from either partner to end the monitoring session:
LWC> There was a discussion of the use of NOTIFY with Expires:0 to
LWC> indicate that the sender (the PINT Gateway that was passing
LWC> status messages "up" to the PINT Client) wanted to close the
LWC> monitoring session.

LWC> My concern was that the Gateway might WELL want to send up
LWC> a status message that reported only transient state (like a "meter
LWC> pulse" or an "errored second") rather than something that has an
LWC> extended duration (like "the call has started"). These NOTIFY
LWC> messages could be indicated by an Expires of 0, with a similar
LWC> interpretation to "Expires:0" or "no-cache" in HTTP.
LWC> Being able to indicate the period of validity of a notification
LWC> seems to be "a good idea" to me; however, this precludes its use
LWC> to terminate a monitoring session.

LWC> The PINT Client terminates the session by sending an UNSUB message
LWC> so having the PINT Gateway do the same seemed a good solution.
LWC> To summarise, use of Call-ID to start a monitoring session, and
LWC> the use of a NOTIFY with Expires:0 is perfectly possible. It even
LWC> reduces the packet traffic for the case where the Entity asking for
LWC> the monitoring session is the one that made the service request in
LWC> the first place. However, this comes at a cost; in the case of
LWC> NOTIFY with Expires:0, there's no easy way to indicate a transient
LWC> status notification, and in the case of using Call-ID to start the
LWC> session, the Gateway must support another method when another UAS
LWC> wants to start a monitoring session (like, for example, a Server
LWC> that monitors corporate call usage).

LWC> This is just a re-iteration of the mailing list posts and drafts of
LWC> the last couple of years; if anyone interprets it differently then
LWC> perhaps we really DO need to expand the descriptions.

Scott's responses (marked SBP):

1. State Machine of SxBSCRIBE/UNSxBSCRIBE

SBP> The typos in the earlier draft obscured the fact that the state-machine
SBP> of SxBSCRIBE/UNSxBSCRIBE is now identical to that of INVITE/BYE. This 
SBP> was a major simplification. Anyone who understands the vanilla INVITE/BYE
SBP> message flow can understand SxBSCRIBE/UNSxBSCRIBE. We added a sentence 
SBP> in the newest draft to make this explicit.

SBP> We also added a sentence to make it clear that a SUBSCRIBE is sent to
SBP> the PINT gateway directly (if that is known from a previous Contact:
SBP> field) or to the server which got the original INVITE (if there was
SBP> no previous Contact: field). 

SBP> The suggestion that one use a NOTIFY with Expires:0 to mean "UNSUBSCRIBE"
SBP> was discussed at length in the mailing list, but the consensus was 
SBP> that one definitely needs an explicit "UNSUBSCRIBE" message. This
SBP> is because any other possibility already has meaning:
SBP> NOTIFY with Expires:0 means that the NOTIFY is only guaranteed to be
SBP> valid this instant (needed to show transient states in the PSTN).
SBP> SUBSCRIBE with Expires:0 means that the sxubscriber wants to get a 
SBP> single NOTIFY and then no more (Needed to allow clients to probe 
SBP> the state of a call once).

SBP> The nice thing about this solution is that SUB/UNSUB has the same state
SBP> machine as INVITE/BYE.

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