Subject: [Sip] INFO Framework: Tags

From: Eric Burger <[email-masked]>
Date: Wed, 19 Nov 2008 18:47:55 -0600

Do we want to specify media tags to indicate package support?

Do we want to specify SIP option tags to require Info Package support?

Comments welcome.

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Thu, 20 Nov 2008 01:16:16 +0000

Eric,

If an individual package requires an option tag, that option tag could
be defined in the RFC that defines the package, which would need to be
standards track. I don't think we need to say anything about this.

Similar situation for media tags, except that RFC would not need to be
standards track.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Burger
> Sent: 20 November 2008 00:48
> To: SIP List
> Subject: [Sip] INFO Framework: Tags
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Nov 2008 20:24:50 -0500

> Do we want to specify media tags to indicate package support?

This would be so you could use callerprefs to select which UA. Given the 
astounding popularity and ubiquitous implementation of callerprefs that 
probably isn't hugely important.

> Do we want to specify SIP option tags to require Info Package support?

I think I agree with John or whoever it was, that these can be specified 
on a per-package basis if desired.

	Thanks,
	Paul

> Comments welcome.
> 
> 
> ------------------------------------------------------------------------
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Nov 2008 02:44:10 +0100

I agree with John here.

I would include an informative reference to RFC 3427 indicating that any
draft that requires option tags for a package would need to have the
status required for option tag registration.

regards

Keith

> Behalf Of Elwell, John
> Sent: Thursday, November 20, 2008 1:16 AM
> To: Eric Burger; SIP List
> Subject: Re: [Sip] INFO Framework: Tags
> 
> Eric,
> 
> If an individual package requires an option tag, that option 
> tag could be defined in the RFC that defines the package, 
> which would need to be standards track. I don't think we need 
> to say anything about this.
> 
> Similar situation for media tags, except that RFC would not 
> need to be standards track.
> 
> John
> 
> Behalf Of 
> > Eric Burger
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Nov 2008 01:00:08 -0600

> Do we want to specify SIP option tags to require Info Package support?

yes, although there are reasons beyond requiring Info package support,  
such as reporting extension support in OPTIONS/200OK

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 20 Nov 2008 14:11:33 +0100

Hi, 

Feature-tags:
-------------

>I agree with John here.
>
>I would include an informative reference to RFC 3427 indicating that
any draft that requires option tags for a package 
>would need to have the status required for option tag registration.

One option would have been to define an info feature tag which can list
package value, and each package could then specify a value.

E.g sip.info="dtmf-packkage, isup-package"

But, I am ok with John's proposal also, but I think we should add some
text as suggested by Keith.

Option-tag:
-----------

I strongly think we should define an option tag for info packages.

Regards,

Christer

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Elwell, John

> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
> 
_______________________________________________
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
_______________________________________________
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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Nov 2008 17:44:56 +0100

> Option-tag:

I think you need to provide more than this in terms of explanation. What
interoperability issues do you think is solved by providing an option
tag for the extension itself, as opposed to individual packages?

Give us some valid scenarios.

regards

Keith 

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Thursday, November 20, 2008 1:12 PM
> To: DRAGE, Keith (Keith); Elwell, John; Eric Burger; SIP List
> Subject: RE: [Sip] INFO Framework: Tags
> 
> 
> Hi, 
> 
> Feature-tags:
> -------------
> 
> >I agree with John here.
> >
> One option would have been to define an info feature tag 
> which can list package value, and each package could then 
> specify a value.
> 
> But, I am ok with John's proposal also, but I think we should 
> add some text as suggested by Keith.
> 
> 
> Option-tag:
> -----------
> 
> need to be

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Nov 2008 12:24:24 -0600

The option tag is used in OPTIONS responses (and in Supported header  
fields in other responses) to inform a correspondent that the node in  
question supports this extension, potentially leading to a decision as  
to which behavior to apply to future requests.

It is also used in Require header fields of requests to cause the  
request to be rejected by any UAS that does not understand the  
extension.  This is potentially critical for applications that find  
themselves completely dependent on the extension.

One might ask whether this is critical; after all the INVITE exchange  
will tell us what info packages (if any) the far end is willing to  
use. What is the difference between not using INFO packages and not  
supporting them?

The answer is in the fallback to pre-package INFO behavior. A node  
supporting INFO packages will, IIRC (or at least "if I get my way") ,  
always use packages when sending INFO. A node not supporting INFO  
packages is likely to send old-style un-negotiated INFO, meaning you  
might need to be prepared with that behavior. Being informed (by  
Supported) which state applies might be useful.

--
Dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Nov 2008 19:32:33 +0100

You seem to be arguing that packages themselves may need to have option
tags, rather than the extension itself, which does not answer the
question I asked. 

What I asked was whether there was a need to have an option tag
specifically for the info-package extension.

There were no option tags for pre package info behaviour, so there is no
information to tell you that if I don't support the new extension that I
supported the previous incarnation of INFO. So I do not see how that can
be used for fallback.

regards

