Subject: Re: [Sipping] Suggested direction for discussions onserviceidentification

From: "Andrew Allen" <[email-masked]>
Date: Fri, 16 Mar 2007 03:58:55 -0400

Henry

Sorry for my delayed reply because I was at a meeting all this week.

In my view there will be standardised services that are commonly known and need to be registered and also vendor proprietary services that do not need registering.

Only if the service is of a nature that an endpoint needs to understand the service in order to accept the session is it absolutely necessary to have registration and Jonathans draft does this through the Require header and the SIP extension mechanism.

The other part of the draft that addresses this issue is the use of the Service URN. URNs have a well defined (but not too onerous) registration mechanism for reserving namespaces. Some of the namespaces or at least the top level hierarchy namespaces will be public but it is also possible to have vendor owned namespaces where a vendor can control the allocation of the subnamespaces. It seems to me IANA has coped with URN allocations for all kinds of organizations to date.

Whether this URN hierarchy is an extension of the existing service URN as specified in ECRIT or a new URN is not material. What I think is needed to aid interoperability with this is a hierachial structure for services identifiers that will allow for a best match comparison between the specified service identifier and the known services supported or charged for. The IETF should in my view control this top level hierarchy and the vendors (both manufacturers and service providers) and other organizations can register their own subnamespaces beneath the top level hierarchy for proprietary services that are subsets of a top level service. In order to place a subnamespace in a branch of the parent hierarchy the service identified must have basic interoperability with a service that shares the same parent node in the hierarchy.

So if service identifiers were to be used for discount coupons and promotional bundling of services the service provider would be able to allocate a new service identifier from their vendor owned subnamespace in the appropriate branch of the service identifer namespace in order to service that particular service set without registering anything additional with IANA unless these services by their nature created a basic interoperability issue between SIP endpoints.

A possible structure for a URN for services hierarchy could look like:

Top level 1: Qos class

This inidcates to network elements and endpoints what kind of QoS characteristics (fixed delay, jitter etc) the session traffic requires.

Values: Background, Interactive, Streaming, Conversational.

Level 2: Common basic services

Values: voice, messaging, games, audio, video, data

Level 3: advanced services

Values; Telephony, PTT, TV, IM, SMS, MMS, Email, file-share, information, notification, download

Level 4: specific sub services

This is where most vendor specific flavors come in. For telephony this level may identify a particular feature set bundle (call features including voicemail) and/or media combinations (basic or multimedia)

Now the idea here is to construct branches of the tree that represent the minimum level of service for inteoperability. So the service identifier for a multimedia telephony service could be

Conversational.voice.telephony.acmeCo.multimedia.serv-bundle2

Note that even though this is multimedia that also supports video basic minimum interoperability is achieved with voice only hence the level 2 token is voice. Hence if an application only understands a conversation voice telephony service it can provide the appropriate support for interoperability between a user having a multimedia telephony service.

acmeCo.multimedia.serv-bundle2 could include voice mail with email notifications.

The corresponding email notification could have a service identifier that looks like:

Background.messaging.email.acmeCo.multimedia.serv-bundle2 

TV could look like

Streaming.video.TV.acmeCable.premium

Here video is essential to provide basic service a voice or audio stream is simply not sufficent to provide the service.

The BNF would correspond to the BNF used for URNs.

The above examples are just illustrative the entire parent hierarchy would need suitable analysis and what identifiers are needed at what level in the hierarchy all needs to be worked out but I think it helps to understand the concept of how this could work and create a scalable mechanism.

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: Henry Sinnreich <[email-masked]>
To: Andrew Allen; Gonzalo Camarillo <[email-masked]>; sipping <[email-masked]>
Cc: Mary Barnes <[email-masked]>
Sent: Mon Mar 12 12:08:47 2007
Subject: RE: [Sipping] Suggested direction for discussions onserviceidentification

Andrew Allen wrote:

> Whilst I welcome focusing the discussion on technical issues rather 
> than the philosophical arguments

Well, one technical issue I am struggling with is service identification
is not scalable, since there are so many competing service models and
marketing cannot be forbidden to invent new ones all the time. It's
actually their job to do so and the engine of marketing. 

Do you expect IANA to have a huge and growing registry for service
definitions? 

How about holiday promotions and coupons for frequent fliers when the
service bundles are rearranged and the service logic may interact? 
I am not kidding.

