Subject: Re: [Sipping] Initial review ofdraft-ietf-sipping-service-identification-00.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 24 Feb 2008 23:40:46 -0500

Mahesh,

I am just now, some FOUR MONTHS later, getting to update this document. 
So, I thank you for your review and patience in waiting for an update. 
Enclosed are some responses to your comments:

Mahesh wrote:
> hello Gonzalo,
> I've been waiting for quite sometime for review of this draft.:-)
> 
> I would like to volunteer to do a intial review of this draft.
> I do not know of the formal procedure to declare myself as volunteer .
> So i shall just go ahead and post my initial review comment below.
> (if there is anything specific to be done to inform the Chairs pls let me
> know)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~``
> 
> Starting with, let me discuss w.r.t the following definition from the draft
> "Service  identification is the process of determining and/or signaling the
>   specific use case that is driving the signaling being generated by a
>   user agent."
> 
> Here, if the signaling is really able to signal the Use-Case that is 
> driving
> the Signaling then it would be Application Identification rather than just
> just Communication Service Identification because the Use-Case
> (defining theUser Experience) is modelled by the Application and not the
> Communication Service.

The draft purposefully stays away from a debate on what is an 
application vs. a service vs. a feature. This is a never-ending 
terminology discussion. So, it uses ONLY the term service, and that term 
refers to the user experience that a user gets for a session.

> But the draft title is "Identification of Communication Services".
> Signaling/determining  a Communication Service does not neccessarily
> amount to determining/signalling the Use Case which is driving the
> signalling.
> 
> Basically, it is unclear as to what is meant by "Service Identification" in
> this draft.

I think the definition as offered:

Service
identification is the process of determining and/or signaling the
specific use case that is driving the signaling being generated by a
user agent.

is fine when you put aside this notion of applications vs. services.

> 
> So i tried to seek answer in Section 3 which tries to define "Service". 
> Here,
> extract from RFC 4479(Presence Data Model) is referred to define a Service.
> " Each presentity has access to a number of services.  Each of these
> represents a point of reachability for communications that can be   used to
> interact with the user."

Careful; RFC 4479 defines service thusly:

Service:  A communications service, such as instant messaging (IM) or
       telephony, is a system for interaction between users that provides
       certain modalities or content.

which is entirely consistent with what is in this draft. THe text you 
quote about is saying that services *represent* a point of reachability; 
not that they ARE a point of reachability.

> 
> There are two ways of interpreting this
>    i1)"Point of reachability for Communications " can be WhiteBoard,
>        Chess Game,Chatt Application  which are all different instances of
>        Interaction with the User.
>    i2)"Point of reachability for Communications" can be Messaging
>        Service, CS Telephony, PS Telephony which can be used by
>        Applications such as Game,Instant Messenger,WhiteBoard etc to enable
>        interaction with the User.
> 
> It is more meaningful  if it were (i1), so that the Presentity Info conveys
> exactly the kind of Use-Case/Interaction that a User can engage in with
> another User.Which Communication Service would be used to achive the
> Interaction/Use-Case may be irrelevant to the User.

Again you are referring to the split which IMS has made between service 
and application. This split is entirely an artifact of the IMS 
architecture and not consequential here. I think the definition of 
service as offered is fine.

> 
> Also, later on in Section 3 of the draft i find the following:
> "Essentially, the service is the user-visible use case that is driving
>   the behavior of the user-agents and servers in the SIP network."
> 
> I'm still not able to understand "Service" and hence "Service 
> Identification"
> from this draft because if "Service" is looked as as a user-visible
> use case then there is ambiguity  in this draft as follows
>    - The Title of  the draft is "Identification of Communication Service",
>    - however the term "Service" is being used to refer to the User Visible
>      Usecase by statement ==> "Service Identification is the process of
>      determining and/or signaling the  specific use-case".
>    - User Visible Use Case cannot be synonymous to Communication Service,
>       in other words a Communication service may not be able to completely
>       indicate/describe the User experience. For Example: by inidcating
>       a Messaging Communication Service i cannot know if User is wants
>       Gaming or Chatting.

Exactly the point the draft is trying to make. The service is a 
consequence of the entirety of what the signaling provides, not just one 
part (i.e., the fact that there is an MSRP stream).

Thanks for your comments,
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
_______________________________________________
Sipping mailing list  http://www.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