Subject: [Sip] WGLC for Update draft

From: "Dean Willis" <[email-masked]>
Date: Sun, 10 Mar 2002 16:11:15 -0600

We'd like to open discussion for working group last call on:

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-update-01.txt

This is part of the "Bundle 2" group needed by 3GPP.

The working group last call discussion period will close immediately after
IETF 53, eta March 25, with the intent to move to IETF Last Call as soon as
possible therafter.

--
Dean Willis
SIP WG Co-Chair

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jo Hornsby" <[email-masked]>
Date: Sat, 16 Mar 2002 00:26:44 -0000

Okay, so here's my comments.  Apologies for any dups.

 * Section 1; Paragraph 2;
   Sentence beginning "While this is reasonable":
   s/where it this/where this/

 * Section 3:
   Would it perhaps be possible to also include
   493?  Is there a case where a UAC could
   automatically Do The Right Thing in this case?

 * Section 4; Paragraph 2:
   I'm not quite sure what the differentiation
   is between 2543bis and 100rel, but shouldn't
   the reference here also be referencing the
   RFCxxxx?

 * Section 4; Paragraph 4:
   I am unsure as to the motivation for this?
   Wouldn't it just be better to always do 155
   because, certainly at least in the first
   instance, a large number of proxies are
   going to be UPDATE-ignorant?

 * Section 4; Paragraph 5:
   I'm not quite sure what the differentation
   is between 2543 and sip-events, but shouldn't
   the reference here also be referencing the
   RFCyyyy?

 * Section 5.1; Paragraph 2:
   I think the "MAY" worries me.  Is the
   expectation that a large number of UAs are
   going to support this quite quickly?  Else
   this looks like something that could break
   interoperability with a sledgehammer.
   Perhaps there should be a note about how
   this is slightly dangerous, unless the
   UA has advanced knowledge of the network/
   peer UA?

 * Section 5.2.1; Paragraph 1:
   See, here I think if we upgraded the "MAY"
   to a "SHOULD", we could probably knock out
   the bit about a proxy flicking the Require:
   update switch on.  But, I'm worried I'm
   missing something blindingly obvious.  &:(

 * Section 5.2.2; Paragraph 2:
   I was going to suggest using the Reason
   header here (header inspection I found a
   little too icky), but then I referred back
   to Reason:, and now I get the feeling that
   this change is already in the pipeline. &:)

 * Section 5.3; Paragraphs 2/3(motivational):
   Minor point, but 100rel makes the creation
   of an "early dialog" a MUST.  Obviously,
   this does no harm, but perhaps the
   redundancy will cause confusion?

 * Section 5.3; Paragraph 7:
   s/proxy/UAC/

 * Section 5.3; Paragraph 7:
   Ah.  Here's the placeholder for Reason:.
   Now I'm betting this is a process issue --
   there's no way that Reason is going to
   be ready in time, right?

 * Section 6.1:
   I'm a little confused by the placement of
   this text, especially given the previous
   paragraph, which says much the same thing?

 * Section 6.1.1:
   I'm a little confused by the "In the case
   of INVITE".  Huh?  Is it like in the
   case of a _session_ created by an INVITE?

 * Section 6.1.1; Paragraph 3:
   [BTW, vertical whitespace constitutes a
   paragraph to my warped mind.  I apologize
   if this is just silly.]
   Isn't this actually a contradiction with
   100rel, since that says that an answer
   must appear in the first reliable
   provisional response if there was an offer
   in the INVITE?  I realize that the 155
   is just a facade, but it probably needs
   to be called out that this is in fact okay.

 * Section 6.1.1; Paragraph 8;
   Sentence beginning "If the UPDATE":
   Should it be explicitly pointed out that
   the "reliable provisional response" must
   have beed PRACKed; and possibly responded
   to, if the PRACK contained an offer?
   In fact, there is some horrible potential
   for out-of-order with 2xx-to-PRACK and
   UPDATE here.  Hmmm....  This may be a
   tad radical, but couldn't we just rule
   out sending offers in PRACKs when a
   dialog is UPDATE-capable?  The only
   downside I can see is extra
   request/response pairs when a UAC wants
   to update session parameters at the exact
   same time a UAS returns a provisional
   response reliably.  This doesn't seem
   that likely to me beyond the first
   provisional response in an early dialog;
   but I have to admit that I'm manyfolks-
   ignorant, so it might be of utmost
   importance there.

 * Section 6.1.1; Last Paragraph:
   s/Section 4.1/Section 14.1/

 * Section 6.2; Paragraph 2:
   Might be nice to reference Section 12.2 of
   RFC BBBB here.  Just a thought -- it'll
   doubtless save my sanity later.

 * Section 6.2; Paragraph 4;
   Sentence beginning "Once the application":
   s/response to request/response to the request/

 * Section 6.2.1; Paragraph 2;
   Sentence beginning "The original request":
   I'd be inclined to append "for example".

 * Section 6.2.1; Paragraph 2:
   Is this paving the way for retrying an
   UPDATE?  (For example: challenge to INVITE
   in 155; UPDATE with credentials; now the
   UAS realizes that it doesn't grok the media,
   so 488 in 155.)  This probably needs to
   either be explicitly allowed or otherwise.

 * Section 7:
   Personally, I see this as the wrong approach
   for maintaining backward compatibility.
   Although the work that the proxy has to do
   is somewhat trivial, it seems far more likely
   that a UA is going to support this extension
   than a proxy.  This means that it's not
   entirely unlikely that UAs will just not
   use UPDATE because a proxy is forking but
   not doing the Require.  Also, how likely is
   it that a UA that isn't UPDATE-aware is
   going to be fly enough to accept resubmitted
   requests that are virtual merges?
   Well, I've said my bit. &:)

 * Table 1/2; "proxy" column:
   [I'm comparing the same table in bis-09]
    o Alert-Info/Call-Info:
      Is there any reason this is "am" here as
      opposed to "ar" in bis-09?
    o Contact: 3xx:
      Should be "d"?
    o Content-Length:
      Should be "ar".
    o Error-Info:
      Should be "a"?
    o Organization:
      Should be "ar".
    o Priority: through Record-Route::
      Need aligning with Table 3 of bis-09.
    o Require:
      Not sure what "c" means here.
    o Route:
      Should be "adr".
    o Via:/WWW-Authenticate::
      Require alignment with Table 3 of bis-09.

 * Table 1/2; "UPDATE" column:
    o Allow: 405:
      Should be "m"?
    o Contact: R/2xx:
      Should be "m"?
    o Min-Expires: 423:
      Should be "m"?
    o Unsupported: 420:
      Should be "m"?
   Same issues with aligning with bis-09 Tables
   in terms of Proxy-Authenticate/
   Record-Route/Via/WWW-Authenticate; specifically,
   the "where" column.

 * Table 2:
   "copied with possible addition of tag" I don't
   think makes sense here, since there's always
   going to be a tag, right?

 * Section 12.3:
   CopyPaste error?  (Should be talking about the
   155, right?)

Finally, is any normative behaviour required for
the case when an UPDATE is received after, say, the
initial INVITE has completed unsuccessfully?
An obvious case where this could happen, that I
can think is where a CANCEL has been issued, and
theres vague racing going on.  I'm guessing you
just 487, but perhaps this should be spelled out?
(Especially if you don't 487¬ (:&).

And I'm done.

 - Jo.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 16 Mar 2002 17:40:16 +0200

Hello,

>    ignorant, so it might be of utmost

I would like to rule it out as well. The problem here is that offers in
PRACKs cannot be refused. Glare is not a problem, because the UAS will
not generate an update if it has an unPRACKed 1xx response, but if the
offer in the PRACK is not acceptable, the UAS cannot refuse it, because
the PRACK has to be answered with a 200 OK anyway.

So, either an error response for a PRACK indicating that the session
description was not accepted is allowed (the same mechanism that exists
for UPDATE) or we rule out offers in PRACK.

Regards,

Gonzalo