Example: Additional (maybe free) voice mail notification over e-mail
with media attachment will be added if you subscribe to IM. How does one
specify voice mail (free?) over email, with media attachment,
conditioned by _new_ IM subscription? Specific coupons are allowed. How
would the BNF spec look like?

If the BNF for this 1,001th service is not registered with IANA, 
will voice mail fail?

Please don't focus on the possible weakness of my example, but address
the generic issue of scalability. 

Thanks, Henry

-----Original Message-----
From: Andrew Allen [mailto:[email-masked]] 
Sent: Monday, March 12, 2007 2:13 AM
To: Gonzalo Camarillo; sipping
Cc: Andrew Allen; Mary Barnes
Subject: RE: [Sipping] Suggested direction for discussions
onserviceidentification
Importance: High

Gonzalo,

Whilst I welcome focusing the discussion on technical issues rather than
the philosophical arguments that will simply use up the meeting time I
am concerned that your proposal seems very much to focus on the use of
Accept-Contact for various aspects rather than the actual proposals in
draft-rosenberg-sipping-service-identification-00. 

Although I know that several companies within 3GPP have proposed the use
of Accept-Contact as the protocol element for transporting service
identifiers this is not part of Jonathan's proposal in the draft
currently and as far as I am aware not part of any draft submitted to
SIPPING. While I have no problem with us discussing alternative
mechanisms including the use of Accept-Contact as part of the discussion
I think that the focus of the discussion should be foremost around the
proposals in the current draft.

In your current proposal for discussion only the proposed use of Require
is actually from the current draft. 

Specifically we need to also discuss:

1) how Application Servers that perform service logic in the home domain
of the UAC can be inserted in the route. The draft's current proposal is
to use a preloaded Route header containing the Service Identifier in a
URN format for that.

2) how UAs can obtain the service identifiers needed to communicate
properly with other UAs in other domains that need service identifiers
in order to have the appropriate service logic, policies and routing
applied. The draft proposes the use of Service URIs and Service Instance
URIs and the use of Presence and GRUU based mechanisms to generate and
communicate these URIs containing the service identifiers.

3) How Application Servers that perform service logic in the terminating
domain can be routed to based on Service Identifiers. The draft bases
terminating domain routing upon domain routing policies for the Service
URI that is inserted in the Request-URI.

4) the format of service identifiers. The draft proposes basing service
identifiers on URNs based upon the existing Service URN.

5) Dependencies on other drafts (such as GRUU and Loose Route).

I believe that discussion on these 4 items needs to also be part of the
agenda for the SIPPING discussion on this

regards
Andrew

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Sunday, March 11, 2007 8:18 AM
To: sipping
Cc: Mary Barnes
Subject: [Sipping] Suggested direction for discussions on
serviceidentification

Folks,

as a chair, I would like to direct our discussions on service
identification to a few topics. Below, I have tried and summarized some
of the issues that have been discussed on the mailing list, and
suggested concrete topics for discussion.

Note that I am sending this email as a chair. That is, it does not
contain my personal opinion on any of the topics below. The intention
with this email is to focus discussions on a few topics that, once
clarified, may help us make some progress as a WG.

1) Non-backwards compatible services (e.g., PoC). Unless user agents
understand the special logic that relates to the service, they will not
be able to do the right thing. It has been proposed to use the Require
header field to identify these services. It has also been proposed to
use feature tags in Accept-Contact header fields together with the
"require" and "explicit" parameters. When these parameters are used a
proxy will only forward the request to contacts that have explicitly
indicated that they support the desired feature set.

It seems that the end result is similar and that no matter in which
header field the token identifying the service is placed, the
requirements would be met.

However, there is an important difference between both mechanisms: the
IANA registration policy for new tokens. Require header fields can only
carry option-tags, which need to be defined in standards-track RFCs.
Feature tags, on the other hand, can be vendor-specific and are
registered in the IANA registry as such.

Therefore, I would like to see explicit discussions on the IANA
registration policy we want for these non-backwards-compatible services.

Questions we may want to ask ourselves are: do we want require a
standards-track RFC for this type of non-backwards-compatible service?
If so, should the PoC specs be copy/pasted into an RFC or a one-page RFC
pointing to the OMA spec would be enough?

