Subject: [Sip] Comments on sip-info-events-01

From: "Elwell, John" <[email-masked]>
Date: Sat, 08 Nov 2008 18:27:07 +0000

Eric,

Some comments:

- "and negotiate
   packages from the UAS' subsequent responses and the ACK"
The UAS doesn't send ACK.

- "Once a UAC advertises it is willing to receive a package, it MUST be
   ready to receive INFO methods carrying that package type.  This is
   because the UAS MAY send such INFO requests at the same time as the
   UAS sends its confirming Send-Info header, and the request may arrive
   out of order.  This also enables early exchange of INFO methods."
This does not recognise the fact that the UAS may advertise first (in a
response), in which case the UAS is subject to a similar rule. This
paragraph should be made direction-agnostic.

- "  Similar rules apply for late Send-Info / Recv-Info negotiation,
such
   as an empty INVITE, followed by an offer in the 200 OK and the
   response in the ACK."
I think this is too vague for a normative section. In fact, as it is,
this statement is not normative, but there should be normative
statements regarding receiving in 1xx/2xx (not having sent in INVITE
request) and sending in ACK request.

- I think I suggested once before that we should not treat
Send-Info/Recv-Info exchanges like offer/answer, but should just have a
simple rule that says that a UA can send these header fields at any time
and they supersede any sent previously. A UA MUST not send INFO unless
the package has been identified in the last Send-Info sent and the last
Recv-Info received. A UA MUST (SHOULD?) discard a received INFO unless
the package has been identified in the last Recv-Info sent, and MUST be
prepared to receive an INFO for a package as soon as it has sent a
Recv-Info identifying that package. These header fields MAY be included
in an INVITE request, in a dialog-forming response to an INVITE request,
or in any other request or response in the context of an early or full
INVITE-initiated dialog. This would be a lot simpler. Is there any
reason it would not work? I am not certain I have enumerated all the
rules here, but I doubt if very much more would need to be said
normatively.

Another advantage of this would be that there would be no need to use
the special terminology in section 3 whereby UAC is specifically the UAC
for the INVITE request and the UAS is the UAS for the INVITE request.
This gets particularly confusing when considering a re-INVITE or UPDATE
request initiated by the UA that was the UAS for the original INVITE
request. Furthermore, in section 4 terminology reverts to the more
orthodox meanings of UAC and UAS. So even if we don't adopt my
suggestion above for getting rid of pair-wise exchanges of
Send-Info/Recv-Info, I think something should be done to avoid the
unorthodox terminology in section 3.

- "If the payload of the INFO method has multiple body parts, the UAC
   SHOULD identify which body part belongs to a given Info Package.  The
   UAC does this by adding the modifier ";cid=<identifier>" to the Info-
   Package header field value, where "<identifier>" is the Content-ID
   MIME header value corresponding to the body part associated with the
   Info-Package.  The sole exception to this rule is if the particular
   Info Package carries no payload.  In this case there will be no body
   part associated with the Info Package and thus there will be no
   Content-ID to reference.  In this case, the UAC MUST NOT include the
   "cid" modifier."
Why not simply say:
"If the payload of the INFO method has multiple body parts, the UAC
   MUST identify which body part (if any) belongs to a given Info
Package.  The
   UAC does this by adding the modifier ";cid=<identifier>" to the Info-
   Package header field value, where "<identifier>" is the Content-ID
   MIME header value corresponding to the body part associated with the
   Info-Package. Some Info Packages may not involve the conveyance of a
body part."?
This would avoid using SHOULD - it is always preferable to use a
conditioned MUST.

- "1.  Recall the response code to an INFO method request relates to the
       INFO method request itself, "
Nothing has been stated previously about response codes to INFO
requests, so it is difficult to recall this! Delete "Recall".

"If the UAS receives an INFO request with a Info-Package the UAC
   advertised with a Send-Info in the last dialog state update"
