Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt

From: Michael Miller <[email-masked]>
Date: Wed, 21 Apr 2010 10:07:49 -0400

> Hi,
>
> >>> People can correct me if I'm wrong - my impression is that the
> >>> *intent* of the keep stuff and the options ping stuff is different,
> >>> at least in emphasis. I am thinking the focus of keep is on keeping
> >>> nat pinholes open, while the focus of options ping is on
> >>> determination of which neighbors are up/down.
> >>
> >> That's also my understanding.
> >>
> >>> But each may be suitable for the other purpose itself. So there is
> >>> overlap, at least in the eyes of some.
> >>>
> >>> And of course there is also some perceived overlap between detecting
> >>> neighbors that are down and overload control.
> >>>
> >>> So to an extent its a matter of whether to characterize this ping
> >>> work as part of one of those other charters, or as something
> >>> independent of them. What is your take on that?
> >>
> >> I fully agree that the OPTIONS "ping" can be viewed as overlapping
> >> with the other two drafts.
> >>
> >> As you know, it was not the intent of the "ping" mechanism to serve as
> >> an overload mechanism, nor was it intended as a means of keeping
> pinholes open.
> >>
> >> I think both the keep and overload work is needed, as they work to
> >> solve specific problems.
> >>
> >> Likewise, I think we need the "ping" mechanism in places where the
> >> other two would not provide the desired device status information.  We
> >> would not need keep or overload between some devices.
> >
> >I don't *in principle* have a problem with treating these as separate
> things. But then we must ensure that they don't have unintended
> >(negative) interactions. That should be managed by careful scoping and by
> ensuring that they take account of one another.
> >
> >Christer indicated that there was a previous decision to include
> proxy-proxy keep-alives in the -keep draft. Christer - do you know where
> that decision might be documented? The existing goal list is very
> >vague on this.
>
> I haven't checked the meeting minutes, but the use-case was in the slides I
> presented at the Dublin meeting.
>
> Regards,
>
> Christer
>

Hi, I'm new to this process, so please be patience with me.

The draft looks good and I just want to make sure of a couple points:
1-We have endpoints that require Notify or Invite to be used for this ping.
I think by saying use the method OPTIONS I am hoping that is the only way to
perform this function.
2-Should we come up with a recommend (or default value) to be used on how
often we should send.  Concerns is that some devices may not reply back if
they get so many in a 30 second period (for an example).

Michael Miller
Global Crossing.

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Apr 2010 11:48:16 -0400

Michael,

It was our intent to recommend use of OPTIONS only for "ping".  The very
fact you've got a couple of implementations that use different messages for
the same purpose is evidence that we need to settle on one way.  Having
multiple ways to do this is clearly not in the best interest of customers.

As for the frequency of sending messages, I'm torn on this one.  I've heard
numbers that vary considerably.  Since this is something done between
devices that have some kind of relationship, I'd prefer to let the frequency
be determined by administrators.  That is what we put in Section 7.
However, if there are strong preferences to recommend an interval, I'll
change it.  But, I think we could only recommend something, not require it.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Michael Miller
Sent: Wednesday, April 21, 2010 10:08 AM
To: [email-masked]
Subject: Re: [sipcore] FW: I-D Action:draft-jones-sip-options-ping-00.txt

Hi,

>> an overload mechanism, nor was it intended as a means of keeping pinholes
open.

Regards,

Christer

Michael Miller
Global Crossing.

---

From: Dean Willis <[email-masked]>
Date: Fri, 23 Apr 2010 11:25:32 -0500

On Apr 23, 2010, at 10:48 AM, Paul E. Jones wrote:

> Michael,
>
> It was our intent to recommend use of OPTIONS only for “ping”.  The  
> very fact you’ve got a couple of implementations that use different  
> messages for the same purpose is evidence that we need to settle on  
> one way.  Having multiple ways to do this is clearly not in the best  
> interest of customers.

There's probably been some discussion of this that has just slipped  
out of my head, but we may wish to consider that OPTIONS gets  
"heavier" with every additional SIP extension. Eventually, it'll get  
too big for UDP, and become fairly useless for pinging.

Factor in that some people seem to be implementing OPTIONS to provide  
a different answer based on "who's asking", and we add the overhead of  
(optionally) authenticating the request,  making an options-selection  
based on what the requester is authorized to see, and then formulating  
the specific reply.

Two alternatives suggest themselves to me:

1) Defining a new method, like PING, specifically constructed to have  
no semantic other than "Are you there?"

2) Holding open a long-lived dialog with the node you are "pinging"  
and using keepalive (and or session-timer) to make sure it's still  
there. At least this lets the AAA process happen only once (for some  
values of authentication) and lets us reuse a long-lived TCP (or TLS)  
connection if appropriate.