2) Enhanced experience. Some services are backwards compatible. That is,
even if the other endpoint does not understand the service, a session
can be established. However, if the other end understands the service,
users get, somehow, an enhanced experience.

An example of this type of service could be a multimedia telephony
service, which might include things such as mandatory support for
certain supplementary services.

It has been proposed to use feature tags and caller preferences for this
type of service. I would like to see discussions on whether or not this
way of using caller preferences is appropriate.

3) SIP-established sessions as a transport for proprietary information.
Some applications use SIP to establish generic media streams in order to
exchange application-specific information on top of them. For example, a
network game may use SIP to establish a TCP stream between two endpoints
and then send the position of its players (or whatever information the
game needs to transfer) over that TCP stream. Another game may establish
a similar TCP stream, but transfer different information in a different
format over it. The same example would be valid if both applications
used MSRP streams instead of TCP streams.

I would like to see discussions on how we want to identify those two
applications (i.e., both games in the example above). Do we want to use
the same mechanism as in 1)?

4) Network support and interactions with caller preferences. It has been
discussed that services in the three categories above sometimes require
network support. Therefore, an entity in the network may need to be able
to identify the service a given SIP request relates to. Note that
network support may be required in the originating and terminating
networks, and that different mechanisms may be used to implement network
support in an originating network or in a terminating network.

I would like to see discussions on possible interactions between
services that require network support and caller preferences. What
happens if a UA sends an INVITE that uses caller preferences to indicate
that the user would prefer to use multimedia telephony but that would be
OK using PoC should multimedia telephony not be available. Are both, the
multimedia telephony and the PoC application servers, included in the
signalling path, just in case?

Cheers,

Gonzalo
SIPPING co-chair

_______________________________________________
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

---------------------------------------------------------------------
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: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 16 Mar 2007 11:27:47 +0100

Andrew,

There is no need to standardize any of this:

1. If the UA would insert such a Service-ID, there are 2 cases:
a) UA fully controlled by and linked with operator network, in this case the 
operator can provision any string it feels like and sync it with the user 
interface / experience
b) UA independent of network, in which case the scheme below won't work 
because different networks will use different ids for the same service 
depending on which vendor they use and/or what their marketing department 
comes up with; how is the UA supposed to know what id to use?

2. If "the network" would insert such a Service-ID, it can already do this 
today (e.g. based on analyzing the request, which would of course have to be 
"sufficiently different" for different services)

Standardization on a fixed set of service identifiers severely limits the 
possibilities for innovation: suppose an operator offers a video service, 
and wants to extend that with a push-to-talk audio experience. Then they 
would first have to go back and standardize the "video+push-to-talk" service 
identifier. Then new handsets are issued which support transfer of such 
calls to an in-home multimedia center, resulting in a need for the 
identifier "video+push-to-talk+transfer-to-home". Then they want to 
introduce a discount for frequent fliers, 
"video+push-to-talk+transfer-to-home+for-frequent-fliers" Etc, etc. It can 
easily be seen that this leads nowhere.

Regards,
Jeroen