Keith

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Thursday, November 20, 2008 6:24 PM
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; Elwell, John; Eric Burger; SIP List
> The option tag is used in OPTIONS responses (and in Supported 
> header fields in other responses) to inform a correspondent 
> that the node in question supports this extension, 
> potentially leading to a decision as to which behavior to 
> apply to future requests.
> 
> It is also used in Require header fields of requests to cause 
> the request to be rejected by any UAS that does not 
> understand the extension.  This is potentially critical for 
> applications that find themselves completely dependent on the 
> extension.
> 
> One might ask whether this is critical; after all the INVITE 
> exchange will tell us what info packages (if any) the far end 
> is willing to use. What is the difference between not using 
> INFO packages and not supporting them?
> 
> The answer is in the fallback to pre-package INFO behavior. A 
> node supporting INFO packages will, IIRC (or at least "if I 
> get my way") , always use packages when sending INFO. A node 
> not supporting INFO packages is likely to send old-style 
> un-negotiated INFO, meaning you might need to be prepared 
> with that behavior. Being informed (by
> > I think you need to provide more than this in terms of 
> explanation.  
> > What
> >> One option would have been to define an info feature tag which can 
> >> list package value, and each package could then specify a value.
> >>
> >> But, I am ok with John's proposal also, but I think we should add 
> >> some text as suggested by Keith.
> >>
> >>
> >> Option-tag:
> >> -----------
> >>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 20 Nov 2008 20:30:26 +0100

Hi Keith,

My proposal is that we define an option tag for the EXTENSION - like we do for most other extensions.

Whether we have a feature tag for the extension, or separate feature tags for each package, has nothing to do with the option tag.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: DRAGE, Keith (Keith) [mailto:[email-masked]]
Lähetetty: to 20.11.2008 19:32
Vastaanottaja: Dean Willis
Kopio: Christer Holmberg; Elwell, John; Eric Burger; SIP List
Aihe: RE: [Sip] INFO Framework: Tags

regards

Keith

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Nov 2008 14:41:43 -0600

> tags, rather than the extension itself, which does not answer the

That is not my intent. I'm talking about the use of option tags to say  
"Yes, I support the concept of info-packages" vs "I do not support the  
concept of info-packages".

> specifically for the info-package extension.

yes, and that's what I tied to answer.

> supported the previous incarnation of INFO. So I do not see how that  

If I don't support info-packages, then I MIGHT support old-info. If I  
do, then I MIGHT understand an INFO (or the legacy set), and I MIGHT  
send you one (from the legacy set). But I'm very, very unlikely to  
understand any of the new CID-indirection-to-select-a-body, multiple- 
body stuff, so don't send it!

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Nov 2008 17:08:37 -0500

Dean Willis wrote:

> understand any of the new CID-indirection-to-select-a-body, 
> multiple-body stuff, so don't send it!

Dean,

You don't need an option tag for this. After the invite, I can't send 
you an info package unless you have provided a Recv-Info for it.

	Thanks,
	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Nov 2008 23:11:20 +0100

Sorry, but you seem to have a use case that is relying on the absence of
an option tag to tell you....

....absolutely nothing. 

regards

Keith

> Sent: Thursday, November 20, 2008 8:42 PM
> To: DRAGE, Keith (Keith)
> > You seem to be arguing that packages themselves may need to have 
> > option tags, rather than the extension itself, which does 
> not answer 
> > the question I asked.
> >
> 
> That is not my intent. I'm talking about the use of option 
> tags to say "Yes, I support the concept of info-packages" vs 
> "I do not support the concept of info-packages".
> 
> > There were no option tags for pre package info behaviour, 
> so there is 
> > no information to tell you that if I don't support the new 
> extension 
> > that I supported the previous incarnation of INFO. So I do 
> not see how 
> > that can be used for fallback.
> 
> If I don't support info-packages, then I MIGHT support 
> old-info. If I do, then I MIGHT understand an INFO (or the 
> legacy set), and I MIGHT send you one (from the legacy set). 
> But I'm very, very unlikely to understand any of the new 
> CID-indirection-to-select-a-body, multiple- body stuff, so 
> don't send it!
> 
> --
> Dean
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Nov 2008 17:15:08 -0500

Dean Willis wrote:
> will tell us what info packages (if any) the far end is willing to use. 
> What is the difference between not using INFO packages and not 
> supporting them?
> 

This really can't be so.

I may support a legacy info usage because I need to do so to 
interoperate with some class of devices that use it and don't do the new 
info stuff. That package works just fine, so there is no reason to 
define a new info-package for the same purpose. So that may not get 
done. Yet for new functionality I use info packages.

In such an environment I may well use a combination of legacy infos and 
info packages.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Nov 2008 16:47:16 -0600

On Nov 20, 2008, at 4:08 PM, Paul Kyzivat wrote:

>
>
> Dean Willis wrote:
>
>> If I don't support info-packages, then I MIGHT support old-info. If  
>> I do, then I MIGHT understand an INFO (or the legacy set), and I  
>> MIGHT send you one (from the legacy set). But I'm very, very  
>> unlikely to understand any of the new CID-indirection-to-select-a- 
>> body, multiple-body stuff, so don't send it!
>
> Dean,
>
> You don't need an option tag for this. After the invite, I can't  
> send you an info package unless you have provided a Recv-Info for it.

Okay, I'm willing to believe that.

What if I have an application that really, really requires info- 
packages, so I want the call to fail if you can't handle them?

Would this arise, or would it always be preferable to complete the  
INVITE exchange, then tear the call down once I find out that you don't?

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Nov 2008 23:49:50 +0100

In which case you need an option tag for the info package itself.

Noone is precluding that.

regards

Keith 

> Sent: Thursday, November 20, 2008 10:47 PM
> To: Paul Kyzivat
> Cc: DRAGE, Keith (Keith); SIP List; Elwell, John; Christer Holmberg
> old-info. If I 
> >> understand any of the new CID-indirection-to-select-a- body, 
> What if I have an application that really, really requires 
> info- packages, so I want the call to fail if you can't handle them?
> 
> Would this arise, or would it always be preferable to 
> complete the INVITE exchange, then tear the call down once I 
> find out that you don't?
> 
> --
> Dean
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 20 Nov 2008 23:53:13 +0100

Hi,

I still think we shall have an option tag for the extension itself.

Eventhough it does not gurantee that the UAS supports specific info
packages, at least you can use it to help finding a UAS which supports
the extensions (by using the sip.extensions feature tag).

And, as Dean said, it can be used with OPTIONS.

Regards,

Christer

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Friday, November 21, 2008 12:50 AM
To: Dean Willis; Paul Kyzivat
Cc: SIP List; Elwell, John; Christer Holmberg
Subject: RE: [Sip] INFO Framework: Tags

regards

Keith

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 20 Nov 2008 23:56:08 +0100

But what does an option tag in OPTIONS tell you over and above a 200
(OK) response to OPTIONS with a Recv-Info header. 

regards

Keith

> Sent: Thursday, November 20, 2008 10:53 PM
> To: DRAGE, Keith (Keith); Dean Willis; Paul Kyzivat
> Cc: SIP List; Elwell, John
> Eventhough it does not gurantee that the UAS supports 
> specific info packages, at least you can use it to help 
> finding a UAS which supports the extensions (by using the 
> sip.extensions feature tag).
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 20 Nov 2008 23:57:56 +0100

Hi, 

Probably nothing.

But, it can still be used for the forking.

Regards,

Christer

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 21 Nov 2008 00:03:31 +0100

You fork OPTIONS requests?

Keith 

> Sent: Thursday, November 20, 2008 10:58 PM
> complete the

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Nov 2008 17:16:07 -0600

No, you use the options tag with a sip.extensions media feature tag  
ala RFC 3840 in order to get a retargeting proxy to send the request  
only to the subset of UAS that support the extension.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 21 Nov 2008 01:02:18 +0100

You fork INVITE requests.

And, an INVITE request which contains sip.extension=info can be forked
to a UAS which has registered support of info.

Regards,

Christer 

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Friday, November 21, 2008 1:04 AM
To: Christer Holmberg; Dean Willis; Paul Kyzivat
Cc: SIP List; Elwell, John
Subject: RE: [Sip] INFO Framework: Tags

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Nov 2008 19:03:25 -0500

I just don't get how getting selectively to UAs that support *some* info 
package is useful for anything.

	Thanks,
	Paul

Dean Willis wrote:
> 
> 
> No, you use the options tag with a sip.extensions media feature tag ala 
> RFC 3840 in order to get a retargeting proxy to send the request only to 
> the subset of UAS that support the extension.
> 
> -- 
> Dean
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 21 Nov 2008 05:28:46 +0100

>I just don't get how getting selectively to UAs that support *some*
info package is useful for anything.

Well, it's better than choosing a UA which doesn't support any packages.

But, of course additional feature tags would be needed in many cases.

In any case, I don't see why it would be such a big deal to define an
option tag, like we do for other extensions.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 21 Nov 2008 04:45:50 +0000

Christer, 

> Sent: 20 November 2008 22:53
[JRE] I haven't heard a compelling argument for this. Keep it simple.

> And, as Dean said, it can be used with OPTIONS.
[JRE] And I haven't heard a compelling argument for this. Keep it
simple.

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 21 Nov 2008 04:45:49 +0000

> Sent: 20 November 2008 22:47
> To: Paul Kyzivat
> old-info. If  
[JRE] This might arise on a per-package basis, in which case the spec
that defines that package can also define the option tag. I can't see it
arising in a package-independent context, so we don't need an option tag
for the extension as a whole.

PLEASE try to keep this extension as simple as possible - this option
tag / media feature tag business adds complexity. Are we really trying
to dissuade people from implementing this extension?

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 21 Nov 2008 04:45:51 +0000

Dean, 

> Sent: 20 November 2008 23:16
> To: DRAGE, Keith (Keith)
> Cc: Christer Holmberg; Paul Kyzivat; SIP List; Elwell, John
[JRE] RFC 3841 does not compel a proxy to behave in this way, and in
fact the proxy might not even support RFC 3841. So you have to be
prepared for your INVITE/Recv-Info to go to any UAS. I don't in general
see a need to specify this as part of the extension in general, but if a
particular package needs a feature tag, let it define one. Keep the
extension simple.

John

> specific info

---

From: Dean Willis <[email-masked]>
Date: Thu, 20 Nov 2008 23:40:50 -0600

On Nov 20, 2008, at 10:45 PM, Elwell, John wrote:

> fact the proxy might not even support RFC 3841.

RFC 3840/3841 can insure such behavior, and (with Proxy-require) can  
assure that the proxy either supports the extension or  rejects the  
call.

> So you have to be
> prepared for your INVITE/Recv-Info to go to any UAS.

well, it MIGHT do so, and fail in a predictable way as a consequence  
due to the Require: info-package. That's not a bad thing.

> I don't in general

Only standards-track RFCs can define SIP option tags under RFC 3427,  
and we have no plans to relax this requirement.

But we have a much looser policy for INFO packages; most will not be  
standards-track.

So, for those sorts of packages, an info-package option tag is  
potentially quite useful.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 21 Nov 2008 13:16:11 +0100

John,

What is "un-simple" by defining an option tag value??? We have done that
many times before...

Regards,

Christer

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, November 21, 2008 6:46 AM
To: Christer Holmberg; DRAGE, Keith (Keith); Dean Willis; Paul Kyzivat
Cc: SIP List
Subject: RE: [Sip] INFO Framework: Tags

Christer, 

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 21 Nov 2008 13:20:45 +0000

Christer,

OK, it might be simple, but still unnecessary, so why do it. I haven't
heard a compelling argument in its favour. Per-package option tags are
far more compelling (depending on particular needs of a package),
although I agree such packages would need a standards track document.

John 

> Sent: 21 November 2008 12:16
> To: Elwell, John; DRAGE, Keith (Keith); Dean Willis; Paul Kyzivat
> Cc: SIP List

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Nov 2008 08:57:57 -0500

Dean Willis wrote:

> Only standards-track RFCs can define SIP option tags under RFC 3427, and 
> we have no plans to relax this requirement.
> 

For that to be useful, each package would need its own option. While I 
guess we could define things such that each info-package registration 
implied a corresponding option tag registration, then that would be an 
end-around of the standards-track requirement for defining option tags. 
We really don't want that, or we will have people defining info-packages 
they don't intend to use, just to get an option tag.

	Thanks,
	Paul

---

From: Bob Penfield <[email-masked]>
Date: Fri, 21 Nov 2008 10:29:01 -0500

I agree with John. There is no compeling reason to include an option tag. An info-package that actually needs an option tag would need to be defined in a standards track document.

Keep it simple.

Less is more.

cheers,
(-:bob

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Elwell, John [[email-masked]]
Sent: Friday, November 21, 2008 8:20 AM
To: Christer Holmberg; DRAGE, Keith (Keith); Dean Willis; Paul Kyzivat
Cc: SIP List
Subject: Re: [Sip] INFO Framework: Tags

Christer,

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 21 Nov 2008 16:31:20 +0100

Hi,

I agree that we don't need to define option tags for each info-package.
>From a SIP perspective the extension (indicated by the option tag) is
the capabilty of transporting info-packages, not the info-packages
themselves.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, November 21, 2008 3:58 PM
To: Dean Willis
Cc: Elwell, John; SIP List; DRAGE, Keith (Keith); Christer Holmberg
Subject: Re: [Sip] INFO Framework: Tags

Dean Willis wrote:

>> I don't in general
>> see a need to specify this as part of the extension in general, but 
>> if a particular package needs a feature tag, let it define one. Keep 
>> the extension simple.
> 

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Nov 2008 10:59:54 -0500

I agree with John too.  I don't see the benefit.  It would be beneficial to have one for a specific package, for example dtmf, maybe, but not the mechanism.  It's like having an option tag to support the Allow/Accept/Supported headers, as opposed to their values.  This draft is basically just a negotiation mechanism and defining how to handle things - not the things themselves.

We'll still have the method name "INFO" for the Allow header, if you want to say you can't do INFO requests.

-hadriel

> Sent: Friday, November 21, 2008 8:21 AM

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Nov 2008 10:05:53 -0600

On Nov 21, 2008, at 9:59 AM, Hadriel Kaplan wrote:

>
> I agree with John too.  I don't see the benefit.  It would be  
> beneficial to have one for a specific package, for example dtmf,  
> maybe, but not the mechanism.  It's like having an option tag to  
> support the Allow/Accept/Supported headers, as opposed to their  
> values.  This draft is basically just a negotiation mechanism and  
> defining how to handle things - not the things themselves.
>

If you need to do some generic non-standards track info-package, how  
do you quickly weed out all the old phones that don't do info-packages  
at all?

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Nov 2008 11:27:37 -0500

> Sent: Friday, November 21, 2008 11:06 AM
>

You create an option-tag for the specific package.  Weeding out the "old phones" won't be enough, because many new phones won't do your package anyway.  Such a shotgun approach is kinda useless.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Nov 2008 13:13:47 -0600

On Nov 21, 2008, at 10:27 AM, Hadriel Kaplan wrote:

> You create an option-tag for the specific package.  Weeding out the  
> "old phones" won't be enough, because many new phones won't do your  
> package anyway.  Such a shotgun approach is kinda useless.
>

But that requires the specific package be a standards-track RFC. Many  
won't be.

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Nov 2008 13:15:24 -0600

On Nov 21, 2008, at 7:57 AM, Paul Kyzivat wrote:

>> Only standards-track RFCs can define SIP option tags under RFC  
>> 3427, and we have no plans to relax this requirement.
>> But we have a much looser policy for INFO packages; most will not  
>> be standards-track.
> For that to be useful, each package would need its own option.

Not exactly. If I know you don't support info-packages at all, I can  
readily presume you don't support any specific info-package, including  
those non-STD-track packages that can't possibly have their own SIP  
options tag.

Having discovered via OPTIONS that you support info-packages, I could  
then decide to offer the specific package needed in an INVITE. This  
can weed out a lot of abortive calls.

Without the info-package tag, I can't use OPTIONS to decide whether or  
not you support info-packages, and must probe with a real-live INVITE  
(which could make things a bit strange with lots of ring-answer-hangup  
calls).

Sure, if every UA supports info-package as a concept this isn't  
useful. But in a transitional phase (which is what we have) where a  
great many UAs are not supporting it al all, it's better than a call- 
and-hangup probe.

> While I guess we could define things such that each info-package  
> registration implied a corresponding option tag registration, then  
> that would be an end-around of the standards-track requirement for  
> defining option tags. We really don't want that, or we will have  
> people defining info-packages they don't intend to use, just to get  
> an option tag.
>

I agree heartily.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Nov 2008 14:40:00 -0500

> Sent: Friday, November 21, 2008 2:14 PM
>

No it doesn't, not in practice.  Only in some theoretical fantasy world.  We're talking about a vendor who makes a proprietary package, and doesn't want it to be used in general.  You think a vendor who does that, and needs to have a way to have endpoints Register the fact they can do it in a Supported header, or needs a way to check if the far-end does it in an Options, will say "oh gee I wish I could put something in the Supported and/or Require header but the IETF won't let me"??  You guys crack me up. :)

And don't get me wrong: I don't mean this in the sense that we should give up specs because people don't follow them.  I just mean that the use-case you're specifically talking about is a *vendor-proprietary* use-case, so why should we go provide some standard means to help them make it more easily deployable with themselves, if the means to do so already exist in a proprietary fashion *without* interop problems with those of us who follow the specs?  Because putting an unregistered option name in Supported/Require should work with the same semantic behavior registered ones do no matter who you talk to.  Unless someone has gone and built a box that does lookups against IANA databases every time it gets a message with an option tag it doesn't recognize and rejects it if not. ;)

All we have to do for vendor-proprietary users of INFO is make sure they interoperate with those of us who don't have them, by letting them discover we don't support them. (which is what recv-info does)  We don't need to work to give them more features.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Nov 2008 13:51:28 -0600

On Nov 21, 2008, at 1:40 PM, Hadriel Kaplan wrote:
>
> All we have to do for vendor-proprietary users of INFO is make sure  
> they interoperate with those of us who don't have them, by letting  
> them discover we don't support them. (which is what recv-info does)   
> We don't need to work to give them more features.
>

But the caller can't get to the recv-info until it  does an INVITE. I  
don't want to be getting INVITES for calls that are going to have to  
be dropped because I don't do info-packages at all. . .

--
Dean

---

From: Bob Penfield <[email-masked]>
Date: Fri, 21 Nov 2008 14:55:53 -0500

This is a corner case. If you require info-packages to make a call work, it sounds to me that whatever you are sending in the info is not appropriate for info and ought to be separate stream described in the SDP.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean Willis
Sent: Friday, November 21, 2008 2:51 PM
To: Hadriel Kaplan
Cc: SIP List
Subject: Re: [Sip] INFO Framework: Tags

--
Dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 21 Nov 2008 20:57:57 +0100

Well you seem to be arguing for the need for an option tag in a Require
header field rather than in a Supported header field. These are a
barrier to interoperability and therefore need to be very carefully
considered. 

The basis for your argument still seems to be very much: lets define one
because I might want one in the future. Conversely it might be: I need
an option tag but its use will be so perverted that I do not dare tell
the IETF community about it.

Keith

> Sent: Friday, November 21, 2008 4:29 AM
> To: Paul Kyzivat; Dean Willis
> Cc: DRAGE, Keith (Keith); SIP List; Elwell, John
> In any case, I don't see why it would be such a big deal to 
> define an option tag, like we do for other extensions.
> 
> Regards,
> 
> Christer
> 
> 
> Dean Willis wrote:
> > 
> > 
> >>>>> INVITE exchange, then tear the call down once I find 
> out that you 
> >>>>> don't?
> >>>>>
> >>>>> --
> >>>>> Dean
> >>>>>
> >>>>
> >>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 21 Nov 2008 15:07:30 -0500

> be dropped because I don't do info-packages at all. . .

You won't, and if you do nothing we do will prevent it.  As you said, most devices won't do Info-packages to begin with.  If a vendor who makes a proprietary info package creates it in such a way that call attempts fail if the other side doesn't do their info-package, then they're way too dumb to put a generic info-package option tag in Require header anyway.

And again, having it for the generic info-package concept won't be good enough either - as soon as you support any info-package at all, then all of the sudden their call attempts start ringing and failing because you don't support their specific proprietary one.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Nov 2008 14:42:40 -0600

On Nov 21, 2008, at 1:55 PM, Bob Penfield wrote:

>
> This is a corner case. If you require info-packages to make a call  
> work, it sounds to me that whatever you are sending in the info is  
> not appropriate for info and ought to be separate stream described  
> in the SDP.

No weirder than requiring support for automatic answering mode.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Nov 2008 14:44:34 -0600

> barrier to interoperability and therefore need to be very carefully

An option tag, once defined, can be used in Require, Supported (in all  
requests, probe with an OPTIONS), and in RFC 3840/3841 caller  
preferences/callee capabilities selective routing.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Nov 2008 00:02:48 -0500

> Sent: Friday, November 21, 2008 3:45 PM
>

I wonder sometimes if we didn't screw up making any registered option tag automatically usable in both Supported and Require.  Developers or product managers seem to not understand that putting something in Require means the call attempt will fail sometimes, and that users and operators are really really unhappy if call attempts fail.
100rel, for example, is sometimes put in Require with dire unintended consequences.

-hadriel

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 23 Nov 2008 03:23:04 +0100

The issue here is if they hit some other proprietary usage of the same
string in an option-tag. If it is an entirely closed space they should
get away with it, but in this case they can just declare the support to
be mandatory in both entities anyway.

In any case, where any info-packages are being deployed out into general
UE space, I hope that the vast majority of these info-packages do not
need the dialog to fail if the package is not supported. In which case
we are talking about option tag needs being very much a corner case.

regards

Keith

> Behalf Of Hadriel Kaplan
> Sent: Friday, November 21, 2008 7:40 PM
> To: Dean Willis
> Cc: SIP List
> No it doesn't, not in practice.  Only in some theoretical 
> fantasy world.  We're talking about a vendor who makes a 
> proprietary package, and doesn't want it to be used in 
> general.  You think a vendor who does that, and needs to have 
> a way to have endpoints Register the fact they can do it in a 
> Supported header, or needs a way to check if the far-end does 
> it in an Options, will say "oh gee I wish I could put 
> something in the Supported and/or Require header but the IETF 
> won't let me"??  You guys crack me up. :)
> 
> And don't get me wrong: I don't mean this in the sense that 
> we should give up specs because people don't follow them.  I 
> just mean that the use-case you're specifically talking about 
> is a *vendor-proprietary* use-case, so why should we go 
> provide some standard means to help them make it more easily 
> deployable with themselves, if the means to do so already 
> exist in a proprietary fashion *without* interop problems 
> with those of us who follow the specs?  Because putting an 
> unregistered option name in Supported/Require should work 
> with the same semantic behavior registered ones do no matter 
> who you talk to.  Unless someone has gone and built a box 
> that does lookups against IANA databases every time it gets a 
> message with an option tag it doesn't recognize and rejects 
> it if not. ;)
> 
> All we have to do for vendor-proprietary users of INFO is 
> make sure they interoperate with those of us who don't have 
> them, by letting them discover we don't support them. (which 
> is what recv-info does)  We don't need to work to give them 
> more features.
> 
> -hadriel

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 23 Nov 2008 03:32:33 +0100

But now you are making the assumption that all info-packages require the
call to fail if I do not support the info package. 

By default, we must make the ordinary assumption we make for all
extensions, i.e. that we can discard the information if it is not
understood. 

regards

Keith

> Behalf Of Dean Willis
> Sent: Friday, November 21, 2008 7:51 PM
> To: Hadriel Kaplan
> Cc: SIP List
> But the caller can't get to the recv-info until it  does an 
> INVITE. I don't want to be getting INVITES for calls that are 
> going to have to be dropped because I don't do info-packages 
> at all. . .
> 
> --
> Dean
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 23 Nov 2008 09:55:44 -0500

So far the devices I've seen which do proprietary option-tags in Supported generally stick to the rfc2543 defined way of doing it with the reverse domain name concept, to avoid name collision.  This is in fact how some vendors are doing negotiation of proprietary-INFO right now. (you can google to see this)

And yes I agree with you that using a package type that needs the dialog to fail if the other side doesn't do it is really a bad idea or a corner case.  I believe MSCML would have been an example of one that would have made sense for it, maybe.  Camera control could be another one.

-hadriel

> Sent: Saturday, November 22, 2008 9:23 PM
> To: Hadriel Kaplan; Dean Willis
> Cc: SIP List

---

From: Dean Willis <[email-masked]>
Date: Sun, 23 Nov 2008 22:21:21 -0600

> call to fail if I do not support the info package. 

No, I'm not. I'm saying that SOME non-standards-track INFO packages will
need the call to fail if the far end does not support INFO packages. If
they don't need it to fail, they shouldn't use the options tag in a
Require directive.

This is pretty basic stuff, kids. Why are you making it so darned hard?

> extensions, i.e. that we can discard the information if it is not

Don't even get me started on explaining the blatant hypocrisy in that
statement when compared to the extensions driven from 3GPP ;-).

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Nov 2008 00:56:02 -0500