I somewhat prefer the second; it has better backward-compatibility,  
and helps discomfit all those people I've been telling not to bill  
based on INVITE/BYE for so long.

--
Dean

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Apr 2010 12:59:01 -0400

Dean,

> based on what the requester is authorized to see, and then formulating

Your concerns are valid, but devices implementing a "ping" know they're
doing that, and would not have to fatten the OPTIONS message.  They also
would not need to authenticate the request, either.  At a minimal, they
respond in all cases, and as one step toward "security" (if the "ping"
needed it), one could employ an ACL.

>From an architectural purity perspective, I like this.  The problem is that
it requires changes to every stack in the field.  It also means we have one
more way to do "ping", since I suspect people will continue to use OPTIONS.

There was also a suggestion to have a tag to indicate that the OPTIONS is
for "ping", though I think the Request URI could serve the same purpose. One
should not ping sip:[email-masked], while one might ping
sip:192.168.1.10 or sip:[email-masked] and the responding entity should
formulate a reasonable (non-heavy) reply.
 
> connection if appropriate.

This likewise requires a bit of change on most devices to understand that
such sessions are "ping" sessions.  It also requires a bit more state
management on both devices.  It's not horrible, but not nearly as
light-weight as sending an OPTIONS "ping" every now and then.  Further,
consider that sending a "ping" is not really necessary for devices that know
(through other means) that the peer device is alive (e.g., active dialogs
starting/stopping).  This approach would not benefit from that. 
 
> based on INVITE/BYE for so long.

Billing?  We don't need no stinkin' bills ;-)

Obviously, I'm partial to the OOD OPTIONS "ping" method.  It's fairly widely
(albeit inconsistently) implemented.  Other options seem to require more
work in terms of specification and implementation.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Apr 2010 13:27:49 -0400

[ as individual ]

> needed it), one could employ an ACL.
...
> formulate a reasonable (non-heavy) reply.

I'm bothered by this - it makes too many assumptions about usage.

The *sender* knows when the options is a ping and when it is not, but 
the recipient doesn't.

Making a decision based on the form of the R-URI presumes that non-ping 
users of options never use an ip address as the R-URI. Requiring the 
R-URI to be ping@ip reserves a user part, and also is just a sleazy way 
of adding another indicator to the message to indicate its intended use.

One possibility would be to use an option tag: Required:ping. That would 
ensure the other party knows this is a ping. (And of course if that 
fails you could remove the tag, and realize you were not getting a 
specialized ping implementation.)

But that itself requires parsing the message enough to recognize the 
option tag. I know of at least one implementation that optimizes OPTIONS 
deep in the stack - replying immediately without ever passing it to the 
applications layer, and without parsing much of the message. But it 
depends on knowing its in an environment where that is acceptable.

I'd certainly like to see the pros/cons debated thoroughly.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 23 Apr 2010 13:55:06 -0500

On Apr 23, 2010, at 12:27 PM, Paul Kyzivat wrote:

>
> One possibility would be to use an option tag: Required:ping. That  
> would ensure the other party knows this is a ping. (And of course if  
> that fails you could remove the tag, and realize you were not  
> getting a specialized ping implementation.)
>

Nah, that just requires somebody to support the ping extension; it  
doesn't tell them to apply that extension to this OPTIONS request.

> option tag. I know of at least one implementation that optimizes  
> OPTIONS deep in the stack - replying immediately without ever  
> passing it to the applications layer, and without parsing much of  
> the message. But it depends on knowing its in an environment where  
> that is acceptable.

How does the implementation know which options are supported at the  
application level? It probably doesn't, and is sending a arong options- 
set in the response.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Apr 2010 15:25:28 -0400

Dean,

OK, you caught me falling into that trap too. :-(

In any case, once you are going to mandate something new, it doesn't 
matter much whether it is an option tag or a method. Either way you have 
to implement something new.

Similarly, if you mandate that a particular R-URI format is to be 
treated differently, that also is something new to implement.

The *advantage* of OPTIONS is that it can be used as a ping without the 
recipient having any knowledge that is the purpose. But if it is 
unsuitable for use with those that don't understand ping as something 
special, then it has no advantage.

I guess the argument remains that if you use some special form of ping 
that will still work for the clueless, but which can be optimized by the 
clueful, then you have the best of both worlds.

For that to work well, the discriminator should be something that is 
certain not to cause trouble for the clueless, and that doesn't limit 
the clueful who also use OPTIONS for non-ping purposes. I think that 
rules out R-URI values. But it could include new header fields. Note 
that you have to implement *something* new in the UAS if you want to 
optimize pings. So implementing a new header should not be a big deal.

	Thanks,
	Paul

Dean Willis wrote:
>> that fails you could remove the tag, and realize you were not getting 
>> a specialized ping implementation.)
>>
> 
> 
>> OPTIONS deep in the stack - replying immediately without ever passing 
>> it to the applications layer, and without parsing much of the message. 
>> But it depends on knowing its in an environment where that is acceptable.
> 
> application level? It probably doesn't, and is sending a arong 
> options-set in the response.
> 
> -- 
> Dean
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Apr 2010 23:56:24 +0200

