Subject: RE: Some initial queries/comments on draft-ietf-sip-183-00.txt

From: "Donovan, Steven R." <[email-masked]>
Date: Thu, 28 Oct 1999 14:48:06 +0000

Dave,

Thanks for the comments.  Please see my comments below.

Steve

-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: Monday, October 25, 1999 1:05 PM
To: [email-masked]
Subject: Some initial queries/comments on draft-ietf-sip-183-00.txt

Thanks for all the careful work on this guys! Here are few questions and
comments based on my initial reading:

1) you don't make clear which pieces of this are intended to be specific to
the 183 response message and what pieces are intended to be generic. For
example, it would seem that the "Session: media/qos/security" header is much
more generic. In the abstract and introduction, it might be best to say
you're making TWO extensions to SIP, the Session header, and the 183
response.

SRD> I agree.  This is an artifact of the concept being agreed to at a late
date and my not having enough time to craft the draft in the manner you
suggest.

2) This may just be me having shell shock flashbacks to my ISO days, but I
cringe when I read all these "shalls" in section 2.1. All of them read much
better if replaced by "should".

SRD> My apologies for inducing nightmares.  However, section 2.1 is there to
outline the requirements by which the solution to the PSTN interworking
issue is measured.  If the solution (in this case, 183 and the Session
header) does not support all of these requirements than it is not a
sufficient solution.  These are not protocol level requirements statements.

3) following on from the logic above in point 1, it is implied but not
stated that the "Session": header could be placed on the initial (or
subsequent) INVITE. This certainly makes sense for the qos & security forms,
and could conceivably be useful for the "media" form as well.

SRD> I'd like to hear other opinions on this one.  I have received some
pushback in the past when I proposed this.  I personally agree that it would
be useful for the QoS and Security cases.  I'm not sure I see an example for
the media case, at least not until we have session descriptions that do not
imply media.

4) I know this may be a can of worms, but if we ever want to allow multiple
SDP bodies in SIP messages it would behoove us to ensure that headers that
refer to body part treatment can explicitly say WHICH body instance they
refer to.

SRD> Worms can get so messy...  Why would there be a need for multiple SDP
message bodies?

5) the MUSTs in section 4.2/4.3 seem a bit strong. Nothing breaks if the
sender is slow or sloppy at stopping; the user might get some mixed audio or
be annoyed though. While I can't off the top of my head think of any
positive use for the continued transmission (maybe the "call is being
monitored" beep tone...") I'd like to hear why such strong prohibition is
called for. There is also the philosophical question of what actually
constitutes "temporary" media, especially in the case where the SDP
describing the "permanent" media is identical to the SDP describing the
"temporary" media.

SRD> I agree.  I will change this unless I hear other arguments.

6) Section 4.4, second paragraph. While I see that 183 may not be
appropriate for ringing, forwarding, or queued (since we have other
responses for these), the used of Session: media may be perfectly
appropriate. Is this just another instance of not becing clear about the
relative independence of the Session: header and the 183 response?

SRD> I don't see that paragraph indicating that a 183 with Session: media is
not valid.  Am I missing something?

---

From: "David R. Oran" <[email-masked]>
Date: Sun, 31 Oct 1999 19:40:57 -0500

RE: Some initial queries/comments on draft-ietf-sip-183-00.txtSome
clarifications:
  -----Original Message-----
  From: Donovan, Steven R. [mailto:[email-masked]]
  Sent: Thursday, October 28, 1999 10:48 AM
  To: 'David R. Oran'; [email-masked]
  Subject: RE: Some initial queries/comments on draft-ietf-sip-183-00.txt

  Dave,

  Steve

  -----Original Message-----
  From: David R. Oran [mailto:[email-masked]]
  Sent: Monday, October 25, 1999 1:05 PM
  To: [email-masked]
  Subject: Some initial queries/comments on draft-ietf-sip-183-00.txt

  1) you don't make clear which pieces of this are intended to be specific
to
  the 183 response message and what pieces are intended to be generic. For
  example, it would seem that the "Session: media/qos/security" header is
much
  more generic. In the abstract and introduction, it might be best to say
  you're making TWO extensions to SIP, the Session header, and the 183
  response.

  SRD> I agree.  This is an artifact of the concept being agreed to at a
late date and my not having enough time to craft the draft in the manner you
suggest.

  2) This may just be me having shell shock flashbacks to my ISO days, but I
  cringe when I read all these "shalls" in section 2.1. All of them read
much
  better if replaced by "should".

  SRD> My apologies for inducing nightmares.  However, section 2.1 is there
to outline the requirements by which the solution to the PSTN interworking
issue is measured.  If the solution (in this case, 183 and the Session
header) does not support all of these requirements than it is not a
sufficient solution.  These are not protocol level requirements statements.

  Eventually we will run into an editing problem if this winds up an
independent RFC, because IETF-speak does not have a well-defined normative
meaning for SHALL, and forces you to define your terms. I don't think this
is such a big deal, but the fact is that either the requirements make sense
or they don't and putting strong language doesn't really affect the outcome.
As the silly Yoda-ism says, "either do or not do". Perhaps the rest of the
WG doesn't have such a kneee-jerk reaction to ITU-speak.

  3) following on from the logic above in point 1, it is implied but not
  stated that the "Session": header could be placed on the initial (or
  subsequent) INVITE. This certainly makes sense for the qos & security
forms,
  and could conceivably be useful for the "media" form as well.

  I don't have a good example for media either, except perhaps some kind of
SIP-based announcement service.

  4) I know this may be a can of worms, but if we ever want to allow
multiple
  SDP bodies in SIP messages it would behoove us to ensure that headers that
  refer to body part treatment can explicitly say WHICH body instance they
  refer to.

  Prediction is a difficult matter, expecially if it involves the future.
This may be stretching too much for an example, but imagine perhaps having a
SIP call for which you could choose to  participate in one of two sessions.
One session is multicast with a layered coder and the second describes how
to talk to an MCU.

  sender is slow or sloppy at stopping; the user might get some mixed audio
or

  SRD> I don't see that paragraph indicating that a 183 with Session: media
is not valid.  Am I missing something?

  What I was getting at is that the text seems to imply that this draft only
defines the behavior of Session: when carried in a 183 response, whereas I
would like it to define the sematics of Session: for all 1xx responses.

  Dave.

---

From: "David R. Oran" <[email-masked]>
Date: Sun, 31 Oct 1999 20:53:25 -0500

-----Original Message-----
  From: Donovan, Steven R. [mailto:[email-masked]]
  Sent: Thursday, October 28, 1999 10:48 AM
  To: 'David R. Oran'; [email-masked]
  Subject: RE: Some initial queries/comments on draft-ietf-sip-183-00.txt

  Dave,

  Steve

  -----Original Message-----
  From: David R. Oran [mailto:[email-masked]]
  Sent: Monday, October 25, 1999 1:05 PM
  To: [email-masked]
  Subject: Some initial queries/comments on draft-ietf-sip-183-00.txt

  Dave.