> Sent: Sunday, November 23, 2008 11:21 PM
>

Again, if a non-standards-track INFO package needs its info package, they'll do non-standard things to get the behavior they need, by putting their non-standard package name in Require, and it works.  It is not necessary for us to help them.  And again doing a check for the generic info-package draft support is not sufficient to accomplish their goal anyway, because as soon as another device supports the draft but not their specific non-standard one, they're back to square one.  So it's neither necessary nor sufficient.  What is there to debate over?

> This is pretty basic stuff, kids. Why are you making it so darned hard?

Because it's easier (and cheaper) to debate this now than to handle the tech-support calls later.

> statement when compared to the extensions driven from 3GPP ;-).

But that's why we're in the IETF and not 3GPP.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Nov 2008 07:41:33 -0600

Hadriel Kaplan wrote:
> 
>> -----Original Message----- From: Dean Willis
>> [mailto:[email-masked]] Sent: Sunday, November 23, 2008
>> 11:21 PM
>> 
>>> But now you are making the assumption that all info-packages
>>> require the call to fail if I do not support the info package.
>> No, I'm not. I'm saying that SOME non-standards-track INFO packages
>> will need the call to fail if the far end does not support INFO
>> packages. If they don't need it to fail, they shouldn't use the
>> options tag in a Require directive.
> 
> Again, if a non-standards-track INFO package needs its info package,
> they'll do non-standard things to get the behavior they need, by
> putting their non-standard package name in Require, and it works.  It
> is not necessary for us to help them.  And again doing a check for
> the generic info-package draft support is not sufficient to
> accomplish their goal anyway, because as soon as another device
> supports the draft but not their specific non-standard one, they're
> back to square one.  So it's neither necessary nor sufficient.  What
> is there to debate over?
> 
> 

