Subject: [Sip] INFO and what to do about it?

From: Dean Willis <[email-masked]>
Date: Tue, 17 Jun 2008 17:27:12 -0500

We've been batting INFO around for many, many years now (like, 10 --  
it predates the SIP working group). A couple of meetings back, we  
agreed that we would discuss use cases for INFO packages, and if we  
didn't find any consensus there, then we would go ahead and publish an  
"INFO Considered Harmful" RFC.

We tried having this discussion at the last IETF, but that just didn't  
work out.

Do we try again, or just give up and publish "INFO Considered Harmful"?

Personally, I don't care anymore -- I just want to drive a stake into  
the heart of this undead-thing, cut off its head, stuff the mouth with  
holy wafers, and bury it at a crossroads somewhere.

But this WG only slays by consensus, so what do you want?

--
Dean

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Jun 2008 18:32:10 -0400

Thanks for raising this, Dean.

I think the issue here is not so much 'what do we do about INFO', but 
rather, what are the actual extensibility models people are using with 
SIP and are we properly providing the techniques to make it all 
interoperate. In my mind, that is a really important issue.

In terms of what to do, I think we should absolutely define an INFO 
framework along the lines of Hadriel's draft, and we should produce a 
guidelines document which helps people figure out whether to use INFO, 
event packages, or something along the lines of a media framework like I 
had proposed with TOTE (separate question on whether to pursue TOTE or 
not).

I think the huge number of actual INFO usages, along with the many 
reasonable use cases we have identified, make a clear statement that 
this is something that is needed.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Jun 2008 19:22:08 -0400

> holy wafers, and bury it at a crossroads somewhere.

I gave my try, very unsuccessfully. So I just want to remind you not to 
forget the garlic, the silver cross, and the sunlight.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 18 Jun 2008 05:37:15 +0200

Hi,

I agree with Jonathan.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
Sent: 18. kesäkuuta 2008 1:32
To: Dean Willis
Cc: [email-masked]
Subject: Re: [Sip] INFO and what to do about it?

I think the issue here is not so much 'what do we do about INFO', but rather, what are the actual extensibility models people are using with SIP and are we properly providing the techniques to make it all interoperate. In my mind, that is a really important issue.

In terms of what to do, I think we should absolutely define an INFO framework along the lines of Hadriel's draft, and we should produce a guidelines document which helps people figure out whether to use INFO, event packages, or something along the lines of a media framework like I had proposed with TOTE (separate question on whether to pursue TOTE or not).

I think the huge number of actual INFO usages, along with the many reasonable use cases we have identified, make a clear statement that this is something that is needed.

-Jonathan R.

Dean Willis wrote:
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
> 

This 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: "Mary Barnes" <[email-masked]>
Date: Wed, 18 Jun 2008 14:41:02 -0500

As Jonathan noted, there is a clear need for something, as I don't see
folks giving up on using INFO at all and providing some
structure/standardization around the use is a good thing. The following
documents are a good starting place IMHO:
http://tools.ietf.org/id/draft-kaplan-sip-info-use-cases-01.txt
http://tools.ietf.org/id/draft-kaplan-sip-info-events-01.txt
http://tools.ietf.org/id/draft-kaplan-sipping-dtmf-package-00.txt

As far as providing guidelines on what approaches folks should use
depending upon requirements and problem statements, I agree with
Jonathan that a document of this sort would be useful, perhaps using
this document as a starting point:
http://tools.ietf.org/id/draft-rosenberg-sip-info-litmus-00.txt 

We would of course need to decide how to partition the work either using
the traditional SIP/SIPPING split of new SIP headers, etc. in SIP and
event packages, informational docs, etc. in SIPPING or possibly consider
this as a test case for your (Dean's) proposal of starting new WGs for
new work items, since it would seem that in the end there could be a
reasonable handful of work items to progress and the work could be
fairly tightly scoped. Although, I fear this group would have the same
difficulty in reaching a stopping point as SIP/SIPPING in terms of folks
wanting to define new INFO event packages.

Likely, the most contentious topic of debate is whether we need to
define a general extensibility model.  Given we don't have a lot of use
cases (other than cases where we've already completed work or well on
the way to completing), it's kinda tough to say that if we build it,
folks will use it.  So, personally, my opinion would be to defer this
topic until we see a real need, although I realize there's a risk of not
being able to deliver this in a timely manner if we wait, particularly
given past history on how quickly we can complete work items.  However,
in one sense I feel that it's just way too late to do this sort of thing
(at least in SIP 2.0). 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Tuesday, June 17, 2008 5:27 PM
To: [email-masked]
Subject: [Sip] INFO and what to do about it?

We've been batting INFO around for many, many years now (like, 10 -- it
predates the SIP working group). A couple of meetings back, we agreed
that we would discuss use cases for INFO packages, and if we didn't find
any consensus there, then we would go ahead and publish an "INFO
Considered Harmful" RFC.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Jun 2008 23:08:55 -0500

> But this WG only slays by consensus, so what do you want?

Several people (Jonathan, Mary, Christer, Paul) have responded to the  
list  with various things that added up to "Publish INFO packages AND  
document the extension models for SIP". So far, nobody has suggested  
otherwise.

Does anybody want to do anything else? Speak now or forever visualize  
whirled peas.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 20 Jun 2008 14:15:48 -0400

[Not surprisingly] I also think we should just do it.  I don't know if it will succeed, but the longer we wait the less the probability it will.  Right now people have to provision devices to send XYZ thing in INFO, and different vendors are using different syntaxes/means for the same mechanism, and I loathe that.  If we want to stop devices in the middle from meddling, we need to stop giving them reasons to.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Thursday, June 19, 2008 12:09 AM
> To: [email-masked]
> Cc: Cullen Jennings; Jon Peterson