Andrew Allen wrote:
> In my view there will be standardised services that are commonly
> known and need to be registered and also vendor proprietary services
> that do not need registering.
>
> Only if the service is of a nature that an endpoint needs to
> understand the service in order to accept the session is it
> absolutely necessary to have registration and Jonathans draft does
> this through the Require header and the SIP extension mechanism.
>
> The other part of the draft that addresses this issue is the use of
> the Service URN. URNs have a well defined (but not too onerous)
> registration mechanism for reserving namespaces. Some of the
> namespaces or at least the top level hierarchy namespaces will be
> public but it is also possible to have vendor owned namespaces where
> a vendor can control the allocation of the subnamespaces. It seems to
> me IANA has coped with URN allocations for all kinds of organizations
> to date.
>
> Whether this URN hierarchy is an extension of the existing service
> URN as specified in ECRIT or a new URN is not material. What I think
> is needed to aid interoperability with this is a hierachial structure
> for services identifiers that will allow for a best match comparison
> between the specified service identifier and the known services
> supported or charged for. The IETF should in my view control this top
> level hierarchy and the vendors (both manufacturers and service
> providers) and other organizations can register their own
> subnamespaces beneath the top level hierarchy for proprietary
> services that are subsets of a top level service. In order to place a
> subnamespace in a branch of the parent hierarchy the service
> identified must have basic interoperability with a service that
> shares the same parent node in the hierarchy.
>
> So if service identifiers were to be used for discount coupons and
> promotional bundling of services the service provider would be able
> to allocate a new service identifier from their vendor owned
> subnamespace in the appropriate branch of the service identifer
> namespace in order to service that particular service set without
> registering anything additional with IANA unless these services by
> their nature created a basic interoperability issue between SIP
> endpoints.
>
> This inidcates to network elements and endpoints what kind of QoS
> characteristics (fixed delay, jitter etc) the session traffic
> requires.
>
> This is where most vendor specific flavors come in. For telephony
> this level may identify a particular feature set bundle (call
> features including voicemail) and/or media combinations (basic or
> multimedia)
>
> Now the idea here is to construct branches of the tree that represent
> the minimum level of service for inteoperability. So the service
> identifier for a multimedia telephony service could be
>
> Note that even though this is multimedia that also supports video
> basic minimum interoperability is achieved with voice only hence the
> level 2 token is voice. Hence if an application only understands a
> conversation voice telephony service it can provide the appropriate
> support for interoperability between a user having a multimedia
> telephony service.
>
> Here video is essential to provide basic service a voice or audio
> stream is simply not sufficent to provide the service.
>
> The above examples are just illustrative the entire parent hierarchy
> would need suitable analysis and what identifiers are needed at what
> level in the hierarchy all needs to be worked out but I think it
> helps to understand the concept of how this could work and create a
> scalable mechanism.
>
> Andrew
> than
> 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: Eric Burger <[email-masked]>
Date: Fri, 16 Mar 2007 07:03:31 -0400

Unless, of course, the goal is either to virtually guarantee a single vendor
solution at the service provider, or limiting communication within a single
service provider.

Of all the markets I am familiar with, this suggestion *can* work in places
like the U.S., where there are only two telecommunications operators, each
with roughly equivalent market share (at&t and Verizon).  Better yet, the
proposal serves as an effective barrier to entry for broadband operators,
small wireless operators, and VoIP service providers, who to date have only
1-3% of the market.

>> helps to understand the concept of how this could work and create a

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

---

From: "Darshan Bildikar" <[email-masked]>
Date: Fri, 16 Mar 2007 19:13:53 +0530

Some of things that draft-stucker-sipping-early-media-coping-03 tries to
do:-

1) Classify "kinds" of early media. 
2) Defines an "emflow" SDP parameter and option tag that allows a UA to
control the direction of early media. 

Problem:

This draft mentions explicitly that deprecation of early media is out of the
scope of the document. 

It then proceeds to classify different "kinds" of early media. This, in my
opinion, exacerbates the problem. 

I feel that a solution should move away from early media all together, while
still being backwards compatible with it. 

My solution is fairly simple. 

1) Don't classify different "types" of early media. In fact, don't even
classify media as early or "late?" Classify WHO/WHAT generated the media. 

2) Create a header that will indicate WHO generated the media. Whether it
was an intermediary or whether it was the final destination that the call
was directed to. This header is generic and has NOTHING to do with billing
but CAN be interpreted by entities that use signalling for billing to do so
i.e. don't start billing until you received a UPDATE/REINVITE with the
header indicating that the actual destination answered. 

3) Use only INVITE, ACK, UPDATE and 2XX requests for offer/answer

4) Define an option tag that indicates support for this mechanism. As more
and more entities start supporting it, we slowly move away from early media.

5) Make it backward compatible with existing mechanisms.

If folks think that this would be a viable solution, I would be willing to
quickly write up a draft on it. Apologies if this has already been
considered and discarded before.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Mar 2007 10:05:17 -0400

Hi Andrew. I have a number of comments/questions about your discussion 
below.

	Paul

> Values: Background, Interactive, Streaming, Conversational.

Making this the top level forces this to the the primary level of 
concern for all. That may not be the case. I'm not sure what the 
difference is between Conversational and Interactive, but I am imagining 
that regular voice might be typically considered conversational, while 
IM and PoC might be considered Interactive. If so, I might not require 
one or the other - I might be happy to accept either. Its not clear to 
me whether that fits with what you are proposing.

> Values; Telephony, PTT, TV, IM, SMS, MMS, Email, file-share, information, notification, download

