Subject: RE: [Sip] Expert review fordraft-allen-sipping-poc-p-answer-state-header-01

From: "Andrew Allen" <[email-masked]>
Date: Tue, 3 Jan 2006 00:52:36 -0500

Jerome,

No I didn't consider this was necessary. 

In fact the need for a parameter at all in the P-Answer-State header is
really only for completeness and to ensure that you can positively
indicate a confirmed response since a value of "Confirmed" in the
P-Answer-State header in a 200 OK has the same semantics of a 200 OK
without the P-Answer-State header.

Andrew

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Tuesday, December 20, 2005 3:42 PM
To: Cullen Jennings
Cc: Andrew Allen; Dean Willis
Subject: Re: [Sip] Expert review
fordraft-allen-sipping-poc-p-answer-state-header-01

Andrew, Cullen,

Brief question: Did you consider to allow generic parameters in the
P-header 
(even though none are defined right now?)
I remember someone saying that this was commonly done for new SIP
headers, 
it wouldn't be the first time that in hindsight we'd like to add a 
parameter...

Regards,

jeroen

----- Original Message ----- 
From: "Dean Willis" <[email-masked]>
To: "Sip" <[email-masked]>
Cc: "Andrew Allen" <[email-masked]>; "Cullen Jennings"
<[email-masked]>
Sent: Tuesday, December 20, 2005 8:34 PM
Subject: [Sip] Expert review 
fordraft-allen-sipping-poc-p-answer-state-header-01

>
> Andrew has submitted the new OMA PoC P-header draft  draft-allen- 
> sipping-poc-p-answer-state-header-01.
>
> We've been asked by OMA to complete an expert review of this draft 
> according to the process specified in RFC 3427, the SIP Change
Process.
>
> I've asked Cullen Jennings to take a look at the draft and see if
he'll 
> be willing to provide the expert review.
>
> In conjunction with that, it would be nice if we could all read the 
> draft, and send any pertinent comments to the list and the author.
>
> Thanks,
>
> --
> Dean Willis
> SIP 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 

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

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Jan 2006 18:31:47 -0500

I side with Jerome on this. It is just good insurance for the future. 
Not providing for this can prove unfortunate in the future.

For example, the P-Asserted-Identity header is defined to not take 
parameters at all. It has recently started to look like parameters on 
that header would be an excellent way to assert roles for the identity. 
But that option is not available because the existing definition is not 
extensible for parameters.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 10 Jan 2006 09:58:39 -0500

> Not providing for this can prove unfortunate in the future.

If there is anything the history of the Internet has taught us it is
"Allow for upward-compatible extensions."

This is especially sensible in a case like this, where all we need to do
is provide a minimal extension to a parser to permit (and ignore)
parameters.

Dale
-- 
interop.pingtel.com -- the public SIP phone interoperability test server