Hi,

>doesn't tell them to apply that extension to this OPTIONS request.

I don't think you can make such general assumption. It needs to be specified per option tag.

For example, if you receive an INVITE with Require:100rel, you must not only support the extension - you must also use it when sending provisional responses (see RFC3262, section 3, paragraph 2).

If you don't think is correct we'd need to update RFC3262.

In addition, the scope of an option-tag can be a single transaction, or wider. 

For example, just because I require 100rel in the initial INVITE, it doesn't mean (at least that is my understanding) I have implicitly also required it in each subsequent re-INVITE.

The scope of Require:sec-agree, on the other hand, is for the whole session. 

Is there ANY option-tag defined, where we specify that Require only means must-support-but-is-not-required-to-use?

Anyway, if we move forward with options-ping, I DO think there should be a way to identify the OPTIONS as a ping, so that the receiver e.g. doens't need to include all supported capabilities etc in the response - or expect them in the request.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Fri, 23 Apr 2010 17:09:51 -0500

On Apr 23, 2010, at 4:56 PM, Christer Holmberg wrote:

> For example, if you receive an INVITE with Require:100rel, you must  
> not only support the extension - you must also use it when sending  
> provisional responses (see RFC3262, section 3, paragraph 2).
>

We've had this discussion before: 100rel was badly written in this  
respect.

For example, what do you do if you receive a request that has Require:  
100rel but not Supported: 100rel?

> If you don't think is correct we'd need to update RFC3262.

It's on my list of things to do Someday When I Have The Time.

> For example, just because I require 100rel in the initial INVITE, it  
> doesn't mean (at least that is my understanding) I have implicitly  
> also required it in each subsequent re-INVITE.
>
> Is there ANY option-tag defined, where we specify that Require only  
> means must-support-but-is-not-required-to-use?

Path and Service-Route and answer-mode come to mind. I edited them . . .

>
> Anyway, if we move forward with options-ping, I DO think there  
> should be a way to identify the OPTIONS as a ping, so that the  
> receiver e.g. doens't need to include all supported capabilities etc  
> in the response - or expect them in the request.

Yes, that would be useful.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Apr 2010 18:14:20 -0400

> -----Original Message-----
> Of Paul Kyzivat
> Sent: Friday, April 23, 2010 1:28 PM
> 

Actually in a weird way I think doing a specific username may be the right thing to do.  Think about it from an email perspective.  When you check on the status and settings of an email list using SMTP, do you (a) send a new different SMTP message type, or (b) address a normal message to the actual logical administrative code for the list?  You send a normal message to [email-masked].  

And logically the thing being "pinged" is a higher layer, because the response provides an administrative status as well. (even though in code one would probably do this at a low level) 

Put it another way: in theory you could send a SUBSCRIBE to this logical admin-UA in that proxy so that it Notifies you when it goes admin up/down.  That logical UA is a resource in the proxy, and could be addressed as such. 

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Apr 2010 18:44:52 -0400

I will grant you that having per-user policies for what to include in 
OPTIONS would be possible.

But using that approach here means reserving a specific username. Which 
one are we allowed to pick that won't impact somebody? (I expect there 
are people out there named "ping" who might not like having their user 
name preempted.)

AFAIK we have never preempted a user name, except for Anonymous, which 
is only preempted in the anonymous.invalid domain. I'd much rather see a 
special uri parameter to designate this behavior.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Apr 2010 00:54:07 +0200

Hi,

>We've had this discussion before: 100rel was badly written in this respect.
>
>For example, what do you do if you receive a request that has Require:100rel but not Supported: 100rel?

Assuming I support 100rel I would send my 18x responses reliably, because I would assume, based on the text in 3262, that Require:100 implicitly indicates that the UAC also supports it.

>It's on my list of things to do Someday When I Have The Time.

So, you want to say that a UAS must not send reliable responses in case the INVITE only contains Require:100rel, but not Supported:100rel? In that case I think "Someday" may have been a long time ago :)

And, I also think you have the same issue with the "preconditions" option-tag. Are you going to update 3312/4032 also?

And, what about sec-agree?