By this point we start to see the usual problems in constructing 
taxonomies. There are many views on how to do it.

What are the distinctions between voice, audio, and telephony above?

What are the distinctions between messaging, data, IM, SMS, MMS, and Email?

Can the same level 3 service appear below multiple level 1 and 2 
services? If so, do they mean the same thing? (When viewed as URNs, each 
level N service forms a unique namespace for level N+1 services. So the 
meaning of a particular named level 3 service would be distinct for each 
level 2 service it is used with.) With the classifications you have 
given above I suspect people will want this to work more like 
independent aspects.

> Note that even though this is multimedia that also supports video basic minimum interoperability is achieved with voice only hence the level 2 token is voice. Hence if an application only understan…

I still don't know what multimedia is. Is it just voice&video? Or does 
it include IM?

The above implies that voice support is needed to use this service, with 
other media support being optional. Now how does that work for somebody 
that wants to call with some of the other features but not voice? For 
instance, someone with video only, or IM only.

It seems that with this scheme, to support those things, my device will 
have to support a whole assortment of service URNs - including 
permutations of the device capabilities with different ones being at the 
highest level. This is because the hierarchical nature doesn't fit the 
non-hierarchical organization of capabilities.

Another issue is that the above says that Conversational QoS is needed 
for all media being used. But that probably isn't true. For instance a 
lesser QoS will be needed for IM than voice, and maybe even less for 
file transfer.

> acmeCo.multimedia.serv-bundle2 could include voice mail with email notifications.

I have difficulty understanding how email notifications fits into this. 
The caller and callee don't have to agree that voicemail will have email 
notifications. That is strictly a side agreement between the user and 
his voicemail provider.

> Background.messaging.email.acmeCo.multimedia.serv-bundle2 

The email will presumably just be an email. Why would service 
identifiers (which are for sip) have anything to do with email? Do I 
need a special email client that understands service identifiers???

> Here video is essential to provide basic service a voice or audio stream is simply not sufficent to provide the service.

Is video *really* essential? Blind people do *listen* to TV. They don't 
need the video - the audio stream is enough. Does there have to be a 
separate service to get that? Or does the blind person have to pay for 
delivery of a video stream that will be ignored?

> The above examples are just illustrative the entire parent hierarchy would need suitable analysis and what identifiers are needed at what level in the hierarchy all needs to be worked out but I thi…

Yes. The examples bring home how hard it will be, and a lot of question 
to whether a hierarchy is appropriate. I think the story might be 
different if the examples were done over using multiple service URNs for 
different aspects that are desired.

	Paul

---

From: Eric Burger <[email-masked]>
Date: Mon, 19 Mar 2007 09:36:52 +0100

Hierarchy simply does not work here, as there is no quantitative method to
create the tree.  Everything is really flat, so you still end up with a
bunch of incompatible, almost alike, indicators for "features" which will
perfectly re-create the feature interaction problem that we *solved* with
SIP.

On 3/16/07 10:05 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> In my view there will be standardised services that are commonly known and
>> need to be registered and also vendor proprietary services that do not need
>> registering.
>> 
>> Only if the service is of a nature that an endpoint needs to understand the
>> service in order to accept the session is it absolutely necessary to have
>> registration and Jonathans draft does this through the Require header and the
>> SIP extension mechanism.
>> 
>> The other part of the draft that addresses this issue is the use of the
>> Service URN. URNs have a well defined (but not too onerous) registration
>> mechanism for reserving namespaces. Some of the namespaces or at least the
>> top level hierarchy namespaces will be public but it is also possible to have
>> vendor owned namespaces where a vendor can control the allocation of the
>> subnamespaces. It seems to me IANA has coped with URN allocations for all
>> kinds of organizations to date.
> 
>> Whether this URN hierarchy is an extension of the existing service URN as
>> speciFrom [email-masked] Mon Mar 19 04:38:23 2007
Date: Mon, 19 Mar 2007 09:36:52 +0100
Subject: Re: [Sipping] Suggested direction for discussions
	onserviceidentification
From: Eric Burger <[email-masked]>
To: Paul Kyzivat <[email-masked]>, Andrew Allen <[email-masked]>
Cc: [email-masked]

Hierarchy simply does not work here, as there is no quantitative method to
create the tree.  Everything is really flat, so you still end up with a
bunch of incompatible, almost alike, indicators for "features" which will
perfectly re-create the feature interaction problem that we *solved* with
SIP.

