Subject: Re: [Sipping] device-info-01

From: Mahfuz Rahman <[email-masked]>
Date: Thu, 11 Nov 2004 19:59:52 -0500

Paul:

We discussed the idea of assinging new presence attributes a 
year ago which we beleive would solve interoperability issue.
But we were advised not to do that on the basis that device 
status and presence are two different things and we should not
mix it up.

I am glad that you brought up this  issue of presence
attributes for device which I totally agree with and would be
happy to pursue our previous idea on presence and submit an 
alternate draft based on presence.

I hope the working group will support it then.

-mahfuz

----- Original Message -----
From: Paul Kyzivat <[email-masked]>
Date: Thursday, November 11, 2004 7:12 pm
Subject: Re: [Sipping] device-info-01

> Brijesh,
> 
> The more I hear the more I dislike. It sounds like you are trying 
> to 
> reinvent presence, but in a very device specific way. The 
> functionality 
> you describe can, I believe, be achieved in a much more 
> interoperable 
> way by defining new presence attributes which the device may 
> publish, 
> and which may be disclosed to you if policy of the owner of the 
> device 
> desires you to know it.
> 
> 	Paul
> 
> Brijesh Kumar wrote:
> > ----- Original Message -----
> > From: Jonathan Rosenberg <[email-masked]>
> > Date: Thursday, November 11, 2004 9:45 am
> > Subject: Re: [Sipping] device-info-01
> > 
> > 
> >>I think there is an interesting question at the root of this 
> >>draft. The 
> >>interesting question is how to manage a "network" where the 
> >>network 
> >>includes all of the SIP user agents (and in particular, single 
> >>user 
> >>devices like softphones and hardphones). Management, in this 
> >>context, 
> >>includes configuration (where things like the config profile are 
> >>targeted), but also includes fault management, accounting, 
> >>performance 
> >>and security management. This draft is targeted roughly in the 
> >>area of 
> >>device performance management, and thats a laudable goal.
> > 
> > 
> > Hi Jonathan:
> > 
> > As I clarified during our presentation, the purpose of this draft
> > is to monitor the useful states of a device that are 
> > relevant for a variety of applications. 
> >   
> > For example, I may be interested in knowing the current status
> > of a camera attached to a user's phone before I start streaming
> > video to him. Or, I may be interested in monitoring if the user's
> > device has enough memory left for me to stream a live video, and
> > then continue monitoring. Also, to know if the speaker is muted 
> > or not, or the camera is on or of.  I may even want to know if 
> the 
> > my friend is inside his home in a comfortable environment rather 
> than 
> > in open in 100 degree heat before streaming a live video to him. 
> 
> > 
> > And, another example is what Dean mentioned - knowing the status of
> > of a video recorder, and then using that status information go 
> to 
> > a different recorder to record a video stream.
> > 
> > There are many use cases that will benefit with the abilities 
> > to learn the device and various type of status information on 
> the 
> > device.  I have only given examples related to applications that
> > are in the common knowledge - I know there are a lot many use
> > cases of similar nature. 
> > 
> > Cheers,
> > 
> > --brijesh 
> >  
> > 
> > 
> > 
> > 
> >>However, I think the problem is fairly broad, and would benefit 
> >>from a 
> >>top-down look at what really needs to be done here, rather than 
> >>jumping 
> >>to an event package or OPTIONS or whatever. The problem is 
> >>complicated 
> >>because in many cases, these devices are run and managed by end 
> users.>>
> >>-Jonathan R.
> >>
> >>Mahfuz Rahman wrote:
> >>
> >>
> >>>Thanks Cullen for making some good comments. My response is as 
> >>
> >>follows:  
> >>
> >>>OPTIONS method is used to query device capabilities such as 
> >>
> >>supported methods,
> >>
> >>>contnet types, codesc etc.. This draft defines data elements 
> for 
> >>
> >>device profile
> >>
> >>>which is  different from the tags defined for OPTIONS. So if we 
> >>
> >>like to define
> >>
> >>>tags for each of the data elements we have defined in the 
> >>
> >>profile it will be a long
> >>
> >>>list. I am not sure if it is acceptable. Also, as you suggested 
> >>
> >>to include multiple
> >>
> >>>schemas and URLs for a device it would be difficult to 
> represent 
> >>
> >>using OPTIONS unless
> >>
> >>>we allow attachment of a body in the OPTIONS response with the 
> >>
> >>following content type: 
> >>
> >>>application/device-profile+xml. 
> >>>
> >>>I agree with you to add software version and also an optional UUID.
> >>>
> >>>The status part will be extended in the future revision which 
> >>
> >>might include a 
> >>
> >>>common XML format. Currently it describes only how vendor 
> >>
> >>specific status information
> >>
> >>>can be retrieved. 
> >>>
> >>>- mahfuz
> >>>
> >>>-----Original Message-----
> >>>From: [email-masked] [[email-masked]]On
> >>>Behalf Of Cullen Jennings
> >>>Sent: Saturday, November 06, 2004 6:19 PM
> >>>To: sipping
> >>>Subject: [Sipping] device-info-01
> >>>
> >>>
> >>>Nice draft - few comments ...
> >>>
> >>>As a completely alternative suggestions.... How much of this 
> >>
> >>information can
> >>
> >>>you get by just sending an OPTION request to the device.
> >>>
> >>>I would remove all the discussion of the device status - you 
> >>
> >>don't define
> >>
> >>>anything about how to do it so the discussion does not help.
> >>>
> >>>This reports things that should not change so rate of 
> >>
> >>notifications is very
> >>
> >>>very seldom.
> >>>
> >>>I would add an optional UUID to the profile
> >>>
> >>>You might want to add software version.
> >>>
> >>>I would make the schema URL and name attributes of a schema 
> >>
> >>object so that
> >>
> >>>the device can lists multiple schema that it can support.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>_______________________________________________
> >>>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
> >>>
> >>
> >>-- 
> >>Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> >>Director, Service Provider VoIP Architecture   Parsippany, NJ 
> >>07054-2711
> >>Cisco Systems
> >>[email-masked]                              FAX:   (973) 952-5050
> >>http://www.jdrosen.net                         PHONE: (973) 952-5000
> >>http://www.cisco.com
> >>
> >>_______________________________________________
> >>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
> >>
> > 
> > 
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 
> 
> 

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Nov 2004 21:10:07 -0500