I see things differently -- the reason we have trouble with our specs is
we've required everything useful to go through standardization with a
very high level of review required. Hence, people have done the simple
things and just implemented non-standard solutions without the safety
mechanisms of standard solutions. Personally, I'd like to see options
tags available for informational documents, experimental documents,
thrid-party specifications, and even first-come, first-served
vendor-tree extensions. But that is NOT the process we have.

In you own words in other messages on this thread you explain how the
vendors will happily do non-standard stuff if they need to get get
things done, like invent their own option tag for an unregistered info
package. Why should we force them to do that?

--
dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Nov 2008 10:34:21 -0500

> Sent: Monday, November 24, 2008 8:42 AM
>
> very high level of review required.

There are all sorts of reasons we have trouble with our specs, but one of them is not the amount of review required, but that we add in "features" or corner-cases into mechanisms that make them more complicated than the problem actually being addressed needs it to be.  Because that makes the spec more complicated, the review takes longer and thus it takes a lot longer to stop changing and reach RFC status; and the spec being more complicated and taking longer means vendors just do their own thing or don't implement them as expected.

Info-packages is a classic example of this.  We have little hope of vendors implementing it if it ends up being complicated, because there is already an INFO mechanism today that works for their needs.

> Hence, people have done the simple

Why is that, BTW?  What was the rationale for changing option-tag use between 2543 and 3261?

