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

From: Mahfuz Rahman <[email-masked]>
Date: Sun, 07 Nov 2004 21:34:39 -0500

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Nov 2004 09:45:23 -0500

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.

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.

-- 
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: "Mahfuzur Rahman" <[email-masked]>
Date: Thu, 11 Nov 2004 12:49:26 -0500

The goal of this draft is not to provide solution for "network"  management.
This draft is addressing a very important use case where a user would like
to retrieve some information about a device particularly its status before
communicating with it. Status here refers to availability, location,
operating mode etc which has some similarity with presence as defined in
SIMPLE. The problem of this draft can be easily solved using an event
package.

The issue of "network" management (performance, fault management,
accounting, performance) is a different problem and out of the scope of this
draft. Hope this clarifies the issue.

- mahfuz

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>
To: "Mahfuz Rahman" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, November 11, 2004 9:45 AM
Subject: Re: [Sipping] device-info-01

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Nov 2004 15:28:46 -0500

As came out in the meeting discussion today, there are many questions 
about this particular use. But if this is your intent, and if anything 
is to come of it, then I think you need to be careful of terminology. 
(My earlier comments highlighted possible ambiguity in the terminology.)

Based on discussion and the text below, you don't seem to be talking 
about "device" info so much as proprietary UA info.

	Paul

Mahfuzur Rahman wrote:
>>>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:
> 
>>>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
>>>
>>>As a completely alternative suggestions.... How much of this information
>>
> can
> 
>>>I would remove all the discussion of the device status - you don't
>>
> define
> 
>>>This reports things that should not change so rate of notifications is
>>
> very
> 
>>>very seldom.
>>>
>>>I would make the schema URL and name attributes of a schema object so
>>
> that
>

---

From: "Mahfuzur Rahman" <[email-masked]>
Date: Thu, 11 Nov 2004 15:42:42 -0500

We do not be mind to change or take suggestion on terminology to avoid any
possible confusion as long as the concept is clear.

-mahfuz

----- Original Message ----- 
From: "Paul Kyzivat" <[email-masked]>
To: "Mahfuzur Rahman" <[email-masked]>
Cc: "Jonathan Rosenberg" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, November 11, 2004 3:28 PM
Subject: Re: [Sipping] device-info-01