On 3/16/07 10:05 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> In my view there will be standardised services that are commonly known and
>> need to be registered and also vendor proprietary services that do not need
>> registering.
>> 
>> Only if the service is of a nature that an endpoint needs to understand the
>> service in order to accept the session is it absolutely necessary to have
>> registration and Jonathans draft does this through the Require header and the
>> SIP extension mechanism.
>> 
>> The other part of the draft that addresses this issue is the use of the
>> Service URN. URNs have a well defined (but not too onerous) registration
>> mechanism for reserving namespaces. Some of the namespaces or at least the
>> top level hierarchy namespaces will be public but it is also possible to have
>> vendor owned namespaces where a vendor can control the allocation of the
>> subnamespaces. It seems to me IANA has coped with URN allocations for all
>> kinds of organizations to date.
> 
>> Whether this URN hierarchy is an extension of the existing service URN as
>> speciFrom [email-masked] Mon Mar 19 04:38:23 2007
Date: Mon, 19 Mar 2007 09:36:52 +0100
Subject: Re: [Sipping] Suggested direction for discussions
	onserviceidentification
From: Eric Burger <[email-masked]>
To: Paul Kyzivat <[email-masked]>, Andrew Allen <[email-masked]>
Cc: [email-masked]

Hierarchy simply does not work here, as there is no quantitative method to
create the tree.  Everything is really flat, so you still end up with a
bunch of incompatible, almost alike, indicators for "features" which will
perfectly re-create the feature interaction problem that we *solved* with
SIP.