---

From: "Rafferty, James" <[email-masked]>
Date: Fri, 20 Jun 2008 14:32:13 -0400

I agree with Hadriel on this one.  I'm getting requests for different oddball uses of INFO all of the time, most of them driven by the need to interoperate with deployed applications.  Creating real INFO packages would give us a way to increase the likelihood of interoperability for the different uses.  Is it too late?  Hard to say, but it is worth a shot.   

James    

James Rafferty 
Product Line Director, Integrated Media Gateways 
Dialogic, Inc.  
15 Crawford Street 
Needham, MA 02494 
USA 

Tel:    781 433 9462
Mobile: 781 929 3895
Fax:    781 433 9268
Email:  [email-masked]
Web:    www.dialogic.com
This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Friday, June 20, 2008 2:16 PM
To: Dean Willis; [email-masked]
Cc: Cullen Jennings; Jon Peterson
Subject: Re: [Sip] INFO and what to do about it?

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 19 Jun 2008 17:49:00 -0600

Personally, I'd like to see some coherent discussion around it in a WG  
meeting then try to get to consensus on it. The totally number of  
people bothering to follow the conversation at this point is extremely  
low.

---

From: [email-masked]
Date: Sat, 21 Jun 2008 19:10:44 +0000

If people care, I'll work, but if nobody cares, I won't.
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Cullen Jennings <[email-masked]>

Date: Thu, 19 Jun 2008 17:49:00 
To:Dean Willis <[email-masked]>
Cc:[email-masked], Jon Peterson <[email-masked]>
Subject: Re: [Sip] INFO and what to do about it?

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sat, 21 Jun 2008 17:59:10 -0400