It was not clear to me that every dialog state update MUST contain
Send-Info/Recv-Info. In other words, if I send an UPDATE request without
these header fields, e.g., for session timer refresh, does this cancel
any previous negotiation of Info Packages? I would prefer that it did
not, that it simply left things unchanged.

- "If a server receives an INFO request with a body it understands, but
   it has no Info-Package header, the UAS MAY render the body."
This is the first mention of "render". In fact there is nothing to say
that a UAS must/should/may render a body when an INFO request is not in
error, so it seems odd to talk about rendering when there is an apparent
error in the INFO request. Is "rendering" necessarily the appropriate
thing to do with a received and valid INFO request. Should we instead
say "...the UAS MAY make use of the body"?

- "The UAS MUST send a 481 Call Leg/Transaction Does Not Exist message
   if the INFO request does not match any existing dialog."
Shouldn't this say "...does not match any INVITE-initiated dialog"?

- "The INFO message MUST NOT change the state of the SIP dialog.  The
   only exception to this rule is for specific failure responses as
   documented in RFC 5057 [RFC5057], which may cause the INVITE dialog
   to terminate."
It is odd to say "MUST NOT" and then state that there is an exception.
Should it be a "SHOULD NOT"?

- "A UAC, the sender of the OPTIONS request, MAY include Send-Info and
   Recv-Info headers, populated appropriately for the packages the UAC
   supports.  The UAS MAY include its set of Send-Info and Recv-Info
   packages.  The UAS and UAC MUST NOT consider the OPTIONS request to
   be part of a capabilities negotiation.  The OPTIONS request is purely
   a probe."
The semantics of these header fields in an INVITE request or another
message in an INVITE-initiated dialog means I am prepared to
send/receive these packages in the context of this dialog. However, for
OPTIONS there is no dialog. So what exactly are the semantics of these
header fields in OPTIONS request? Presumably it just means I support
these packages and may be prepared to send/receive them in the context
of an INVITE-initiated dialog. This should be clarified.

- "The UAS MAY include its set of Send-Info and Recv-Info
   packages."
Presumably this should say "... in a 2xx response to an OPTIONS
request".

- "For the UAC or UAS to renegotiate package support, they must use the
   procedures described in Section 3."
Change "renegotiate" to "negotiate" (since OPTIONS does not negotiate).

- "That is, when the
   UAC sends another INFO request before receiving a transaction
   response from the UAS to a prior INFO request."
This is an incomplete sentence. Presumably it should say "... the
requests can arrive at the UAS out of order".

- In 5.1, Why is Contact allowed in an INFO request but not in a 2xx
response to INFO? Since INFO is not allowed to change dialog state, it
cannot change target URIs, so what would be the meaning of Contact in an
INFO request. I think we should align with BYE and not allow Contact in
INFO.

- Why is Max-Breadth allowed in an INFO request, given that it cannot
fork?

- In 5.2, why are Send-Info and Recv-Info not allowed in UPDATE requests
and responses? In fact in 3.1 it says it is allowed.

- "For the purposes of matching Info Package types indicated in Send-
   Info or Recv-Info with those in the Info-Package header field value,
   one compares the Info-package-name portion of the Info-package-type
   portion of the "Info-Package" header byte-by-byte with that of the
   same in the "Send-Info" or "Recv-Info" header values."
Presumably comparison is case-sensitive. Should we state this?

John

_______________________________________________
Sip mailing list  https://www.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: Sun, 09 Nov 2008 23:10:23 -0500

Some followups to John's comments. I've trimmed down to relevant stuff.

	Thanks,
	Paul

> rules here, but I doubt if very much more would need to be said

I think this will work as long as he contents of these headers on one 
side are not coupled with those on the other side. IOW, I should be able 
to mention a package in Recv-Info even if it wasn't mentioned by the 
other side, and visa versa.

But can somebody remind me why we need Send-Info at all?