On 3/16/07 10:05 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> In my view there will be standardised services that are commonly known and
>> need to be registered and also vendor proprietary services that do not need
>> registering.
>> 
>> Only if the service is of a nature that an endpoint needs to understand the
>> service in order to accept the session is it absolutely necessary to have
>> registration and Jonathans draft does this through the Require header and the
>> SIP extension mechanism.
>> 
>> The other part of the draft that addresses this issue is the use of the
>> Service URN. URNs have a well defined (but not too onerous) registration
>> mechanism for reserving namespaces. Some of the namespaces or at least the
>> top level hierarchy namespaces will be public but it is also possible to have
>> vendor owned namespaces where a vendor can control the allocation of the
>> subnamespaces. It seems to me IANA has coped with URN allocations for all
>> kinds of organizations to date.
> 
>> Whether this URN hierarchy is an extension of the existing service URN as
>> specified in ECRIT or a new URN is not material. What I think is needed to
>> aid interoperability with this is a hierachial structure for services
>> identifiers that will allow for a best match comparison between the specified
>> service identifier and the known services supported or charged for. The IETF
>> should in my view control this top level hierarchy and the vendors (both
>> manufacturers and service providers) and other organizations can register
>> their own subnamespaces beneath the top level hierarchy for proprietary
>> subnamespace in a branch of the parent hierarchy the service identified must
>> have basic interoperability with a service that shares the same parent node
>> in the hierarchy.
>> 
>> promotional bundling of services the service provider would be able to
>> allocate a new service identifier from their vendor owned subnamespace in the
>> appropriate branch of the service identifer namespace in order to service
>> that particular service set without registering anything additional with IANA
>> unless these services by their nature created a basic interoperability issue
>> between SIP endpoints.
>> 
>> characteristics (fixed delay, jitter etc) the session traffic requires.
>> 
>> This is where most vendor specific flavors come in. For telephony this level
>> may identify a particular feature set bundle (call features including
>> voicemail) and/or media combinations (basic or multimedia)
>> 
>> Now the idea here is to construct branches of the tree that represent the
>> minimum level of service for inteoperability. So the service identifier for a
>> multimedia telephony service could be
>> 
>> Note that even though this is multimedia that also supports video basic
>> minimum interoperability is achieved with voice only hence the level 2 token
>> is voice. Hence if an application only understands a conversation voice
>> telephony service it can provide the appropriate support for interoperability
>> between a user having a multimedia telephony service.
> 
> The above implies that voice support is needed tfied in ECRIT or a new URN is not material. What I think is needed to
>> aid interoperability with this is a hierachial structure for services
>> identifiers that will allow for a best match comparison between the specified
>> service identifier and the known services supported or charged for. The IETF
>> should in my view control this top level hierarchy and the vendors (both
>> manufacturers and service providers) and other organizations can register
>> their own subnamespaces beneath the top level hierarchy for proprietary
>> subnamespace in a branch of the parent hierarchy the service identified must
>> have basic interoperability with a service that shares the same parent node
>> in the hierarchy.
>> 
>> promotional bundling of services the service provider would be able to
>> allocate a new service identifier from their vendor owned subnamespace in the
>> appropriate branch of the service identifer namespace in order to service
>> that particular service set without registering anything additional with IANA
>> unless these services by their nature created a basic interoperability issue
>> between SIP endpoints.
>> 
>> characteristics (fixed delay, jitter etc) the session traffic requires.
>> 
>> This is where most vendor specific flavors come in. For telephony this level
>> may identify a particular feature set bundle (call features including
>> voicemail) and/or media combinations (basic or multimedia)
>> 
>> Now the idea here is to construct branches of the tree that represent the
>> minimum level of service for inteoperability. So the service identifier for a
>> multimedia telephony service could be
>> 
>> Note that even though this is multimedia that also supports video basic
>> minimum interoperability is achieved with voice only hence the level 2 token
>> is voice. Hence if an application only understands a conversation voice
>> telephony service it can provide the appropriate support for interoperability
>> between a user having a multimedia telephony service.
> 
> The above implies that voice support is needed tfied in ECRIT or a new URN is not material. What I think is needed to
>> aid interoperability with this is a hierachial structure for services
>> identifiers that will allow for a best match comparison between the specified
>> service identifier and the known services supported or charged for. The IETF
>> should in my view control this top level hierarchy and the vendors (both
>> manufacturers and service providers) and other organizations can register
>> their own subnamespaces beneath the top level hierarchy for proprietary
>> subnamespace in a branch of the parent hierarchy the service identified must
>> have basic interoperability with a service that shares the same parent node
>> in the hierarchy.
>> 
>> promotional bundling of services the service provider would be able to
>> allocate a new service identifier from their vendor owned subnamespace in the
>> appropriate branch of the service identifer namespace in order to service
>> that particular service set without registering anything additional with IANA
>> unless these services by their nature created a basic interoperability issue
>> between SIP endpoints.
>> 
>> characteristics (fixed delay, jitter etc) the session traffic requires.
>> 
>> This is where most vendor specific flavors come in. For telephony this level
>> may identify a particular feature set bundle (call features including
>> voicemail) and/or media combinations (basic or multimedia)
>> 
>> Now the idea here is to construct branches of the tree that represent the
>> minimum level of service for inteoperability. So the service identifier for a
>> multimedia telephony service could be
>> 
>> Note that even though this is multimedia that also supports video basic
>> minimum interoperability is achieved with voice only hence the level 2 token
>> is voice. Hence if an application only understands a conversation voice
>> telephony service it can provide the appropriate support for interoperability
>> between a user having a multimedia telephony service.
> 
>> Here video is essential to provide basic service a voice or audio stream is
>> simply not sufficent to provide the service.
> 
>> The above examples are just illustrative the entire parent hierarchy would
>> need suitable analysis and what identifiers are needed at what level in the
>> hierarchy all needs to be worked out but I think it helps to understand the
>> concept of how this could work and create a scalable mechanism.
> 
>> conditioned o use this service, with
>> Here video is essential to provide basic service a voice or audio stream is
>> simply not sufficent to provide the service.
> 
>> The above examples are just illustrative the entire parent hierarchy would
>> need suitable analysis and what identifiers are needed at what level in the
>> hierarchy all needs to be worked out but I think it helps to understand the
>> concept of how this could work and create a scalable mechanism.
> 
>> conditioned o use this service, with
>> Here video is essential to provide basic service a voice or audio stream is
>> simply not sufficent to provide the service.
> 
>> The above examples are just illustrative the entire parent hierarchy would
>> need suitable analysis and what identifiers are needed at what level in the
>> hierarchy all needs to be worked out but I think it helps to understand the
>> concept of how this could work and create a scalable mechanism.
> 
>> header field to identify these servby _new_ IM subscription? Specific coupons are allowed. How
>> header field to identify these servby _new_ IM subscription? Specific coupons are allowed. How
>>ices. It has also been proposed to
>>ices. It has also been proposed to
>> 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.
>>