>Path and Service-Route and answer-mode come to mind. I edited them . . .

I don't think we have an option-tag for Service-Route, do we?

And, as far as I remember, RFC 3327 doesn't say anything about the usage of the "path" option-tag in Require.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Fri, 23 Apr 2010 17:53:57 -0500

On Apr 23, 2010, at 5:44 PM, Paul Kyzivat wrote:
>
> I'd much rather see a special uri parameter to designate this  
> behavior.
>

That would be so cool!

If only we had a way to pass URI parameters across proxies that do RFC  
3261 contact-routing...

Which of corse if why I've been standing on that particular soapbox  
for ten years or so.

The best Idea I've heard along these lines is to stop REGISTERing  
Contact and start PUBLISHing a Route, as suggested by Adam early in  
MARTINI's life cycle. Perhaps we'll get there someday.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Apr 2010 09:28:28 +0200

Hi,

>doesn't tell them to apply that extension to this OPTIONS request.

In this specific case, does it really matter?

As long as you only want SOME response, does it really matter? You will either get a 200 or a 420 response.

Regards,

Christer

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sat, 24 Apr 2010 13:22:15 -0500

It matters in the sense what the UAS returns in 200 OK response to
OPTIONS. If it supports that extension, it will return a success
response without it's full capabilities, as will be required with normal
OPTIONS processing.

Sanjay

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Christer Holmberg
> Sent: Saturday, April 24, 2010 12:58 PM
> To: Dean Willis; Paul Kyzivat (pkyzivat)
> Cc: Paul E. Jones; [email-masked]; 'Michael Miller'
> Subject: Re: [sipcore] FW: I-D
Action:draft-jones-sip-options-ping-00.txt
> As long as you only want SOME response, does it really matter? You
will either get a
> 200 or a 420 response.
> 
> Regards,
> 
> Christer
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Dean Willis <[email-masked]>
Date: Sat, 24 Apr 2010 15:43:16 -0500

On Apr 23, 2010, at 5:54 PM, Christer Holmberg wrote:
>>
>> For example, what do you do if you receive a request that has  
>> Require:100rel but not Supported: 100rel?
>
> Assuming I support 100rel I would send my 18x responses reliably,  
> because I would assume, based on the text in 3262, that Require:100  
> implicitly indicates that the UAC also supports it.
>

So, 3262 has a bug in it. Putting an option tag in Require clearly  
doesn't men you support the feature, only that you require the UAS to  
do so.

> So, you want to say that a UAS must not send reliable responses in  
> case the INVITE only contains Require:100rel, but not Supported: 
> 100rel? In that case I think "Someday" may have been a long time  
> ago :)

I think at a minimum that 3262 should say that a UAC putting a  
Require: 100rel MUST also put Supported: 100rel

>
> And, I also think you have the same issue with the "preconditions"  
> option-tag. Are you going to update 3312/4032 also?
>

I suspect it needs it.

> And, what about sec-agree?

It's clearly got bugs.

> And, as far as I remember, RFC 3327 doesn't say anything about the  
> usage of the "path" option-tag in Require.

Right. The UAS is free to use path if the UAC supports it. It doesn't  
decide whether or not to use the extension based on a Require.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Apr 2010 11:55:12 +0200

Hi,

>response without it's full capabilities, as will be required with normal

But, from a ping perspective, why does it matter what the response code it? Why does it matter whether the receiver supports the functionality or not?

Of course, if you also expect the receiver to send pings towards you, then you may need to know whether it supports the mechanism. But, if you are the only one sending pings, all you want is A response, isn't it?

Regards,

Christer

Behalf Of
will either get a

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Apr 2010 21:25:10 +0200

Hi,

>So, 3262 has a bug in it. Putting an option tag in Require clearly doesn't men you support the feature, only that you require the UAS to do so.

Upon what text do you base "clearly"? 

If it's so clear, why have we ended up with a number of RFCs which would be incorrect?

>I think at a minimum that 3262 should say that a UAC putting a Require: 100rel MUST also put Supported: 100rel

If we would be doing 3262 today I would not necessarily disagree with you. Today, I just think you're going to end up with backward compability issues.

>>And, what about sec-agree?

I love this protocol...

Also, in some cases the Require header in a *response* seems to have different meanings. 

For example, "Require: outbound" in a response seems to indicate that the registrar has done somthing, while "timer" seems to require the UAC to do something (ie not only require to support some extension).

So, if Require only means "you must support", why would someone send 'Require: x' in a response if the associated request already contained 'Supported: x'? The UAC has already indicated support, so there is no need to say you-must-support...

Regards,

Christer

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sun, 25 Apr 2010 23:00:12 -0500

