Subject: Re: [Sipping] Requirements for the identificationof IMScommunicationservices.

From: "Andrew Allen" <[email-masked]>
Date: Sun, 26 Mar 2006 01:51:11 -0500

Dean

Dean Willis wrote:
"network based service" is a misnomer, as we all know that the only 
network-based services are packet forwarding, routing topology 
management, and just possibly (but not usually in IP) admissions control 
and congestion reporting.

What about Presence Servers, Resource List Servers, Conferencing Servers, email servers, Transcoding Bridges, Media Gateways, voicemail servers, Message Relays, Message Stores, Location Servers, servers that protect you from Spam and harasment (white lists and black lists), and Servers that support providing Consent for you to be added to a resource list? 

It would also be difficult to see how Push to Talk Group calls would work with an acceptable user experience on constrained wireless networks without a server in the network that supports media burst control. Of course you could always have one of the end user equipments perform the  media burst control - in fact the next release of OMA PoC will support such functionality however this is really intended for human moderated push to talk sessions and other "special" push to talk applications and would be too slow for the regular Push to Talk experience.

The end to end model is fine and needs to be supported as does the end to middle model. Whether servers in the network are provided by the service provider that provides connectivity or third parties is a commercial issue not a technology one.

I think taking the position that everything must be end to end is as extreme a position as the walled garden approach that everything must be end to middle.

Where end to middle makes sense use that approach and where end to end makes sense use that approach. The technology should be provided that supports either approach and ensures interoperability between a mix of these approaches and then let the market decide which approach provides the best solution for each application.

Andrew
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

----- Original Message -----
From: Dean Willis <[email-masked]>
To: Dale R. Worley <[email-masked]>
Cc: Sipping <[email-masked]>
Sent: Sat Mar 25 16:38:27 2006
Subject: Re: [Sipping] Requirements for the identificationof	IMScommunicationservices.

Dale R. Worley wrote:
> On Fri, 2006-03-24 at 12:51 -0600, Brian Stucker wrote:
> 
>>- A device has knowledge of certain (potentially, but not exclusively)
>>network based services that are available to it. How does it correctly
>>format it's request such that the set of services that it is
>>interested in having applied to the request are invoked in a generic
>>(standards-based) manner?
> 
> 
> Maybe I'm the only ignorant one here, but what is a "network based
> service"?
> 

Telco speak for "function invoked by a proxy or other service-provider 
equipment" rather than "function performed in an end-user network node."

The fact that we differentiate between "service provider equipment" and 
"end user equipment" and that this presumably says something about the 
function being perfromed speaks volumes about the design philosophy.

"network based service" is a misnomer, as we all know that the only 
network-based services are packet forwarding, routing topology 
management, and just possibly (but not usually in IP) admissions control 
and congestion reporting.

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 26 Mar 2006 09:13:33 -0600

Andrew Allen wrote:

> What about Presence Servers, Resource List Servers, Conferencing Servers,
> email servers, Transcoding Bridges, Media Gateways, voicemail servers, 
> Message Relays, Message Stores, Location Servers, servers that protect you
> from Spam and harasment (white lists and black lists), and Servers that 
> support providing Consent for you to be added to a resource list?

All the above are indeed part of network based services and represent the
telephone company view, mutated in in age of IP, after all telecom networks
and their technology had to give way to the Internet. There are numerous
problems with the above approach, such as high costs, the innability to
innovate and lack of auditable security (mostly due to the huge complexity).
In fact, none of the above are actually required for rich application
services but are pushed on the market for various revenue objectives, that
may never be fulfilled for service providers.

Besides, the agenda of controlling th user from the network, besides being
repugnant, is also doomed to failure in the free market.

By contrast, the Internet view of the world is based on the e2e principle,
because putting service in the network (such as mentioned above) stifles
innovation and removes user choice and control. Only the endpoints can best
introduce, own and manage their own applications, state, data, etc.