Deployments and support of INFO is a reality, unlike some of the other
(@#$ in SIP.

So either you believe it is real, or you hide your head under the covers
and pretend that there are no ghosts in the closet. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Saturday, June 21, 2008 3:11 PM
To: [email-masked]
Subject: Re: [Sip] INFO and what to do about it?

---

From: Dean Willis <[email-masked]>
Date: Sat, 21 Jun 2008 17:57:02 -0500

Cullen Jennings wrote:
> meeting then try to get to consensus on it. The totally number of people 
> bothering to follow the conversation at this point is extremely low.

We tried to do that in the last meeting, but I seem to remember AD 
intervention taking our agenda time away.

So it's do it on the list, or don't do it at all, as far as I can tell.

To be honest, I'd say that we have the people who usually pat attention 
to SIP work paying attention now, and the people who usually don't aren't.

--
dean

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 21 Jun 2008 19:15:37 -0400

I'm with Eric on this. I worked for awhile and the results seemed 
futile, so I'm not overly motivated to start again. But if there is some 
possibility of reaching a conclusion then I'll join in.

Certainly I agree with Martin that there are lots of deployments and 
support for INFO in some form. But most of them are non-standard in one 
way or another. And I think this leaves us in a Catch-22 situation:

- we can just bless unrestricted use of INFO. But that would serve no 
purpose, and wouldn't enhance interoperability.

- or we can formalize rules for negotiating usages of INFO. That will 
provide the potential of enhanced interop. But then all the existing 
deployments will be incompatible with it.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Sun, 22 Jun 2008 23:16:02 -0500

> deployments will be incompatible with it.

That sounds like a vote for defaulting and publishing Eric's original
"Why you shouldn't use INFO for anything" draft.

---

From: "Xavier Marjou" <[email-masked]>
Date: Mon, 23 Jun 2008 11:20:16 +0200

My opinion is that INFO is used a lot in SIP whatever people like it
or not. It should thus be accepted, as well as corrected in its
details if some minor aspects need to be enhanced.

The work done in draft-kaplan-sip-info-events goes this direction and
should thus become a WG item.

Cheers,
Xavier

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Jun 2008 07:41:00 -0700

On Jun 21, 2008, at 3:57 PM, Dean Willis wrote:

> Cullen Jennings wrote:
>> Personally, I'd like to see some coherent discussion around it in a  
>> WG meeting then try to get to consensus on it. The totally number  
>> of people bothering to follow the conversation at this point is  
>> extremely low.
>

Dean, a room full a 100+ people in the sipping meeting took a hum and  
decided much to my surprise to not add an evening meeting. I realize  
we wish there was more time but there is not and it is unlikely there  
will be more time in Dublin. The best we can do is carefully pick what  
topics we do choose to use the time we do have on. I will note there  
was not enough interest in this to get an interim meeting to happen.    
I would not exactly describe this as AD intervention.

> To be honest, I'd say that we have the people who usually pat  
> attention to SIP work paying attention now, and the people who  
> usually don't aren't.
>
> --
> dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Jun 2008 11:44:01 -0400

> Cullen Jennings
> Sent: Monday, June 23, 2008 10:41 AM
>
> decided much to my surprise to not add an evening meeting.

I wasn't there, but my impression from talking with others was that there was concern over having a late-night meeting given some WG's were going to be meeting early the following morning.

> I realize

I doubt any single topic in the SIP/SIPPING/etc. working groups would by itself be sufficient to warrant an interim meeting, so that's hardly a fair litmus test.

Personally I'd prefer an interim meeting specifically to get most of the current mostly-done WG items out of the way and off of the next full-meeting agenda, and just try to get consensus hums for the outcome of the interim at the full-meeting since they're not likely to be contentious; but my guess is you can't do that at an interim?

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 23 Jun 2008 11:02:03 -0500

On Jun 23, 2008, at 9:41 AM, Cullen Jennings wrote:

>>> Personally, I'd like to see some coherent discussion around it in  
>>> a WG meeting then try to get to consensus on it. The totally  
>>> number of people bothering to follow the conversation at this  
>>> point is extremely low.
>>
> Dean, a room full a 100+ people in the sipping meeting took a hum  
> and decided much to my surprise to not add an evening meeting. I  
> realize we wish there was more time but there is not and it is  
> unlikely there will be more time in Dublin. The best we can do is  
> carefully pick what topics we do choose to use the time we do have  
> on. I will note there was not enough interest in this to get an  
> interim meeting to happen.   I would not exactly describe this as AD  
> intervention.

No, I was talking about the 4 hour agenda request that got cut to 2  
hours along with the instruction to "focus only on chartered work".

INFO is interesting, but it's not on our milestone list.

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jun 2008 11:16:02 -0500

FYI,  we actually had the meeting targetted as a SIPPING WG adhoc:
https://www3.ietf.org/proceedings/08mar/slides/sipping-0/sipping-0_files
/frame.htm  (Chart 16)

Personally, I was in favor of an interim to discuss that topic as well
as other critical WG items. In the past, interims have really helped in
progressing key WG items.  As I understand, one roadblock for some folks
is travel approval (my proposal had been to hold the interim in Dallas
before or after the GEOPRIV interim).  It might be useful to plan
earlier for interims to allow folks to consider this in travel budgets
sooner (i.e., some of us do these quarterly and having it in the plan
earlier allows it to be approved with all other travel and can be
considered/prioritized with other travel requests, whereas if it comes
later, it requires special approval and is often challenged given
today's business environment). 

I will note that Keith did try to schedule a teleconference on this
topic, however, the quorom of key people were not available.  However,
in general, I do think regular teleconferences for the WGs with authors
to progress key topics would be useful. Recognizing that you can't get
everyone all the time, rotating time slots might help.

I don't think it's apathy or lack of interest in topics as much as many
folks I've communicated with have increased day job workloads, so the
amount of time focused on IETF has dramatically increased for some
folks. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dean Willis
Sent: Monday, June 23, 2008 11:02 AM
To: Cullen Jennings
Cc: [email-masked]; Jon Peterson
Subject: Re: [Sip] INFO and what to do about it?

On Jun 23, 2008, at 9:41 AM, Cullen Jennings wrote:

>>> WG meeting then try to get to consensus on it. The totally number of

>>> people bothering to follow the conversation at this point is 
>>> extremely low.
>>

> was not enough interest in this to get an

---

From: Robert Sparks <[email-masked]>
Date: Mon, 23 Jun 2008 12:27:30 -0500

Paul's two points resonate with me.

Does anyone expect that if we _did_ build a usage framework for INFO,  
that we would somehow take the existing uses and retroactively declare  
them standard and part of that framework without change?

If that were possible, what's the difference between that and just  
documenting them as is and declaring them standard without this  
framework.

So I don't see how building this framework will solve the kind of  
problem that Martin was punctation-charactering about.

As Paul points out, creating the framework might provide better  
interoperability for some _new_ use, but the level of effort someone  
would have to go through to get the usage standardized is not going to  
be easier than standardizing it on its own. So having its not going to  
do the person that wants a nifty new feature any real good.

If we had a truckload of things that would use the framework bursting  
at the seams waiting for the framework, we'd all, I'm betting,
happily work very quickly to create it. I don't see this truckload of  
things.  The existing uses are out there and they're not going to  
change (so far when I've asked folks with features build on INFO if  
they'd change their code to use this framework once it existed,  
they've laughed).

So if we do anything at all, I'd favor finishing the work Paul started.

RjS

On Jun 21, 2008, at 6:15 PM, Paul Kyzivat wrote:

> futile, so I'm not overly motivated to start again. But if there is  
> some possibility of reaching a conclusion then I'll join in.
>
> support for INFO in some form. But most of them are non-standard in  
> one way or another. And I think this leaves us in a Catch-22  
> situation:
>
> - we can just bless unrestricted use of INFO. But that would serve  
> no purpose, and wouldn't enhance interoperability.
>
> - or we can formalize rules for negotiating usages of INFO. That  
> will provide the potential of enhanced interop. But then all the  
> existing deployments will be incompatible with it.
>
> 	Paul
>
>> and pretend that there are no ghosts in the closet. -----Original  
>> Message-----
>> Date: Thu, 19 Jun 2008 17:49:00 To:Dean Willis <[email-masked] 
>> >

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 23 Jun 2008 19:33:33 +0200

Hi Robert,

INFO is out there, true, and I am not sure we can do much about that. I don't think the intention is to standardize the current usages.

I think the idea of the framework is for FUTURE INFO usages. Because, I don't think we can assume there won't be more usages in the future than we currently have - even if we would try to "forbid" INFO.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 23. kesäkuuta 2008 20:28
To: Paul Kyzivat
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
Subject: Re: [Sip] INFO and what to do about it?

Does anyone expect that if we _did_ build a usage framework for INFO, that we would somehow take the existing uses and retroactively declare them standard and part of that framework without change?

If that were possible, what's the difference between that and just documenting them as is and declaring them standard without this framework.

So I don't see how building this framework will solve the kind of problem that Martin was punctation-charactering about.

As Paul points out, creating the framework might provide better interoperability for some _new_ use, but the level of effort someone would have to go through to get the usage standardized is not going to be easier than standardizing it on its own. So having its not going to do the person that wants a nifty new feature any real good.

If we had a truckload of things that would use the framework bursting at the seams waiting for the framework, we'd all, I'm betting, happily work very quickly to create it. I don't see this truckload of things.  The existing uses are out there and they're not going to change (so far when I've asked folks with features build on INFO if they'd change their code to use this framework once it existed, they've laughed).

RjS

On Jun 21, 2008, at 6:15 PM, Paul Kyzivat wrote:

>> Deployments and support of INFO is a reality, unlike some of the 
>> other (@#$ in SIP.
>> So either you believe it is real, or you hide your head under the 
>> covers and pretend that there are no ghosts in the closet. 
>> -----Original
>> Message-----
>> Sent from my Verizon Wireless BlackBerry -----Original Message-----
>>> Several people (Jonathan, Mary, Christer, Paul) have responded to 
>>> the list  with various things that added up to "Publish INFO 
>>> packages AND document the extension models for SIP". So far, nobody 
>>> has suggested otherwise.
>>>
>>> Does anybody want to do anything else? Speak now or forever 
>>> visualize whirled peas.
>>>
>>> --
>>> Dean
>>>
>>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Jun 2008 13:40:00 -0400

What was "the work Paul started"?  You mean Eric's draft?

-hadriel

> Robert Sparks
> Sent: Monday, June 23, 2008 1:28 PM
> To: Paul Kyzivat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2008 13:48:10 -0400

How about this?

Define the new INFO usage framework, for new uses of INFO, along the 
lines proposed by Hadriel and others. As part of that, establish a 
registry or registries.

Incorporate into that a grandfather clause. If your usage of INFO 
predated some specified date then it will be permitted to be registered, 
but not standardized. Presumably the registration would have to be based 
on Content-Type, since AFAIK that is all that really works for existing 
usages. The registry for these grandfathered usages would have to point 
to *some* specification of the usage. It could be be an individual 
informational RFC, or a document by some other SDO. (What else would 
make sense?)

Existing *standard* usages of INFO (the few there are) would also fall 
under this grandfather clause. In that case there is an RFC to refer to.

*New* usages, after the specified date, would be ineligible for 
registration under the grandfather clause. They would be required to use 
the new formal usage mechanism.

(Damn, I'm allowing myself to be sucked into this again.)

	Thanks,
	Paul

Robert Sparks wrote:
> documenting them as is and declaring them standard without this framework.
> 
> If we had a truckload of things that would use the framework bursting at 
> the seams waiting for the framework, we'd all, I'm betting,
> things.  The existing uses are out there and they're not going to change 
> (so far when I've asked folks with features build on INFO if they'd 
> change their code to use this framework once it existed, they've laughed).
> 
>> one way or another. And I think this leaves us in a Catch-22 situation:
>>
>>> Date: Thu, 19 Jun 2008 17:49:00 To:Dean Willis 
>>> <[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2008 13:48:52 -0400

I forget who the last proposal was from, but it wasn't me.

	Paul

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jun 2008 12:46:45 -0500

I don't believe we could ever forbid INFO. I initially did not think we could accomplish anything around INFO, but I believe some of the work that's on the table would be useful for working towards interoperabilty for the INFO usages. I would be afraid to ask honestly for the identification of all the different uses of INFO that are out there right now. 

Doing something is better than nothing at this point IMHO and I'm personally really tired of revisiting this issue every couple of years. AND, this would help us put a stake in the group on the future usages of INFO (whether we ever get rid of the old usages or not), as I believe there are other SDOs defining new uses of INFO right now to add to the mix of un-interoperability in this area.

My two cents,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, June 23, 2008 12:34 PM
To: Robert Sparks; Paul Kyzivat
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
Subject: Re: [Sip] INFO and what to do about it?

Hi Robert,

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Sparks
Sent: 23. kesäkuuta 2008 20:28
To: Paul Kyzivat
Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS
Subject: Re: [Sip] INFO and what to do about it?

RjS

On Jun 21, 2008, at 6:15 PM, Paul Kyzivat wrote:

>> <[email-masked]
>> >

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: Robert Sparks <[email-masked]>
Date: Mon, 23 Jun 2008 12:52:12 -0500

But you did do a lot of the early hard lifting and that's what I was  
nodding towards.

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Jun 2008 13:54:27 -0400

> Sent: Monday, June 23, 2008 12:16 AM
> >

The EXACT same thing could be said for deprecating/outlawing info:
"We can just restrict the use of INFO.  But that would serve no purpose, and wouldn't enhance interoperability."

> "Why you shouldn't use INFO for anything" draft.

Ummm... I don't see how that solves the: "But then all existing deployments will be incompatible with it" concern.  All existing deployments would _still_ be incompatible with such a "don't-use info" draft.

Or is the argument: "there would be no way to make this backwards compatible"?  I think it would be backwards compatible.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 23 Jun 2008 13:23:17 -0500

On Jun 23, 2008, at 12:48 PM, Paul Kyzivat wrote:

> predated some specified date then it will be permitted to be  
> registered, but not standardized. Presumably the registration would  
> have to be based on Content-Type, since AFAIK that is all that  
> really works for existing usages. The registry for these  
> grandfathered usages would have to point to *some* specification of  
> the usage. It could be be an individual informational RFC, or a  
> document by some other SDO. (What else would make sense?)
>
> Existing *standard* usages of INFO (the few there are) would also  
> fall under this grandfather clause. In that case there is an RFC to  
> refer to.
>
> registration under the grandfather clause. They would be required to  
> use the new formal usage mechanism.
>

That works for me. It's quite rational, given where we find ourselves,  
and fits with the goal of "reducing further damage."

> (Damn, I'm allowing myself to be sucked into this again.)

I'm so sorry ;-).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jun 2008 09:25:10 -0400

Mary Barnes wrote:
> I don't believe we could ever forbid INFO. I initially did not think
> we could accomplish anything around INFO, but I believe some of the
> work that's on the table would be useful for working towards
> interoperabilty for the INFO usages. I would be afraid to ask
> honestly for the identification of all the different uses of INFO
> that are out there right now.

I don't think we should be afraid of this at all.

There are (sometimes/often) good reasons why folks resort to these 
solutions. Our job here at IETF is to ensure interoperability for the 
SIP protocol. If we don't listen to our customers - the people who have 
deployed and are actually using it - what purpose does our work serve?

> 
> Doing something is better than nothing at this point IMHO and I'm
> personally really tired of revisiting this issue every couple of
> years. AND, this would help us put a stake in the group on the future
> usages of INFO (whether we ever get rid of the old usages or not), as
> I believe there are other SDOs defining new uses of INFO right now to
> add to the mix of un-interoperability in this area.

As long as SIP usage continues to rise, I suspect we will continue to 
see more INFO usages. Just because we cannot fix what is broken in the 
past, doesn't mean we should let it remain broken for the future.

-Jonathan R.

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 24 Jun 2008 08:45:23 -0500

Just a couple more points of clarification on my view embedded below
[MB].

Mary

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2008 8:25 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; [email-masked]; DOLLY,
MARTIN C, ATTLABS

Mary Barnes wrote:
> interoperabilty for the INFO usages. I would be afraid to ask honestly

> for the identification of all the different uses of INFO that are out 
> there right now.

I don't think we should be afraid of this at all.
[MB] My guess (based on what I've seen) is that a lot of vendors would
have around a half dozen (+- 2). Now, some of those might overlap given
there is some level of interop between various vendors. [/MB]

[MB] My experience is that at least half the uses of INFO were in place
when the protocol was quite immature (i.e., well before RFC 3261). And,
we indeed should listen to our customers by providing a flexible
platform for them to do the things they need to do. IMHO, it's been loud
and clear in the past that they want to use INFO and in the past, docs
like "Info considered harmful" weren't helpful towards this end. [/MB]

[MB] I'm not at all disagreeing on this point. Optimistically, I'd like
to see the current implementations evolve to support this new approach
as it will improve interoperability. If the WG can complete this work in
a timely manner (perhaps the biggest issue given past performance), then
the potential for uptake for a standardized implementation is INFO is
far higher IMHO. If we can get this work chartered, then we're far more
likely to get uptake by the other SDOs far sooner than if we continue to
dillydally. And, it's important to remember that this isn't the only
area where there are interoperability issues. And, actually, per SFSIW-1
the use of INFO was not a common theme - either because it was a given
or it's not as big an issue as some of us are assuming - in a quick scan
I only found one document discussing the use of INFO.  [/MB]

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2008 10:00:32 -0400

Mary,

My latest thought is that we should "grandfather" existing uses of INFO. 
We would provide a registry of them, without blessing them or 
standardizing their specifications. That would at least shine some light 
in the dark corners.

At the same time, we would define the new INFO usage framework (still 
TBD) and ban *new* INFO usages that don't follow it.

I think that would be better than the current situation, and about as 
good as we can expect to achieve.

	Thanks,
	Paul

---

From: "Mary Barnes" <[email-masked]>
Date: Tue, 24 Jun 2008 09:00:58 -0500

Paul,

The grandfathering is aa good  suggestion and likely far more pragmatic
than my optimistic approach that they'll evolve. I will go ahead and
ping our folks and see how they feel about this.  If others will do the
same, I think we'll have some very interesting results.

Thanks,
Mary

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2008 9:01 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Jonathan Rosenberg; Christer Holmberg; Robert Sparks; [email-masked];
DOLLY, MARTIN C, ATTLABS

Mary,

	Thanks,
	Paul

Mary Barnes wrote:
> Cc: Christer Holmberg; Robert Sparks; Paul Kyzivat; [email-masked]; 
> DOLLY, MARTIN C, ATTLABS
>> honestly

> have around a half dozen (+- 2). Now, some of those might overlap 
> given there is some level of interop between various vendors. [/MB]
> 
> SIP protocol. If we don't listen to our customers - the people who 
> have deployed and are actually using it - what purpose does our work
serve?
> 
> [MB] My experience is that at least half the uses of INFO were in 
> place when the protocol was quite immature (i.e., well before RFC 
> 3261). And, we indeed should listen to our customers by providing a 
> flexible platform for them to do the things they need to do. IMHO, 
> it's been loud and clear in the past that they want to use INFO and in

> the past, docs like "Info considered harmful" weren't helpful towards 
> this end. [/MB]
> 

> [MB] I'm not at all disagreeing on this point. Optimistically, I'd 
> like to see the current implementations evolve to support this new 
> approach as it will improve interoperability. If the WG can complete 
> this work in a timely manner (perhaps the biggest issue given past 
> performance), then the potential for uptake for a standardized 
> implementation is INFO is far higher IMHO. If we can get this work 
> chartered, then we're far more likely to get uptake by the other SDOs 
> far sooner than if we continue to dillydally. And, it's important to 
> remember that this isn't the only area where there are 
> interoperability issues. And, actually, per SFSIW-1 the use of INFO 
> was not a common theme - either because it was a given or it's not as 
> big an issue as some of us are assuming - in a quick scan I only found

> one document discussing the use of INFO.  [/MB]
> 
> -Jonathan R.
> 
>

---

From: "Michael Procter" <[email-masked]>
Date: Tue, 24 Jun 2008 16:18:27 +0100 (BST)

> TBD) and ban *new* INFO usages that don't follow it.

I agree.  The framework proposed in draft-kaplan-sip-info-events-01 seems
like a step in the right direction.

And I agree with registering existing uses.   Even if existing uses aren't
updated to use the negotiation mechanism suggested (or whatever solution
the WG converges on), I think there is value in strongly encouraging the
adoption of the 'Info-Package' header (or similar).  This shouldn't
noticeably affect interop of legacy devices, but marking the requests like
this would allow more recent devices to act appropriately in the presence
of multiple incompatible non-standard extensions.  Not that such things
exist, of course!

Regards,

Michael

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Tue, 24 Jun 2008 11:24:14 -0400

Hi, all:

It appears that we are almost close to have an agreement on this topic.

The basic analysis needs to be made why people like to use INFO for so many purposes in SIP.

If the WG can abstract those requirements for usages of INFO and can prepare the INFO spec to meet those requirements, there will be no need for "proprietary" usages by vendors.

If the WG fails to meet the above requirements, no matter what is done now or in the future will NOT stop the usage of INFO using proprietary schemes. If the past history provide any lessons, it will be a total failure.

The bottom line is this: The future INFO spec MUST meet the basic requirements for which people are tempted to sue this in the first place.

Best regards,
Radhika

----- Original Message -----
From: Mary Barnes 
Date: Tuesday, June 24, 2008 10:04
Subject: Re: [Sip] INFO and what to do about it?
To: Paul Kyzivat 
Cc: [email-masked], "DOLLY, MARTIN C, ATTLABS" , Christer Holmberg 

> Paul,
> 
> The grandfathering is aa good suggestion and likely far more 
> pragmaticthan my optimistic approach that they'll evolve. I will 
> go ahead and
> Cc: Jonathan Rosenberg; Christer Holmberg; Robert Sparks; 
> [email-masked];DOLLY, MARTIN C, ATTLABS
> standardizing their specifications. That would at least shine some 
> lightin the dark corners.
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Jun 2008 11:52:26 -0500

inline

On Jun 24, 2008, at 9:00 AM, Paul Kyzivat wrote:

> Mary,
>
> My latest thought is that we should "grandfather" existing uses of  
> INFO. We would provide a registry of them, without blessing them or  
> light in the dark corners.
>
> At the same time, we would define the new INFO usage framework  
> (still TBD) and ban *new* INFO usages that don't follow it.

Well, if we don't think banning INFO as a whole would be listened to,  
why do we think banning INFO that doesn't use this new framework would  
be listened to?

That's where I'm having difficulty with the question. I can see the  
bite of work it would take to make the framework.
I'm still trying to see what would actually use it if we did?
Can somebody list the packages that we've already identified that we  
would put out with this framework?

>
>
> I think that would be better than the current situation, and about  
> as good as we can expect to achieve.

I'm still not convinced it makes it better. One outcome I can see from  
following this path is two years from now finding ourselves with no  
actual packages using the framework and  a set of _new_ INFO based  
applications in the field that _don't_ use the framework.

Will we continue to put those in this proposed registry above? Or do  
we just have another set of practices that we have to treat the  
current non-standardized INFO uses with now?

The bet we would be placing by putting the work into creating this  
framework is that it actually takes some motivation away from using a  
non-standard bare INFO to realize some new application (and that there  
are new applications out there where this would be a really good tool  
to have to realize them). Is this framework really lowering a barrier  
to entry or relieving some other pain so that the people who would  
otherwise make a new non-standard use of INFO come use it? I'm having  
a really hard time seeing that.

If we end up on the wrong side of that bet, we've arguably made things  
_worse_ taking work away from other things, creating mechanics that  
have to be implemented, tested and will ultimately be abused, and not  
solving the actual problem in the first place.

So, I'll continue to look for some evidence this will actually get  
used and relieves some pressure to just go use INFO in a proprietary  
way and skip all this standards pain (hopefully folks here can help me  
with this).

Without it, I think the better path would be to create the registry  
you describe, publish an informational document pointing out the  
pitfalls of the approaches they take, and get on with other work.

I'll also, of course, accept a community decision to just do this work  
and take the risk of losing the bet and help make sure we build the  
best framework possible if that's where we really want to go. I just  
hope somebody can convince me we're not trading off other work we  
could be benefiting from more to find ourselves in effectively the  
same position two years from now.

RjS

>> From: Jonathan Rosenberg [mailto:[email-masked]] Sent: Tuesday,  
>> June 24, 2008 8:25 AM
>> DOLLY,
>>> I don't believe we could ever forbid INFO. I initially did not  
>>> think we could accomplish anything around INFO, but I believe some  
>>> of the work that's on the table would be useful for working  
>>> towards interoperabilty for the INFO usages. I would be afraid to  
>>> ask honestly
>>> for the identification of all the different uses of INFO that are  
>>> out there right now.
>> given
>> have
>> place
>>> years. AND, this would help us put a stake in the group on the  
>>> future usages of INFO (whether we ever get rid of the old usages  
>>> or not), as I believe there are other SDOs defining new uses of  
>>> INFO right now to add to the mix of un-interoperability in this  
>>> area.
>> like

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 24 Jun 2008 10:11:11 -0700

>If we don't listen to our customers - the people who have

This is what the managers of the typewriter business must have said when the
word processors appeared: "Our customers ask for a white-out ribbon and for
a price under $500."

A PC at that time cost $5,000 and the additional laser printer was another
$5,000.

Some companies opted for the PC business nevertheless and did NOT listen to
their customers.

Does anyone care for simple SIP that can be understood by developers with
limited time on their hands?

Henry

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 24 Jun 2008 11:33:44 -0600

I've been reading this thread and so far, it seems that folks are
recommending one or more of the following approaches:
1) do nothing
2) document what's out there in some ways
   (as informational or a new class of WCP RFCs,
worst-current-practices)
3) define new framework for info 
   (as part of the standard track)
   Eric's info draft-02 intended to obsolete 2976 and still showing
intended status as standard track.

The intended audience is both implementers and users (end-users,
enterprise, operators).  
--- implementers
I believe implementers are faced with a basic problem when deciding what
to implement: what other vendor products is my implementation supposed
to interoperate with? Is that other implementation in my customer's
hands.  If so, what is that other vendor implementing for this
pseudo-info functionality.  Correct me if I'm wrong but I think this
often leads to the INFO path for all the uses Eric documented.  Even if
an implementer argues that KPML should be used to pass digits on the
signaling path, if the customer has a box that has INFO for that, they
will likely do info and argue later because there is often little room
for a user/operator to ask for an upgrade of the already deployed box
for a new entrant.
	=> implementers' vote count and what would they choose?
	   Likely:
              1 (because they don't care, those hacks get driven by
customers to interwork with existing gears or they build products in
between UAs...)
	        2 (because they'd like to avoid defining yet a new hack
and would rather code an INFO mechanism to address the maximum number of
implementations out there)
	  Other Opinions?

--- users
While some architects push for pure standard solutions, the reality is
often darker.  Users have often a service or application goal and if it
takes an INFO to get the job done given a box in the field, so be it.
They will try to ask for better solutions in upcoming releases (some of
which never address the INFO hacks which is the problem).
	=> users' opinion count and what would they choose?
	   Likely:
              2 (because they'd like to point to a document and say: I
use this as my UA on my PC/network, and it supports INFO as defined by
that doc section X.Y).
	  Other Opinions?

2 seems at a first sight to be the best worst thing to do.  But doing 2
is a slippery slope for the IETF though: is INFO worth it?  What about
the call diversion headers we can't seem to get rid of in favor of the
their alternative standard-track mechanisms?
It would be good to see a more detailed draft documenting the uses of
INFO (with actual snippets) and some rational numbers indicating how
many implementers (& releases of their code) support those, and how many
users have those.  That could be beneficial to just discuss what to do,
if anything.

Jean-Francois.

> Sent: Tuesday, June 24, 2008 10:52 AM
> To: Paul Kyzivat
> Cc: [email-masked]; DOLLY, MARTIN C, ATTLABS; Mary Barnes; Christer
> Holmberg
> >> when the protocol was quite immature (i.e., well before RFC
> 3261).
> >> And,
> >> platform for them to do the things they need to do. IMHO, it's
> been
> >> loud
> >> and clear in the past that they want to use INFO and in the
> past,
> >> docs
> >> like "Info considered harmful" weren't helpful towards this end.
> [/
> >> MB]
> >> see more INFO usages. Just because we cannot fix what is broken
> in
> >> the
> >> a timely manner (perhaps the biggest issue given past
> performance),
> >> then
> >> far higher IMHO. If we can get this work chartered, then we're
> far
> >> more
> >> or it's not as big an issue as some of us are assuming - in a
> quick
> >> scan

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2008 13:47:46 -0400

Let me be clear: for the grandfathering part, I am suggesting that we 
develop a registry of *existing* usage, not that those existing usages 
change in any way. I want to get them written down, so at least there is 
a place to look to find out about something unknown to you, and to 
ensure nothing new gets defined that is in conflict with something old.

If those existing usages can be updated to use the new framework that 
would be better yet. But I'm not going to hold my breath waiting for 
that to happen.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2008 14:03:43 -0400

Robert,

I will agree that the scenario you pose is a possibility. And if it 
seems probable then we should do nothing.

The carrot we could offer would be the registry. New usages would get 
into the registry, but new usages of INFO without the framework would 
not be eligible for the registry.

Whether that is perceived as a carrot is an open question. It may be 
that most existing usages that haven't come through ietf don't *wish* to 
be public. If not, then there is nothing we can do.

	Paul

Robert Sparks wrote:
> That's where I'm having difficulty with the question. I can see the bite 
> of work it would take to make the framework.
> Will we continue to put those in this proposed registry above? Or do we 
> just have another set of practices that we have to treat the current 
> non-standardized INFO uses with now?
> 
> are new applications out there where this would be a really good tool to 
> have to realize them). Is this framework really lowering a barrier to 
> entry or relieving some other pain so that the people who would 
> otherwise make a new non-standard use of INFO come use it? I'm having a 
> really hard time seeing that.
> 
> _worse_ taking work away from other things, creating mechanics that have 
> to be implemented, tested and will ultimately be abused, and not solving 
> the actual problem in the first place.
> 
> So, I'll continue to look for some evidence this will actually get used 
> and relieves some pressure to just go use INFO in a proprietary way and 
> skip all this standards pain (hopefully folks here can help me with this).
> 
> Without it, I think the better path would be to create the registry you 
> describe, publish an informational document pointing out the pitfalls of 
> the approaches they take, and get on with other work.
> 
> and take the risk of losing the bet and help make sure we build the best 
> framework possible if that's where we really want to go. I just hope 
> somebody can convince me we're not trading off other work we could be 
> benefiting from more to find ourselves in effectively the same position 
> two years from now.
> 
> RjS
> 
> 
>>
>>
>>     Thanks,
>>     Paul
>>
>> Mary Barnes wrote:
>>>> future usages of INFO (whether we ever get rid of the old usages or 
>>>> not), as I believe there are other SDOs defining new uses of INFO 
>>>> right now to add to the mix of un-interoperability in this area.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jun 2008 14:05:53 -0400

Henry,

You seem to be changing philosophy here. These existing uses of INFO are 
*running code*. Why doesn't that make them the good candidates for 
standardization?

	Paul

---

From: "Michael Procter" <[email-masked]>
Date: Tue, 24 Jun 2008 20:11:04 +0100

Paul Kyzivat wrote:
> change in any way. I want to get them written down, so at least there
> is a place to look to find out about something unknown to you, and to

Exactly.  I agree with all this, and recognise it as a good start.

I went on to propose a half-way house between no changes for legacy
uses, and full adoption of a new framework.  A lightweight[0] framework
may[1] attract new uses, but the negotiation features present in
Hadriel's current draft seem likely to deter the migration of legacy
uses.  I am merely suggesting that using the INFO-labelling part of
Hadriel's draft but not the negotiation aspect could seem more
attractive[2] to legacy uses, and would still provide the rest of the
community some value (namely being able to identify all the INFO
messages flying around their networks).

Michael

[0] Both the implementation and documentation needs to be lightweight 
IMO.
[1] RjS' email discusses this further, and he seems less optimistic.
[2] Low implementation cost, relatively low risk, no additional stateful
behaviour required.

>>> INFO.
>>> (still

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 Jun 2008 14:12:49 -0500

On Jun 24, 2008, at 11:52 AM, Robert Sparks wrote:
> framework is that it actually takes some motivation away from using  
> a non-standard bare INFO to realize some new application (and that  
> there are new applications out there where this would be a really  
> good tool to have to realize them). Is this framework really  
> lowering a barrier to entry or relieving some other pain so that the  
> people who would otherwise make a new non-standard use of INFO come  
> use it? I'm having a really hard time seeing that.
>

Well, that's the whole reason we write RFCs instead of just telling  
people to innovate, isn't it?

> If we end up on the wrong side of that bet, we've arguably made  
> things _worse_ taking work away from other things, creating  
> mechanics that have to be implemented, tested and will ultimately be  
> abused, and not solving the actual problem in the first place.
>
> way and skip all this standards pain (hopefully folks here can help  
> me with this).
>

Don't use INFO. By the way, here's the "standard required" process for  
registering your non-standard INFO use by MIME-type and content- 
disposition. . . Don't blame us when it kills you, or you have to  
register a new MIME or content-disposition because somebody already  
signed up for the one you want to use.

I kind of like that approach. Can we do the same thing with P-headers?  
It'd sure save us a lot of work.

---

From: [email-masked]
Date: Tue, 24 Jun 2008 20:20:52 +0000

Here is my prognostication: if we document current usage, that is what will be used. I'm in a foul enough mood to suggest we document curent usage to foster some semblance of interoperation, do the honorable thing and note why life sucks, and then consider our work done. I would offer that any framework we come up would be nothing more than an academic exercise. I can already hear people say we need to publish how to interwork this new framework with Cisco INFO DTMF because, golly gee, that is the only thing their deployed equipment supports.
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Dean Willis <[email-masked]>

Date: Tue, 24 Jun 2008 14:12:49 
To:Robert Sparks <[email-masked]>
Cc:[email-masked], "DOLLY, MARTIN C, ATTLABS" <[email-masked]>,Paul Kyzivat <[email-masked]>, Mary Barnes <[email-masked]>,Christer Holmberg <[email-masked]>
Subject: Re: [Sip] INFO and what to do about it?

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Jun 2008 16:54:10 -0400

> Michael Procter

I don't think there's much value in documenting the labeling part without negotiation.  One of the main issues right now is you don't know which INFO mechanisms the far end wants/needs/supports.  There isn't really much issue with discerning what the INFO you received was for once you got it, 'cause the content-type has been unambiguous so far for all of the current usages I think (or majority thereof).  It was the potential for content-type ambiguity in the future that was one of the concerns of INFO, but the real driver for me at least is the "what does the other end want/expect" problem.

I'm all for making the "negotiation" part as trivial and KISS as possible - I started with what I thought was trivial, but people wanted to pile onto it to cover 3PCC and other scenarios.  I'm cool with going back to simple as a better-than-nothing approach. :)

-hadriel

---

From: "Michael Procter" <[email-masked]>
Date: Tue, 24 Jun 2008 22:15:44 +0100

Hadriel Kaplan wrote:
> I don't think there's much value in documenting the labeling part
> without negotiation.  One of the main issues right now is you don't
> know which INFO mechanisms the far end wants/needs/supports.  There
> isn't really much issue with discerning what the INFO you received was
> for once you got it, 'cause the content-type has been unambiguous so
> far for all of the current usages I think (or majority thereof).  It
> was the potential for content-type ambiguity in the future that was
> one of the concerns of INFO, but the real driver for me at least is
> the "what does the other end want/expect" problem.

That is exactly the use-case that I am concerned with.  I've seen more
than one 'application/xml' to date, and whilst I have so far been able
to disambiguate those based on content analysis, I fear more are on the
way.

But on reflection, I suppose that vendors unwilling to declare their
content more precisely are unlikely to add a new header instead.

> I'm all for making the "negotiation" part as trivial and KISS as
> possible - I started with what I thought was trivial, but people
> wanted
> to pile onto it to cover 3PCC and other scenarios.  I'm cool with
> going
> back to simple as a better-than-nothing approach. :)

I'll leave it in your capable hands then!

Regards,

Michael

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 24 Jun 2008 14:35:02 -0700

> You seem to be changing philosophy here.

Not at all. The philosophy is very simple:

Use "simple SIP" - basically the rendezvous and session setup functions, be
they CS or P2P.

Everything else related to SIP applications and customer demands (I
understand Jonathan's desire) can be better accomplished with API's, SDKs,
IDE's and various tool kits as is customary in the industry.

(Unfortunately we have other tools: Concept papers, frameworks, etc.)

This presumes however respecting the e2e Internet principle, the "dumb
network" architecture and the applications in the endpoints.

Henry