It is true that all the receiver wants is some response. And for that,
the receiving node does not even have to support OPTIONS. If it does
not, then it will send 405 response. That is enough for the sender to
know that the ping was successful.
But I think that we are talking about case where 200 OK is considered as
successful ping. For that case, Dean was suggesting an options tag for
the receiver to sends a ping 200 OK response as compared to 200 OK
response for an OPTIONS, which is to query capabilities.

Maybe all confusion is due to overloading of OPTIONS.

Thanks
Sanjay

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Sunday, April 25, 2010 3:25 PM
> To: Sanjay Sinha (sanjsinh); Dean Willis; Paul Kyzivat (pkyzivat)
> Cc: Paul E. Jones; [email-masked]; Michael Miller
> Subject: RE: [sipcore] FW: I-D
> But, from a ping perspective, why does it matter what the response
code it? Why does
> it matter whether the receiver supports the functionality or not?
> 
> Of course, if you also expect the receiver to send pings towards you,
then you may
> need to know whether it supports the mechanism. But, if you are the
only one sending
> pings, all you want is A response, isn't it?
>
> 
> Regards,
> 
> Christer
> 
>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sun, 25 Apr 2010 23:16:23 -0500

Without "Require" in the response, how does the UAC know that the UAS
supports that extension, if the UAC had added a Supported header in the
request?

Thanks
Sanjay

Behalf Of
> Christer Holmberg
> Sent: Monday, April 26, 2010 12:55 AM
> To: Dean Willis
> Cc: Paul E. Jones; [email-masked]; [email-masked]; Miller'
> >So, 3262 has a bug in it. Putting an option tag in Require clearly
doesn't men you
> support the feature, only that you require the UAS to do so.
> 
> If it's so clear, why have we ended up with a number of RFCs which
would be
> incorrect?
Require: 100rel
> MUST also put Supported: 100rel
> 
> If we would be doing 3262 today I would not necessarily disagree with
you. Today, I
> just think you're going to end up with backward compability issues.
> 
option-tag. Are
> you going to update 3312/4032 also?
> >>
> >>I suspect it needs it.
> >>
> Also, in some cases the Require header in a *response* seems to have
different
> meanings.
> 
> For example, "Require: outbound" in a response seems to indicate that
the registrar has
> done somthing, while "timer" seems to require the UAC to do something
(ie not only
> require to support some extension).
> 
> So, if Require only means "you must support", why would someone send
'Require: x'
> in a response if the associated request already contained 'Supported:
x'? The UAC has
> already indicated support, so there is no need to say
you-must-support...

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Apr 2010 09:02:05 +0200

Hi, 

>Without "Require" in the response, how does the UAC know that the UAS supports that extension, if the UAC had added a 
>Supported header in the request?

According to Dean "Require" doesn't say anything about what the UAS supports, or doesn't support. It only says what the receiver must support.

Regards,

Christer

> > >>100rel? In that case I think "Someday" may have been a 
> long time ago 
> > >>:)
> > >

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Apr 2010 04:12:55 -0500

On Apr 25, 2010, at 4:55 AM, Christer Holmberg wrote:

> code it? Why does it matter whether the receiver supports the  
> functionality or not?
>
> Of course, if you also expect the receiver to send pings towards  
> you, then you may need to know whether it supports the mechanism.  
> But, if you are the only one sending pings, all you want is A  
> response, isn't it?
>

Then you don't need an option tag and don't need to be able to Require  
the extension. It's just an optimization parameter; if the UAS sees a  
recognizable "ping" flag, then it can return an optimized options-free  
response. If it doesn't understand the flag, it returns a conventional  
response.

Sounds like a great candidate for a new header field. Note that I've  
generally believed that header fields should be easy to register,  
given that they're our only really way to pass parameters since we  
broke URI-parameters with contact-routing.

Maybe we can define an "OPtions-Mode" header field, and register the  
value "ping" here -- and add additional Options-Mode values here in  
the future if needed.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Apr 2010 04:32:28 -0500

On Apr 25, 2010, at 2:25 PM, Christer Holmberg wrote:

>> doesn't men you support the feature, only that you require the UAS  
>> to do so.
>

RFC 3261: 20.32 Require says (verbatim):
"The Require header field is used by UACs to tell UASs about options  
that the UAC expects the UAS to support in order to process the  
request. Although an optional header field, the Require MUST NOT be  
ignored if it is present. The Require header field contains a list of  
option tags, described in Section 19.2. Each option tag defines a SIP  
extension that MUST be understood to process the request. Frequently,  
this is used to indicate that a specific set of extension header  
fields need to be understood. A UAC compliant to this specification  
MUST only include option tags corresponding to standards-track RFCs."