These two views are reflected recently in the market by:

- The IMS, TISPAN, etc. network centric architectures, and the opposite
- Peer-to-peer applications whose traffic dominate the Internet.

Skype can be considered as a pre-standard P2P communication application and
it dominates VoIP. SIP is also P2P by nature and servers are only
_opitional_ , a fact that many tend forget.

The four meetings dedicated to P2P in general and P2P SIP at the 65 IETF are
clearly an indication the Internet will recover from the network centric
approach pushed by the network based VoIP industry. See for more information
http://www.p2psip.org/ietf.php and follow the postings from the 65 IETF.

>>and congestion reporting.

Thanks, Henry

-----Original Message-----
From: Andrew Allen [mailto:[email-masked]] 
Sent: Sunday, March 26, 2006 12:51 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Requirements for theidentificationof
IMScommunicationservices.

Dean

Dean Willis wrote:

What about Presence Servers, Resource List Servers, Conferencing Servers,
email servers, Transcoding Bridges, Media Gateways, voicemail servers,
Message Relays, Message Stores, Location Servers, servers that protect you
from Spam and harasment (white lists and black lists), and Servers that
support providing Consent for you to be added to a resource list? 

It would also be difficult to see how Push to Talk Group calls would work
with an acceptable user experience on constrained wireless networks without
a server in the network that supports media burst control. Of course you
could always have one of the end user equipments perform the  media burst
control - in fact the next release of OMA PoC will support such
functionality however this is really intended for human moderated push to
talk sessions and other "special" push to talk applications and would be too
slow for the regular Push to Talk experience.

The end to end model is fine and needs to be supported as does the end to
middle model. Whether servers in the network are provided by the service
provider that provides connectivity or third parties is a commercial issue
not a technology one.

I think taking the position that everything must be end to end is as extreme
a position as the walled garden approach that everything must be end to
middle.

Where end to middle makes sense use that approach and where end to end makes
sense use that approach. The technology should be provided that supports
either approach and ensures interoperability between a mix of these
approaches and then let the market decide which approach provides the best
solution for each application.

Andrew

----- Original Message -----
From: Dean Willis <[email-masked]>
To: Dale R. Worley <[email-masked]>
Cc: Sipping <[email-masked]>
Sent: Sat Mar 25 16:38:27 2006
Subject: Re: [Sipping] Requirements for the identificationof
IMScommunicationservices.

--
Dean

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this
transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 26 Mar 2006 09:16:42 -0600

All the above are indeed part of network based services and represent the
telephone company view, mutated in the age of IP, after all telecom networks
and their technology had to give way to the Internet. There are numerous
problems with the above approach, such as high costs, the inability to
innovate and lack of auditable security (mostly due to the huge complexity).
In fact, none of the above are actually required for rich application
services but are pushed on the market for various revenue objectives, that
may never be fulfilled for service providers.

The agenda of controlling the user from the network, besides being
repugnant, is also doomed to failure in the free market.

Skype can be considered as a pre-standard P2P communication application and
it dominates VoIP. SIP is also P2P by nature and servers are only _optional_
, a fact that many tend forget.

Thanks, Henry

-----Original Message-----
From: Andrew Allen [mailto:[email-masked]] 
Sent: Sunday, March 26, 2006 12:51 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] Requirements for theidentificationof

Dean

Dean Willis wrote:

Andrew

----- Original Message -----
From: Dean Willis <[email-masked]>
To: Dale R. Worley <[email-masked]>
Cc: Sipping <[email-masked]>
Sent: Sat Mar 25 16:38:27 2006
Subject: Re: [Sipping] Requirements for the identificationof

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sun, 26 Mar 2006 16:40:01 -0600

> What about Presence Servers, Resource List Servers, Conferencing
> Servers, email servers, Transcoding Bridges, Media Gateways, voicemail
> servers, Message Relays, Message Stores, Location Servers, servers that
> protect you from Spam and harasment (white lists and black lists), and
> Servers that support providing Consent for you to be added to a resource
> list?