> I hope the working group will support it then.

I think that will depend entirely on the details.

I suspect that availability for streaming video might be considered a 
reasonable presence status (if it can be demonstrated to be orthogonal 
to normal video), while "has N gb of free storage" might not be.

I have a sense that you have a concept that the sender will be making 
the decisions about what should be done to the receiver, while the 
popular presence viewpoint is that the presentity makes those decisions 
and announces availability at a higher level of abstraction.

It would perhaps be helpful if you would be more explicit about the use 
cases you are trying to enable.

	Paul

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 12 Nov 2004 12:09:29 -0500

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
> cases you are trying to enable.

We are adding a section that will describe use cases in more details in the
next revision. A number of use cases are lready being discussed in OMA,
and Dean who goes to OMA is aware those use cases.

regards,

--brijesh

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 12 Nov 2004 12:10:20 -0500

----- Original Message ----- 

We are adding a section that will describe use cases in more details in the
next revision. A number of use cases are lready being discussed in Open
Mobile Alliance (OMA), and Dean who goes to OMA is aware those use 
cases. Some of these cases may be discussed in our revision.

regards,

--brijesh

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 12 Nov 2004 12:10:26 -0500

----- Original Message ----- 

regards,

--brijesh

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 12 Nov 2004 12:10:34 -0500

----- Original Message ----- 

regards,

--brijesh

---

From: "Brijesh Kumar" <[email-masked]>
Date: Fri, 12 Nov 2004 12:10:43 -0500

----- Original Message ----- 

regards,

--brijesh

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Nov 2004 02:12:13 -0500

inline.

Brijesh Kumar wrote:

> ----- Original Message ----- From: "Paul Kyzivat" <[email-masked]>
> 
>> popular presence viewpoint is that the presentity makes those 
>> decisions and announces availability at a higher level of abstraction.
>>
>> It would perhaps be helpful if you would be more explicit about the 
>> use cases you are trying to enable.
> 
> 

"Some" and "may"??

The purpose of the sipping working group is to discuss problems and 
applications of sip. If you cannot discuss the problems and use cases 
that motivate a piece of work, I don't see how it can reasonably be 
discussed or developed.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Brijesh Kumar" <[email-masked]>
Date: Tue, 16 Nov 2004 11:15:19 -0500

> From: Jonathan Rosenberg [mailto:[email-masked]]
 
> > next revision. Some of these cases may be discussed in our revision.
> 
> "Some" and "may"??
> 
 
Jonathan:

We have a large number of use cases - most of these involve a 
mobile device  getting the current operational state of a peer device 
and then using that information to make a decision as to when, where, 
which and how to transfer media streams to other sip enabled mobile 
multi-media devices. And, also there are other call center related
use cases. We can't include every thing in a draft.

Cheers,

--brijesh