The above clearly indicates that the usual use of the option-tag in  
Require is to indicate that there is other data in the request,  
typically header fields, which the UAS MUST be able to understand in  
order to process the request. It does NOT say that the presence of the  
Require changes the behavior of the UAS in any other way; it's the  
presence of those header fields (or other extension flags) in the  
request that changes the behavior. All the Require does is cause the  
UAS to reject the request if it doesn't understand that other data.  
This changes the default behavior of a UAS, which is to silently  
ignore "other data" that it does not understand. Note that having a  
Require for a new request type is rather useless, as we're less  
liberal-in-what-we -accept with request types and reject unknowns  
anyhow.
In other words, un-Required extensions appearing in a known request  
type are ignored if not understood, whereas Required extensions that  
are not understood cause the request to be rejected.
Note also that the prohibition of non-standards-track option-tags is  
spelled out in RFC 3261.
> would be incorrect?

It's an overly complicated design for our simple minds? I didn't say I  
LIKE the way this works in RFC 3261, just that I mostly (ok, sortof)  
understand it.

> I love this protocol...

Yes, it gives us so much to work on. Much better than knitting or  
jigsaw puzzles on a cold winter night!

> different meanings.

Very true. At the moment, I can't say where the meaning of Require in  
a response comes from. RFC 3261 does not, AFAIK, say anything about  
it. We seem to have invented it on the fly without formal  
specification, using an error in RFC 3261's table 2/3 to justify the  
approach. Perhaps a more formal specification would be a good idea.

>
> For example, "Require: outbound" in a response seems to indicate  
> that the registrar has done somthing, while "timer" seems to require  
> the UAC to do something (ie not only require to support some  
> extension).
>
> 'Require: x' in a response if the associated request already  
> contained 'Supported: x'? The UAC has already indicated support, so  
> there is no need to say you-must-support...

I dunno. Maybe somebody wrote a specification based on not  
understanding Require in the request and we were too tired of arguing  
about it to stop the publication?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Apr 2010 04:39:57 -0500

On Apr 26, 2010, at 2:02 AM, Christer Holmberg wrote:

>
> Hi,
>
>> Without "Require" in the response, how does the UAC know that the  
>> UAS supports that extension, if the UAC had added a
> According to Dean "Require" doesn't say anything about what the UAS  
> supports, or doesn't support. It only says what the receiver must  
> support.

Not quite. The UAS is (by definition) the receiver of any request, and  
the Require says that if the UAS does not support the required option,  
then it must reject the request.

Other than that, the Require doesn't invoke any specific behavior in  
the UAS.

So for example a INVITE with a "Require: explodemyphone" doesn't make  
the phone blow up, but would cause the phone to reject the request if  
it doesn't know how to blow up. It'd be some other header field, like  
"Explodemyphone:withsmokeandfire". In the absence of a Require, a  
phone that didn't know how to explode would just ignore that part of  
the request and alert in the usual fashion.

Also, an INVITE with a "Require:explodemyphone" but that lacked an  
"Explodemyphone" header field would be accepted by a phone that knows  
how to explode, but said phone probably wouldn't explode as a result  
(especially not with both smoke and fire!)

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Apr 2010 12:42:55 +0200

Hi, 

>>>doesn't men you support the feature, only that you require 
>>>the UAS to do so.
>>
>"The Require header field is used by UACs to tell UASs about 
>options that the UAC expects the UAS to support in order to 
>process the request. Although an optional header field, the 
>Require MUST NOT be ignored if it is present. The Require 
>header field contains a list of option tags, described in 
>Section 19.2. Each option tag defines a SIP extension that 
>MUST be understood to process the request. Frequently, this 
>is used to indicate that a specific set of extension header 
>fields need to be understood. A UAC compliant to this 
>specification MUST only include option tags corresponding to 
>standards-track RFCs."
> 
>The above clearly indicates that the usual use of the 
>option-tag in Require is to indicate that there is other data 
>in the request, typically header fields, which the UAS MUST 
>be able to understand in order to process the request. It 
>does NOT say that the presence of the Require changes the 
>behavior of the UAS in any other way; it's the presence of 
>those header fields (or other extension flags) in the request 
>that changes the behavior. All the Require does is cause the 
>This changes the default behavior of a UAS, which is to 
>silently ignore "other data" that it does not understand. 
>Note that having a Require for a new request type is rather 
>useless, as we're less liberal-in-what-we -accept with 
>request types and reject unknowns anyhow.
>In other words, un-Required extensions appearing in a known 
>request type are ignored if not understood, whereas Required 
>extensions that are not understood cause the request to be rejected.
>Note also that the prohibition of non-standards-track 
>option-tags is spelled out in RFC 3261.