I see where our disconnect is. You think you're designing a network, 
when you are really just designing applications that use a network.

 From a network perspective, the things on your list are pretty much all 
"endpoint services". A mail server is attached TO a network. It is not 
"in the network".

> It would also be difficult to see how Push to Talk Group calls would
> work with an acceptable user experience on constrained wireless networks
> without a server in the network that supports media burst control. Of
> course you could always have one of the end user equipments perform the
> media burst control - in fact the next release of OMA PoC will support
> such functionality however this is really intended for human moderated
> push to talk sessions and other "special" push to talk applications and
> would be too slow for the regular Push to Talk experience.

Lots of applications used with the Internet involve more than one 
endpoint. Consider email. I send a message across the net to my outbound 
mail relay. It sends the message across the net to your inbound email 
server. The message sits there until you get around to having your mail 
client pop it off of the server, also presumably across the Internet.

Email servers use the network. They are not part of the network, and if 
one wanted to, one could use the network without them. That said, the 
email servers do provide certain value, so most people do use them, but 
that doesn't make them part of the network.

Indeed, from a "network service provider" basis, the email servers are 
completely separate from the netwwork. Consider AOL. AOL has lots of 
email servers, but they use network servicec from wholesale ISPs like 
UUNET and Level3 to connect users to those servers.

> The end to end model is fine and needs to be supported as does the
> end to middle model. Whether servers in the network are provided by the
> service provider that provides connectivity or third parties is a
> commercial issue not a technology one.

Whether servers are used by an application is an aspect of the design of 
that application. But according to the design of the Internet, servers 
are never "in the network".

When you confound the use of servers with a network that is actually 
BUILT on servers, you do a significant disservice to the reader who is 
attempting to understad what you are talking about in the context of the 
Internet. This is, after all, the "Internet Engineering Task Force", not 
the "ITU Engineering Task Force".

> I think taking the position that everything must be end to end is as
> extreme a position as the walled garden approach that everything must be
> end to middle.

No doubt. Just remember where the ends are. This prevents design 
confusion. I give for example OMA POC. Many, many times I have cleared 
up confusing discussions by saying "Pretend the user is actually at the 
POC Participating Function. It is a user agent (perhaps back to back) 
but from a network perspective, it is an ENDPOINT. There is a separate 
end-to-end relationship between the phone and the PF."

> Where end to middle makes sense use that approach and where end to
> end makes sense use that approach. The technology should be provided that
> supports either approach and ensures interoperability between a mix of
> these approaches and then let the market decide which approach provides
> the best solution for each application.

This basic topic came up in last weeks plenary (my fault, I suppose).

Someone astutely pointed out that often we need to think about "person 
to person" rather than "end to end" in our designs. This is especially 
important for cryptographic protections, where a relay node might well 
be used as a man-in-the-middle attack point. While I will agree that 
conference bridges (although MITMs) really are useful, we DO have to be 
very careful about surrendering essential security for a little 
temporary convenience. Let us not become deserving of neither.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Mar 2006 09:55:37 -0500

Dean makes good points. We have reasonable mechanisms in place when we 
consider network based endpoints as targets. Callerprefs allows the 
caller to identify the endpoint capabilities it considers most important 
for the request. There are plenty of mechanisms to name new 
capabilities, and capabilities need not be mutually exclusive. But of 
course these are all *caller* controlled.

AFAIK there has been little recent work on callee based policy (or 
callee provider based policy).

Looking way back, there is the work on CPL (RFC 3880). There is even a 
framwork for that (RFC 2824). These are sufficiently far back that I 
have no direct knowledge of their development, or of their current 
applicability. But perhaps they could be viewed as a starting point for 
this work.

	Paul

Dean Willis wrote:
>> management, and just possibly (but not usually in IP) admissions 
>> control and congestion reporting.
>>
>