Subject: Re: [Sip] WGLC for Update draft

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 Apr 2002 18:11:51 -0400

Jo,

Thanks for your comments. Responses inline:

Jo Hornsby wrote:
> 
> 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/

Fixed.

> 
>  * 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?

Thats the question. I think you'd generally need to query the user,
although its not unreasonable for a user to configure their UA to
automatically retry 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?

100rel is about reliability of provisional responses, which is not in
bis at all (anymore)... I think the reference is right as it stands.

> 
>  * 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?

Hmm, thats a good point. I think this paragraph can stay as it is, but
instead, section 5.2.1 should say that, if supported, the uas SHOULD
request an update instead of generating the repairable error response. 

> 
>  * 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?

[5] is sip-events, I don't get it?

> 
>  * 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?

Only the market can decide that.

>     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?

This really isn't different than any other extension. I'll note the
issue though.
> 
>  * 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.  &:(

No, that seems to be the right thing. Changed.

> 
>  * 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. &:)

Now that the draft has been split into two (UPDATE and 155), Reason is
part of the 155 stuff. It wasn't there initially for process reasons,
which are now moot.

> 
>  * 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?

THe 1xx need not have been sent reliably; 100rel requires it, but
baseline bis doesn't (although the words are kind of vague in the spec). 

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

Fixed.

> 
>  * 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?

See above.

> 
>  * 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?

Its just transition text; I'll clean up.

> 
>  * 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?

UPDATE has the semantics of the request which created the dialog on
which its sent. However, I must admit that this makes me kind of
queasy... This bit about INVITE vs. SUBSCRIBE is only an issue for the
herfp usage, now in a separate draft. We have the opportunity now to
consider whether that is the actual semantic we want.

> 
>  * 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.

This is an odd exception, due to the fact that 155 isn't *really* the
response. Really, the response is an error response, and the SDP is the
capabilities of the UAS, as would be present in a 488.

> 
>  * 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.

We had a whole thread on this. The conclusion was that the UAS needs to
be prohibited from sending an UPDATE with an offer if it has sent SDP in
a 1xx for which it hasn't gotten a PRACK yet. We can't disallow offers
in PRACK, since it is too late for that. The reason for it was pressure,
as I recall, from manyfolks, to allow for the baseline manyfolks
exchange without an extra transaction (remember the 3gpp guys want to
keep the transaction count down). 

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

Fixed.

> 
>  * 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.

OK. Anything to save your sanity.

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

Fixed.

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

OK.

> 
>  * 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.

No, this paragraph is avoiding infinite 155 loops. You are talking about
a different proble, which I don't think is discussed, and needs to be. I
suppose it is OK to generate another 155 in this case. 

> 
>  * 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. &:)

Per other threads, this has been changed to a MAY.

> 
>  * 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?

No. Fixed.

>     o Contact: 3xx:
>       Should be "d"?

Yup.

>     o Content-Length:
>       Should be "ar".

yup.

>     o Error-Info:
>       Should be "a"?

yup.

>     o Organization:
>       Should be "ar".

Yup.

>     o Priority: through Record-Route::
>       Need aligning with Table 3 of bis-09.

yup.

>     o Require:
>       Not sure what "c" means here.

Fixed.

>     o Route:
>       Should be "adr".

yup.

>     o Via:/WWW-Authenticate::
>       Require alignment with Table 3 of bis-09.

Fixed.

> 
>  * Table 1/2; "UPDATE" column:
>     o Allow: 405:
>       Should be "m"?

yup.

>     o Contact: R/2xx:
>       Should be "m"?

Hmm. Its not strictly needed, but since its a target refresh request, it
probably has to be there....

>     o Min-Expires: 423:
>       Should be "m"?

For the subscribe usage, yes, but since update and herfp are split, the
baseline update won't need it, so its a -.

>     o Unsupported: 420:
>       Should be "m"?

yup.

>    Same issues with aligning with bis-09 Tables
>    in terms of Proxy-Authenticate/
>    Record-Route/Via/WWW-Authenticate; specifically,
>    the "where" column.

Right. Sadly, I copied this table from an older version of bis, before
we have a major overhaul, and it got out of sync. I re-aligned.

> 
>  * 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?

yup.

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

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¬ (:&).

Yes, you 487. No different than any other mid-dialog request outside of
an active 
dialog.

Thanks for your comments.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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