> package. Why should we force them to do that?

That is a different question than "should we have an info-package draft option tag".  I'm fine with providing a way for non-standard uses of Foo to identify their non-standard Foo in Supported.  But I guess that requires an update to 3261?

-hadriel

---

From: Bob Penfield <[email-masked]>
Date: Mon, 24 Nov 2008 11:33:19 -0500

The thing that makes me most uncomfortable with an option tag for info-packages is that it is expanding the scope of an option tag from a single well-defined extension/feature to a whole class of features that are not necessarily related. I see it as being analogous to defining an option tag for event-packages that could be used to fail calls because the UAS does not support SUBSCRIBE/NOTIFY. The other thing that is bothersome is that one day, the calls are failing for your mystery application, the next day they succeed because the UAS was upgraded to support SOME info-package, but not your mystery feature and you will have to terminate successful calls because of it.

I think we should change the section about OPTIONS to require the UAS to include its supported info-packages in the response if the request had a Recv-Info header. That way you could probe the far end if you really require your info-package to be there.

cheers,
(-:bob

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Nov 2008 14:22:39 -0600

> use between 2543 and 3261?

There was some well-founded concern that other SIP-using SDOs would  
use flexible extensibility specification to essentially rewrite SIP  
into a more-tentacled leviathan than it currently is, and that making  
extensions STD-RFC-required would force them back to the IETF for  
sanity review. There is widespread opinion that the specification  
divergence was reduced by this.

Of course, there is also widespread opinion that we should surrender  
SIP to the telephone world, wash our hands, and go back to solving  
Internet problems, so you have to pick your opinions carefully.

> That is a different question than "should we have an info-package  
> draft option tag".  I'm fine with providing a way for non-standard  
> uses of Foo to identify their non-standard Foo in Supported.  But I  
> guess that requires an update to 3261?

Update to RFC 3427, actually, since that updates the specification  
strengths of 3261.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 25 Nov 2008 00:19:10 +0100

Hadriel wrote:

> That is a different question than "should we have an 
> info-package draft option tag".  I'm fine with providing a 
> way for non-standard uses of Foo to identify their 
> non-standard Foo in Supported.  But I guess that requires an 
> update to 3261?

Changing RFC 3261 is entirely possible. You write a draft that updates
it.

But we need to think through why that was made that way in the first
place.

I think you yourself have admitted that option-tags in Require headers
are overused (and abused). Therefore I believe if we relax the IANA
registration requirement for registering new ones, we also need to
address how we stop people putting them in Require headers when they do
not need to.

regards

Keith

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Monday, November 24, 2008 3:34 PM
> To: Dean Willis
> Cc: DRAGE, Keith (Keith); SIP List
> > I see things differently -- the reason we have trouble with 
> our specs 
> > is we've required everything useful to go through 
> standardization with 
> > a very high level of review required.
> 
> There are all sorts of reasons we have trouble with our 
> specs, but one of them is not the amount of review required, 
> but that we add in "features" or corner-cases into mechanisms 
> that make them more complicated than the problem actually 
> being addressed needs it to be.  Because that makes the spec 
> more complicated, the review takes longer and thus it takes a 
> lot longer to stop changing and reach RFC status; and the 
> spec being more complicated and taking longer means vendors 
> just do their own thing or don't implement them as expected.
> 
> Info-packages is a classic example of this.  We have little 
> hope of vendors implementing it if it ends up being 
> complicated, because there is already an INFO mechanism today 
> that works for their needs.
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 24 Nov 2008 18:22:20 -0500

> Sent: Monday, November 24, 2008 6:19 PM
>
> Hadriel wrote:
>

Which is why I carefully put the word "Supported" in my statement: "to identify their non-standard Foo in Supported".  :)