Section 8.1.1.9 says:

"If the UAC wishes to insist that a UAS understand an extension that
the UAC will apply to the request in order to process the request, it
MUST insert a Require header field into the request listing the
option tag for that extension."

I think the "that the UAC will apply" could be read as indicating that the UAC also supports the extension.

>Very true. At the moment, I can't say where the meaning of 
>Require in a response comes from. RFC 3261 does not, AFAIK, say anything about  
>>that the registrar has done somthing, while "timer" seems 
>>to require the UAC to do something (ie not only require to support some  
>>extension).
>> 
>understanding Require in the request and we were too tired of 
>arguing about it to stop the publication?

Well, it's not only one specification...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Apr 2010 12:45:18 +0200

Hi, 

>>>Without "Require" in the response, how does the UAC know 
>>>that the UAS supports that extension, if the UAC had added a Supported 
>>>header in the request?
>>
>Not quite. The UAS is (by definition) the receiver of any 
>request, and the Require says that if the UAS does not 
>support the required option, then it must reject the request.

Note that the text above was about Require in a response (in which case the UAC is the receiver).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Apr 2010 08:43:35 -0400

If this discussion is to continue, can we at least have a relevant 
subject rather than hijacking the discussion options ping?

I agree in principle with Dean's point. But from a practical perspective 
I think we just acknowledge that the definition of certain options added 
on additional semantics. I think we should just grandfather that but 
refrain from making the same mistake in the future.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Apr 2010 08:52:21 -0400

Dean,

The loss of parameters on retargeting is a valid issue in general, and 
may be a reason not to use a parameter in this case. But it isn't a 
problem for the use case contemplated because that case doesn't expect 
there to be retargeting.

But haven't we decided to solve the uri parameter problem with H-I?

	Thanks,
	Paul

Dean Willis wrote:
>> I'd much rather see a special uri parameter to designate this behavior.
>>
> 
> That would be so cool!
> 
> Which of corse if why I've been standing on that particular soapbox for 
> ten years or so.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Apr 2010 13:19:37 -0400

> Of Christer Holmberg
> Sent: Monday, April 26, 2010 6:43 AM
> 
> Section 8.1.1.9 says:
> 

Dean's point is that the Require does indeed mean the UA must support the extension - but it does not mean it is *using* the extension nor even demanding the extension be used, for this particular transaction/dialog/whatever.  It's the header/param which indicates the actual usage, and the option-tag just says "you must understand the header or param".  That way the processing of the Require/Supported header fields can be handled separately from whatever logic/layer handles the extension logic itself.

We've had this debate before. :)
We all agreed there were RFCs which used it to mean both "I understand" and "I am using" the extension, and we wouldn't deprecate/change them.  But I'm not sure we ever agreed on what we'd do going forward.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Apr 2010 12:19:31 -0500

On Apr 26, 2010, at 7:52 AM, Paul Kyzivat wrote:

> Dean,
>
> The loss of parameters on retargeting is a valid issue in general,  
> and may be a reason not to use a parameter in this case. But it  
> isn't a problem for the use case contemplated because that case  
> doesn't expect there to be retargeting.

How does it know?

> But haven't we decided to solve the uri parameter problem with H-I?

We keep saying that. I haven't seen it work yet. I retain the opinion  
that it's a bad solution to the problem.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Apr 2010 13:51:14 -0400

chair hat off:

>> problem for the use case contemplated because that case doesn't expect 

I should let him answer.

My impression is either:
- Max-Forwards:1
or
- R-URI is ip address with no user part, and an *expectation* that
   this will not be redirected, or that if it is, then it isn't a
   use case of interest.

> that it's a bad solution to the problem.

Well, I don't like it either. Yet that *seems* to be the consensus.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Apr 2010 19:53:11 +0200

Hi, 

>>MUST insert a Require header field into the request listing the option 
>>tag for that extension."
>> 
>Dean's point is that the Require does indeed mean the UA must support the extension - but it does not mean it is *using* the extension nor even demanding the extension be used, for this particular 
>transaction/dialog/whatever. 

Yes, I know.

>It's the header/param which indicates the actual usage, and the option-tag just says "you must understand the header or param".  That way the processing of the Require/Supported header fields can be 
>handled separately from whatever logic/layer handles the extension logic itself.

So, how does this work for 100rel? The INVITE request does not contain any of the extension specific header fields (RSeq and RAck). They will be used when the UAS starts using the extension.

Yes, I know, you say we don't deprcate/change 100rel, but what if we have similar extensions in the future, where the option-tag is the only thing you initially send?