However in any case we must accept that there is a race condition, when 
an INFO is in flight at the same time as a Recv-Info in the other 
direction that forbids sending it. I think that is fine - it will just 
be rejected, and that should not be considered a serious error.

> not, that it simply left things unchanged.

We need to be careful here, to prevent breaking 3pcc. If a transfer is 
done via 3pcc, how can we ensure that the desires of the unchanged party 
are made known to the transfer target? This could be ensured that the 
Send-Info/Recv-Info headers are always sent when an offer or answer is sent.

> say "...the UAS MAY make use of the body"?

Yeah, "render" could be quite confusing. Perhaps "process"?

> Shouldn't this say "...does not match any INVITE-initiated dialog"?

INVITE-dialog-usage?

(I could have a dialog that was initiated with an INVITE, then 
piggybacked with a SUBSCRIBE, then BYE to the INVITE, but subscription 
remains. That is still an INVITE-initiated dialog, but INFO isn't valid.)

>    documented in RFC 5057 [RFC5057], which may cause the INVITE dialog

This jogs another question in my mind. Is it permissible to pass 
Send-Info / Recv-Info headers in an INFO? If so, then IMO those change 
the state of the dialog.

> of an INVITE-initiated dialog. This should be clarified.

I agree. (I have similar problems with everything in an OPTIONS.)

> INFO request. I think we should align with BYE and not allow Contact in

Agree.

> Presumably comparison is case-sensitive. Should we state this?

By default I would assume case-insensitive behavior. That is the norm 
for most things. Is there a reason to be case sensitive here?

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 10 Nov 2008 06:00:16 +0100

> This jogs another question in my mind. Is it permissible to 
> pass Send-Info / Recv-Info headers in an INFO? If so, then 
> IMO those change the state of the dialog.

The answer is currently no.

INVITE and 1xx,2xx responses to INVITE, OPTIONS and 2xx responses to
OPTIONS.

REG was still under discussion although it is the draft.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
> Sent: Monday, November 10, 2008 4:10 AM
> To: Elwell, John
> Cc: SIP IETF
> Subject: Re: [Sip] Comments on sip-info-events-01
> 
> > Send-Info/Recv-Info exchanges like offer/answer, but should 
> just have 
> > a simple rule that says that a UA can send these header 
> fields at any 
> > time and they supersede any sent previously. A UA MUST not 
> send INFO 
> > unless the package has been identified in the last 
> Send-Info sent and 
> > the last Recv-Info received. A UA MUST (SHOULD?) discard a received 
> > INFO unless the package has been identified in the last Recv-Info 
> > sent, and MUST be prepared to receive an INFO for a package 
> as soon as 
> > it has sent a Recv-Info identifying that package. These 
> header fields 
> > MAY be included in an INVITE request, in a dialog-forming 
> response to 
> > an INVITE request, or in any other request or response in 
> the context 
> > of an early or full INVITE-initiated dialog. This would be a lot 
> > simpler. Is there any reason it would not work? I am not certain I 
> > have enumerated all the rules here, but I doubt if very much more 
> > would need to be said normatively.
> 
> I think this will work as long as he contents of these 
> headers on one side are not coupled with those on the other 
> side. IOW, I should be able to mention a package in Recv-Info 
> even if it wasn't mentioned by the other side, and visa versa.
> 
> However in any case we must accept that there is a race 
> condition, when an INFO is in flight at the same time as a 
> Recv-Info in the other direction that forbids sending it. I 
> think that is fine - it will just be rejected, and that 
> should not be considered a serious error.
> 
> > Send-Info/Recv-Info. In other words, if I send an UPDATE request 
> > without these header fields, e.g., for session timer refresh, does 
> > this cancel any previous negotiation of Info Packages? I 
> would prefer 
> > that it did not, that it simply left things unchanged.
> 
> We need to be careful here, to prevent breaking 3pcc. If a 
> transfer is done via 3pcc, how can we ensure that the desires 
> of the unchanged party are made known to the transfer target? 
> This could be ensured that the Send-Info/Recv-Info headers 
> are always sent when an offer or answer is sent.
> 
> > that a UAS must/should/may render a body when an INFO 
> request is not 
> > in error, so it seems odd to talk about rendering when there is an 
> > apparent error in the INFO request. Is "rendering" necessarily the 
> > appropriate thing to do with a received and valid INFO 
> request. Should 
> > we instead say "...the UAS MAY make use of the body"?
> 
> (I could have a dialog that was initiated with an INVITE, 
> then piggybacked with a SUBSCRIBE, then BYE to the INVITE, 
> but subscription remains. That is still an INVITE-initiated 
> dialog, but INFO isn't valid.)
> 
> This jogs another question in my mind. Is it permissible to 
> pass Send-Info / Recv-Info headers in an INFO? If so, then 
> IMO those change the state of the dialog.
> 
> > send/receive these packages in the context of this dialog. However, 
> > for OPTIONS there is no dialog. So what exactly are the 
> semantics of 
> > these header fields in OPTIONS request? Presumably it just means I 
> > support these packages and may be prepared to send/receive 
> them in the 
> > context of an INVITE-initiated dialog. This should be clarified.
> 
> > cannot change target URIs, so what would be the meaning of 
> Contact in 
> > an INFO request. I think we should align with BYE and not allow 
> > Contact in INFO.
> 
> Agree.
> 
> By default I would assume case-insensitive behavior. That is 
> the norm for most things. Is there a reason to be case sensitive here?
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 10 Nov 2008 08:22:43 +0000

My responses to Paul: 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 10 November 2008 04:10
> To: Elwell, John
> Cc: Eric Burger; SIP IETF
> just have a
[JRE] I agree that this would be a consequence, and yet a further
simplification.

> condition, when 
> transfer is 
[JRE] I don't object to mandating it, if this is what it takes to make
it work in a 3PCC environment. Is it clear to everyone what "dialog
state update" means?

> request is not in
[JRE] Yes, that would be better.

> Contact in an
[JRE] I am happy for it to be case-insensitive, but the most likely
interpretation of the existing words is case-sensitive.

John

---

From: Eric Burger <[email-masked]>
Date: Sun, 16 Nov 2008 20:20:50 -0600

Inline.

> [JRE] I agree that this would be a consequence, and yet a further

I like it.

>> But can somebody remind me why we need Send-Info at all?

You may be willing to send a package but not be willing to receive a  
package.  For example, you may be a phone that wants to send only the  
DTMF package but have no need to receive any INFOs. You need a way to  
advertise what you are willing to send.

In much older drafts, when it was really an offer/answer handshake,  
there was some thought you might modify what you will advertise. For  
example, if you advertised
    Send-Info: old-foo, new-foo
and the response had
    Recv-Info: old-foo, new-foo
the final response may just list
    Send-Info: new-foo
to let the UAS know you will only be sending new-foo.

I am ambivalent about this.  What say you?

>> be rejected, and that should not be considered a serious error.

Agreed.

>>>   If the UAS receives an INFO request with a Info-Package the UAC

Yes, and I would offer sending Send-Info/Recv-Info in every  
(potential) state changing message means the protocol works in all  
scenarios. It doesn't cost much in bytes, but I can see the argument  
that if you ran a separate, light-weight keep-alive mechanism, it  
would need to now know about INFO Packages.

>> Yeah, "render" could be quite confusing. Perhaps "process"?

Sounds good to me.  I used render because its meaning is well-known  
("Do something with it").

>> remains. That is still an INVITE-initiated dialog, but INFO

Will do.

>> Send-Info / Recv-Info headers in an INFO? If so, then IMO

Nope. I'll fix.

>> I agree. (I have similar problems with everything in an OPTIONS.)

Me, too.

>>> INFO request. I think we should align with BYE and not

Yup.

> interpretation of the existing words is case-sensitive.

The intention of the existing words is, in fact, case-sensitive.   
Again, I can go either way.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 17 Nov 2008 13:20:08 +0100

Buried in here is a discussion with OPTIONS.
 
I believe OPTIONS is useful, but I could live without it. If we have it,
it should do what OPTIONS always does, i.e. provide a means of
discovering what would happen if I tried an INVITE request with the same
characteristics.
 
That means we have to agree what the parameters in an INVITE dialog
provide us with first.
 
regards
 
Keith

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Burger
	Sent: Monday, November 17, 2008 2:21 AM
	To: John Elwell; Paul Kyzivat
	Cc: SIP IETF
	Subject: Re: [Sip] Comments on sip-info-events-01

	Inline. 

		My responses to Paul: 

			-----Original Message-----

			To: Elwell, John

			Subject: Re: [Sip] Comments on
sip-info-events-01

			Some followups to John's comments. I've trimmed
down to 

			relevant stuff.

			Thanks,

			Paul

			Elwell, John wrote:

				- I think I suggested once before that
we should not treat

				Send-Info/Recv-Info exchanges like
offer/answer, but should 

			just have a

				simple rule that says that a UA can send
these header 

			fields at any time

				and they supersede any sent previously.
A UA MUST not send 

			INFO unless

				the package has been identified in the
last Send-Info sent 

			and the last

				Recv-Info received. A UA MUST (SHOULD?)
discard a received 

			INFO unless

				the package has been identified in the
last Recv-Info sent, 

			and MUST be

				prepared to receive an INFO for a
package as soon as it has sent a

				Recv-Info identifying that package.
These header fields MAY 

			be included

				in an INVITE request, in a
dialog-forming response to an 

			INVITE request,

				or in any other request or response in
the context of an 

			early or full

				INVITE-initiated dialog. This would be a
lot simpler. Is there any

				reason it would not work? I am not
certain I have enumerated all the

				rules here, but I doubt if very much
more would need to be said

				normatively.

			I think this will work as long as he contents of
these headers on one 

			side are not coupled with those on the other
side. IOW, I 

			should be able 

			to mention a package in Recv-Info even if it
wasn't mentioned by the 

		[JRE] I agree that this would be a consequence, and yet
a further
		simplification.

	I like it.

			But can somebody remind me why we need Send-Info
at all?

	You may be willing to send a package but not be willing to
receive a package.  For example, you may be a phone that wants to send
only the DTMF package but have no need to receive any INFOs. You need a
way to advertise what you are willing to send.

	In much older drafts, when it was really an offer/answer
handshake, there was some thought you might modify what you will
advertise. For example, if you advertised
	   Send-Info: old-foo, new-foo
	and the response had
	   Recv-Info: old-foo, new-foo
	the final response may just list
	   Send-Info: new-foo
	to let the UAS know you will only be sending new-foo.

			However in any case we must accept that there is
a race 

			condition, when 

			an INFO is in flight at the same time as a
Recv-Info in the other 

			direction that forbids sending it. I think that
is fine - it 

			will just 

			be rejected, and that should not be considered a
serious error.

	Agreed.

				  If the UAS receives an INFO request
with a Info-Package the UAC

				  advertised with a Send-Info in the
last dialog state update"

				It was not clear to me that every dialog
state update MUST contain

				Send-Info/Recv-Info. In other words, if
I send an UPDATE 

			request without

				these header fields, e.g., for session
timer refresh, does 

			this cancel

				any previous negotiation of Info
Packages? I would prefer 

			that it did

				not, that it simply left things
unchanged.

			We need to be careful here, to prevent breaking
3pcc. If a 

			transfer is 

			done via 3pcc, how can we ensure that the
desires of the 

			unchanged party 

			are made known to the transfer target? This
could be ensured that the 

			Send-Info/Recv-Info headers are always sent when
an offer or 

			answer is sent.

		[JRE] I don't object to mandating it, if this is what it
takes to make
		it work in a 3PCC environment. Is it clear to everyone
what "dialog
		state update" means?

	Yes, and I would offer sending Send-Info/Recv-Info in every
(potential) state changing message means the protocol works in all
scenarios. It doesn't cost much in bytes, but I can see the argument
that if you ran a separate, light-weight keep-alive mechanism, it would
need to now know about INFO Packages.

				- "If a server receives an INFO request
with a body it 

			understands, but

				  it has no Info-Package header, the UAS
MAY render the body."

				This is the first mention of "render".
In fact there is 

			nothing to say

				that a UAS must/should/may render a body
when an INFO 

			request is not in

				error, so it seems odd to talk about
rendering when there 

			is an apparent

				error in the INFO request. Is
"rendering" necessarily the 

			appropriate

				thing to do with a received and valid
INFO request. Should 

			we instead

				say "...the UAS MAY make use of the
body"?

			Yeah, "render" could be quite confusing. Perhaps
"process"?

	Sounds good to me.  I used render because its meaning is
well-known ("Do something with it").

				- "The UAS MUST send a 481 Call
Leg/Transaction Does Not 

			Exist message

				  if the INFO request does not match any
existing dialog."

				Shouldn't this say "...does not match
any INVITE-initiated dialog"?

			INVITE-dialog-usage?

			(I could have a dialog that was initiated with
an INVITE, then 

			piggybacked with a SUBSCRIBE, then BYE to the
INVITE, but 

			subscription 

			remains. That is still an INVITE-initiated
dialog, but INFO 

			isn't valid.)

	Will do.

				- "The INFO message MUST NOT change the
state of the SIP 

			dialog.  The

				  only exception to this rule is for
specific failure responses as

				  documented in RFC 5057 [RFC5057],
which may cause the 

			INVITE dialog

				  to terminate."

			This jogs another question in my mind. Is it
permissible to pass 

			Send-Info / Recv-Info headers in an INFO? If so,
then IMO 

			those change 

			the state of the dialog.

	Nope. I'll fix.

				- "A UAC, the sender of the OPTIONS
request, MAY include 

			Send-Info and

				  Recv-Info headers, populated
appropriately for the 

			packages the UAC

				  supports.  The UAS MAY include its set
of Send-Info and Recv-Info

				  packages.  The UAS and UAC MUST NOT
consider the OPTIONS 

			request to

				  be part of a capabilities negotiation.
The OPTIONS 

			request is purely

				  a probe."

				The semantics of these header fields in
an INVITE request or another

				message in an INVITE-initiated dialog
means I am prepared to

				send/receive these packages in the
context of this dialog. 

			However, for

				OPTIONS there is no dialog. So what
exactly are the 

			semantics of these

				header fields in OPTIONS request?
Presumably it just means I support

				these packages and may be prepared to
send/receive them in 

			the context

				of an INVITE-initiated dialog. This
should be clarified.

			I agree. (I have similar problems with
everything in an OPTIONS.)

	Me, too.

				- In 5.1, Why is Contact allowed in an
INFO request but not in a 2xx

				response to INFO? Since INFO is not
allowed to change 

			dialog state, it

				cannot change target URIs, so what would
be the meaning of 

			Contact in an

				INFO request. I think we should align
with BYE and not 

			allow Contact in

				INFO.

			Agree.

	Yup.

				- "For the purposes of matching Info
Package types 

			indicated in Send-

				  Info or Recv-Info with those in the
Info-Package header 

			field value,

				  one compares the Info-package-name
portion of the 

			Info-package-type

				  portion of the "Info-Package" header
byte-by-byte with 

			that of the

				  same in the "Send-Info" or "Recv-Info"
header values."

				Presumably comparison is case-sensitive.
Should we state this?

			By default I would assume case-insensitive
behavior. That is the norm 

			for most things. Is there a reason to be case
sensitive here?

		[JRE] I am happy for it to be case-insensitive, but the
most likely
		interpretation of the existing words is case-sensitive.