-hadriel

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 25 Nov 2008 00:51:39 +0100

> Update to RFC 3427, actually, since that updates the specification  

It's difficult to tell whether RFC 3427 updates RFC 3261 in this
respect. It certainly does not change the IANA requirements, but it is
unclear whether it is restating the existing requirements, or just
mentioning them in an aside for completeness.

Either way, it is currently required to be standards track RFC, but you
can change it with another standards track RFC if you so wish to start
the process for one.

Keith

> Sent: Monday, November 24, 2008 8:23 PM
> To: Hadriel Kaplan
> > Why is that, BTW?  What was the rationale for changing 
> option-tag use 
> > between 2543 and 3261?
> >
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Nov 2008 20:06:21 -0600

On Nov 24, 2008, at 10:33 AM, Bob Penfield wrote:

> The thing that makes me most uncomfortable with an option tag for  
> info-packages is that it is expanding the scope of an option tag  
> from a single well-defined extension/feature to a whole class of  
> features that are not necessarily related. I see it as being  
> analogous to defining an option tag for event-packages that could be  
> used to fail calls because the UAS does not support SUBSCRIBE/NOTIFY.

We have one; SUBSCRIBE. If it doesn't show in the Supported methods,  
don't send a SUBSCRIBE.

Unfortunately, INFO method support is not enough, as there are  
prepackage INFO implementations in the wild. So we have three cases to  
differentiate: No INFO, Old INFO, and new INFO packages.

> The other thing that is bothersome is that one day, the calls are  
> failing for your mystery application, the next day they succeed  
> because the UAS was upgraded to support SOME info-package, but not  
> your mystery feature and you will have to terminate successful calls  
> because of it.

But now you can look at the info package negotiation and figure out  
that it does not support the mystery-package, and tell what other  
packages it does support (and write the application to adapt to the  
available packages).
>
> I think we should change the section about OPTIONS to require the  
> UAS to include its supported info-packages in the response if the  
> request had a Recv-Info header. That way you could probe the far end  
> if you really require your info-package to be there.

While that makes perfect sense, it is inconsistent with the use of  
OPTIONS tags in RFC 3261. I'd like to change that part of 3261  
someday . . .

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 24 Nov 2008 20:13:13 -0600

> address how we stop people putting them in Require headers when they  

Wow! It really hurts when I strike my back with these knotted cords.  
But when I do it long enough, I get these nifty visions of a perfect  
architecture . . .

Maybe I should stop? Maybe I should invite my friends to do it too?

In other words, pain is the only educational tool we have. When it  
hurts, they'll either stop doing it, or make a religious cult out of  
the experience and encourage other people to play along.

Either way, the physics are the same.