Subject: [Sipping] RE: draft-allen-sipping-poc-p-answer-state-header-04

From: "Andrew Allen" <[email-masked]>
Date: Wed, 18 Oct 2006 08:04:53 -0400

Paul,

I thought I would take this offline with you first before responding on
the list.

Comments below

Andrew

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, October 17, 2006 7:15 PM
To: Andrew Allen
Cc: sipping
Subject: Re: draft-allen-sipping-poc-p-answer-state-header-04

Andrew,

This is looking pretty much done. I found only a couple of things:

Section 6.4 says:

    A parameter value of "Confirmed" is only
    included in a SIP 200 OK response.

But 6.4.2 says:

    If the UAC part of a back-to-back UA of a PTT Server sent a SIP
    INVITE request as a result of receiving a SIP REFER Request,
receives
    a SIP 18x or 2xx response containing a P-Answer-State header field
at
    the UAC part of its back-to-back UA, then the UAS part of its back-
    to-back UA SHOULD include the P-Answer-State header field and its
    parameters from that response unmodified in the sipfrag of the
    response contained in a SIP NOTIFY request that the UAS part of its
    back-to-back UA sends in response to the SIP REFER request.

This means that a Confirmed can be included in a NOTIFY. (But only a 
NOTIFY of a 200.)

[AA] This is true but the parameter value is the header field parameter
value as this text discusses. The header and its parameters are only
included in the SIP part of a 200 OK. The reception of the 200 OK
containing the Header with the Confirmed parameter can also be notified
in a SIP Frag but the header is not included in the Notify. The text was
discussing where the header and value were used as far as the SIP use of
the SIP header. Do you think this really needs clarification? I suppose
I could add "or in the SIP Frag of a 200 OK included in a Notify)" to
the end of the sentence in 6.4 if its needed.

The usage of REFER always seems to mention of sending of the REFER 
within an INVITE dialog. There should probably also be procedures for 
doing this with a separate dialog, since shared dialog usages are so 
unpopular.

[AA] This is the way it's done in OMA PoC right now. I thought P-headers
were only supposed to outline the way they used or could be potentially
used in their specific application space. It is not clear how without
sending the Refer on the same dialog as was used to establish the
pre-established session the receiving server knows which session
(because there could potentially be others) to connect with when it
establishes a session to the other party using Refer (kind of third part
invitation). I suppose the Target-Dialog header might be used to achieve
this but this usage has not been discussed within IETF yet to my
knowledge or in OMA and I really hesitate to bring this discussion up at
this late stage. Can you live with it as it is?

	That's it,
	Paul

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Oct 2006 10:20:01 -0400

Andrew Allen wrote:
> the SIP header. Do you think this really needs clarification?

I think it would help.

> I suppose

Sounds good to me.

> used in their specific application space.

Hmm. I wasn't thinking about special rules for P-headers. I'm not sure 
if that makes a difference here or not.

But I see a consistent story of P-headers being defined narrowly and 
then later turning out to be too restrictive. I'm not sure what the 
right balance is.

Anybody else have insight into this?

> It is not clear how without
> knowledge

AFAIK this is precisely the usage that Target-Dialog was introduced for.

> or in OMA and I really hesitate to bring this discussion up at

Yes.

Here I am trying to go with the concensus view about shared dialog 
usages. Personally I don't find them objectionable when used appropriately.

	Paul