>We all agreed there were RFCs which used it to mean both "I understand" and "I am using" the extension, and we wouldn't deprecate/change them.
>
>But I'm not sure we ever agreed on what we'd do going forward.

It would be really good if we could document the outcome of such debates, rather than leaving them in an e-mail somewhere...

Regards,

Christer

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Apr 2010 14:02:48 -0400

> Sent: Monday, April 26, 2010 1:53 PM
> 
> So, how does this work for 100rel? The INVITE request does not contain any
> of the extension specific header fields (RSeq and RAck). They will be used
> when the UAS starts using the extension.
> 
> Yes, I know, you say we don't deprcate/change 100rel, but what if we have
> similar extensions in the future, where the option-tag is the only thing
> you initially send?

We would make sure they don't just send an option-tag only.  In some cases this would just mean a placebo header gets defined and used, like for RFC 4488 norefersub where a "Refer-Sub: false" is used.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Apr 2010 14:07:25 -0400

> So, how does this work for 100rel? The INVITE request does not contain any of the extension specific header fields (RSeq and RAck). They will be used when the UAS starts using the extension.

100rel botched it, so now its grandfathered.

> Yes, I know, you say we don't deprcate/change 100rel, but what if we have similar extensions in the future, where the option-tag is the only thing you initially send?

If we have similar things in the future, then shame on us for approving 
them.

> It would be really good if we could document the outcome of such debates, rather than leaving them in an e-mail somewhere...

Yes, it would be good. Where would you propose to put it?
Is it a problem we need to solve? Or do we already have it under control 
for future options.

	Thanks,
	Paul

---

From: [email-masked]
Date: Tue, 27 Apr 2010 12:02:38 +0800

Hi Paul,

Yes. Under semantic analysis, Require(from UAC) only means the demand of 
UAS's capability.

To expressing the semantics of demanding UAS's specific behavior (in 
specific conditions) needs something new. Relating, if UAS want the UAC's 
specific behavior (in specific conditions) should use the same *new 
header*, Require is not proper. So, Require 100rel from both UAC and UAS 
is misapplication.

And it seams that we should clarify that we haven't had tool with the 
semantics of demanding the peer's specific behavior (in specific 
conditions). But I prefer there's no correction for RFC3262 just for this 
reason.

Thanks,

Gao 

> refrain from making the same mistake in the future.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Apr 2010 13:53:45 +0200

Hi,

>We would make sure they don't just send an option-tag only.  In some cases this would just mean a placebo header gets defined and used, like for RFC 4488 norefersub where a "Refer-Sub: false" is use…

In many cases the extension does have associated information elements (header fields, SDP parameters etc), but they still don't say anything about whether the receiver should use the required extension or not. They simply provide additional information associated with the extension. Preconditions is a good example.

I just wonder why a UA would require support of some extension, if it doesn't also require the usage of it... Exactly HOW it is then used can of course depend on header field values etc.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 27 Apr 2010 14:03:31 +0200

Hi,

>If we have similar things in the future, then shame on us for approving them.

Yes, but "we" (referring to the people active in the WG at this point) will not be here forever. This should be clear also to people defining SIP extension in 100 years from now :)

In addition, even if we are not going to change existing extensions, I am not sure all of them are very clear on what Require really means. Maybe some of the assume that Require also indciates UAC support, but it is not stated anywhere. So, I guess we would need to check that.

>Is it a problem we need to solve? Or do we already have it under control for future options.

There are two things we need to consider:

1. Even if "we" have it under control - is it clearly enough specified?

2. As described above, even if we won't change the meaning of Require in existing extensions, is it always clear what Require actually means in those extensions?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Apr 2010 09:45:26 -0400

> I just wonder why a UA would require support of some extension, if it doesn't also require the usage of it... Exactly HOW it is then used can of course depend on header field values etc.

Well, the simplest case of this is when "support" means 
ability/willingness to receive and act upon something in a message. In 
that case the UAC might Require that because it *might* need to send 
something that requires it. OTOH the circumstance where it would send 
that might never come up, and so the required support may never be employed.

Another case might be a conflict between capability and policy.
The UAS might be capable of supporting some option, but unwilling to do 
so, in some circumstances, due to policy. It thus may have to wait until 
the circumstances where the option would be used to evaluate the policy 
and decide what to do.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Apr 2010 09:50:16 -0400

Christer,

I expect you know by now that my inclination is to carefully "dot every 
'i' and cross every 't'", so philosophically I am entirely with you.

But from a practical perspective I see this as a very low priority 
issue. If we happen to be doing something else that we could reasonably 
piggy back this on, then I would go for it. But I can't get very worked 
up over initiating an effort specifically to do this.

	Thanks,
	Paul