Subject: [sipcore] Info-events and Request-Disposition etc.

From: "Elwell, John" <[email-masked]>
Date: Tue, 3 Nov 2009 14:40:23 +0100

The info-events draft does not mention the Request-Disposition header field. However, in RFC 3841, Request-Disposition is indicated as optional in INFO requests. Similarly for Accept-Contact and Reject-Contact. So there is an apparent contradiction, which we should try to put right.

I fail to see the purpose of these header fields in an INFO Request, which can occur only on an INVITE-initiated dialog. Therefore I think the info-events draft is correct. Does this therefore mean that the draft updates RFC 3841, and if so do we need to make explicit mention of the fact that RFC 3841 is updated by removing the option of these header fields in an INFO request?

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Nov 2009 11:16:33 -0500

> I fail to see the purpose of these header fields in an INFO Request, which can occur only on an INVITE-initiated dialog. Therefore I think the info-events draft is correct. Does this therefore mean…

Well, IMO the Request-Disposition was very underspecified.
Also, the possibility of 3xx responses to in-dialog requests is 
underspecified.

*If* its possible to get a 3xx response to an INFO request, then the 
Request-Disposition might be desired to control how a proxy deals with it.

It would be nice to clarify all of that, but this isn't the place to do it.

So I would recommend that this draft *not* update 3841.
I would try to avoid addressing the subject at all.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 3 Nov 2009 17:33:29 +0100

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 03 November 2009 16:17
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [sipcore] Info-events and Request-Disposition etc.
> 
> 
> 
> Elwell, John wrote:
> > The info-events draft does not mention the 
> Request-Disposition header field. However, in RFC 3841, 
> Request-Disposition is indicated as optional in INFO 
> requests. Similarly for Accept-Contact and Reject-Contact. So 
> there is an apparent contradiction, which we should try to put right.
> > 
> > I fail to see the purpose of these header fields in an INFO 
> Request, which can occur only on an INVITE-initiated dialog. 
> Therefore I think the info-events draft is correct. Does this 
> therefore mean that the draft updates RFC 3841, and if so do 
> we need to make explicit mention of the fact that RFC 3841 is 
> updated by removing the option of these header fields in an 
> INFO request?
> 
[JRE] That would be fine with me, as long as it is understood that there are issues with RFC 3841 that we will not attempt to address in this draft. The question arose from some discussions involving ETSI TISPAN and 3GPP CT1, where 3841 seems to be taken as evidence these header fields can be used in INFO.

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Nov 2009 19:09:43 +0100

Hi,

Keith commented on the R-D header field in his comments, and the
following will be added to the header field table:

"Request-Disposition         R       o"

Other than that I don't think we need to say anything, but we shall not
deviate from 3841.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
Sent: 3. marraskuuta 2009 18:33
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [sipcore] Info-events and Request-Disposition etc.

> Request-Disposition is indicated as optional in INFO requests. 
> Similarly for Accept-Contact and Reject-Contact. So there is an 
> apparent contradiction, which we should try to put right.
> > 
> therefore mean that the draft updates RFC 3841, and if so do we need 
> to make explicit mention of the fact that RFC 3841 is updated by 
> removing the option of these header fields in an INFO request?
> 
> Request-Disposition might be desired to control how a proxy deals with

> it.
[JRE] That would be fine with me, as long as it is understood that there
are issues with RFC 3841 that we will not attempt to address in this
draft. The question arose from some discussions involving ETSI TISPAN
and 3GPP CT1, where 3841 seems to be taken as evidence these header
fields can be used in INFO.

John

> 	Paul
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Nov 2009 13:31:09 -0500

> [JRE] That would be fine with me, as long as it is understood that there are issues with RFC 3841 that we will not attempt to address in this draft. The question arose from some discussions involvi…

IMO it would be ok to include something in this doc that says its not 
trying to address any issues with R-D.

I just think trying to solve that here is a rat hole.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Nov 2009 19:34:20 +0100

Hi,

There are lots of headers we don't say anything about. 

But, I think the header table shall be as complete as possible, and
alligned with the RFCs which specify the headers.

Otherwise the table is useless, and just messes things up for people
using it for comformance testing etc.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: 3. marraskuuta 2009 20:31
To: Elwell, John
Cc: [email-masked]
Subject: Re: [sipcore] Info-events and Request-Disposition etc.

Elwell, John wrote:
> [JRE] That would be fine with me, as long as it is understood that
there are issues with RFC 3841 that we will not attempt to address in
this draft. The question arose from some discussions involving ETSI
TISPAN and 3GPP CT1, where 3841 seems to be taken as evidence these
header fields can be used in INFO.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 3 Nov 2009 21:14:39 +0100

If we just stay in line with RFC 3841 and specify that these header fields are allowed in an INFO request, even though they appear to be meaningless, then if, at some point in the future, we update RFC 3841, aren't we going to go round in a circle and say we don't want to contradict the info-events RFC? We have to bite the bullet at some stage. Or do you believe that these header fields do serve some purpose in INFO, and that a future version of RFC 3841 would clarify their use?

John 

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 03 November 2009 18:10
> To: Elwell, John; Paul Kyzivat
> Cc: [email-masked]
> Subject: RE: [sipcore] Info-events and Request-Disposition etc.
> 
> 
> Hi,
> 
> > It would be nice to clarify all of that, but this isn't the 
> place to 
> > do it.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Nov 2009 15:26:50 -0500

> If we just stay in line with RFC 3841 and specify that these header fields are allowed in an INFO request, even though they appear to be meaningless, then if, at some point in the future, we update…

Its possible (though unlikely).

I think there may be some obscure cases where forking may occur 
mid-dialog. And its always been an open issue what happens if you get a 
3xx response to a mid-dialog request. It isn't excluded but also isn't 
defined. In cases like those, there may be a role for a proxy to use the 
R-D header to decide how to handle the forking, etc.

Its far fetched. But I see no advantage to making a gratuitous change to 
3841 at this point without having considered any of those issues. I 
think it does less harm to leave well enough alone.

	Thanks,
	Paul

On an unrelated note, do you notice how we all use notations like R-D, 
I-P, C-T, C-D, etc.? It would have been much nicer if sip had made 
provision for that sort of short form header names rather than the 
single letter forms. Of course they still aren't unique, but close 
enough for most purposes.

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Nov 2009 21:58:20 +0100

Hi,

If we in future update 3841, then we have to take the consequences. But,
that can then be done in a more controlled manner than starting to
"update" 3841 in different drafts all over.

If the header has no purpose in INFO, then nobody is going to use it. It
is optional to use.

Regards,

Christer 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 3. marraskuuta 2009 22:15
To: Christer Holmberg; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [sipcore] Info-events and Request-Disposition etc.

If we just stay in line with RFC 3841 and specify that these header
fields are allowed in an INFO request, even though they appear to be
meaningless, then if, at some point in the future, we update RFC 3841,
aren't we going to go round in a circle and say we don't want to
contradict the info-events RFC? We have to bite the bullet at some
stage. Or do you believe that these header fields do serve some purpose
in INFO, and that a future version of RFC 3841 would clarify their use?

John 

> Other than that I don't think we need to say anything, but we shall 
> not deviate from 3841.
> 
> Regards,
> 
> Christer
> 
>