Subject: [Simple] Extend UA Capabiity Extension to PIDF

From: Helsen Frank <[email-masked]>
Date: Fri, 24 Sep 2004 09:44:59 +0200

Hello,

At this moment, draft-ietf-simple-prescaps-ext-01 does not provide a way to
indicate to the server which client the user uses.  I can imagine that an
operator has specific client capabilities he would like to know (e.g. java
virtual machine version, screen size).  When including this client
information, the server could retrieve the client capabilities from his e.g.
his DB.  With this extension, the operator has control over the client
information and is not dependend on the information the client provides to
him.  
Next example shows a possible extension

<ClientInfo>
	<Manufacturor> Siemens </Manufacturor>
	<Model> CX65 </Model>
	<Version>2.103564</Version>
</ClientInfo>

Regards,

Frank

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Aki Niemi <[email-masked]>
Date: Fri, 24 Sep 2004 16:40:23 +0300

Hi,

The primary consumer of presence documents is a presence watcher. And it
seems this information wouldn't be all that useful to most if not all
watchers.

What is the actual scenario where the server would need this
information? Because in many cases, the User-Agent header field in SIP
is supposed to carry this sort of information already.

Cheers,
Aki

On Fri, 2004-09-24 at 10:44, ext Helsen Frank wrote:
> Hello,
> 
> 
> At this moment, draft-ietf-simple-prescaps-ext-01 does not provide a
> way to indicate to the server which client the user uses.  I can
> imagine that an operator has specific client capabilities he would
> like to know (e.g. java virtual machine version, screen size).  When
> including this client information, the server could retrieve the
> client capabilities from his e.g. his DB.  With this extension, the
> operator has control over the client information and is not dependend
> on the information the client provides to him.  
> 
> ______________________________________________________________________

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Sep 2004 10:27:30 -0400

Helsen,

I don't understand your terminology very well, or what you are trying to 
achieve.

By 'client' I guess you mean a device addressed by a contact in a tuple 
of the presence document, rather than a subscriber to presence. Is that 
right?

I don't know precisely what role you have in mind for 'operator'. Is it 
the operator of the presence server itself? Or is it something that is a 
client of the PS. What is it doing that requires it to know this 
information?

In general the device will probably be publishing its own presence 
status to the presence server. If so the extension you suggest would 
simply cause it to push this invariant information over and over.

This kind of info can already be polled using OPTIONS. Why isn't that 
enough?

	Paul

Helsen Frank wrote:
> Hello,
> 
> 
> At this moment, draft-ietf-simple-prescaps-ext-01 does not provide a way 
> to indicate to the server which client the user uses.  I can imagine 
> that an operator has specific client capabilities he would like to know 
> (e.g. java virtual machine version, screen size).  When including this 
> client information, the server could retrieve the client capabilities 
> from his e.g. his DB.  With this extension, the operator has control 
> over the client information and is not dependend on the information the 
> client provides to him. 
> 
> ------------------------------------------------------------------------
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Sep 2004 11:47:58 -0400

My guess is that Helsen is looking at something equivalent to the UAProf 
functions in WAP, which allow a client to push fairly complicated 
information about itself, such as screen size and JVM. I don't think 
this is "presence" in the sense that much of this information is 
probably not useful to watchers. However, it does represent valid device 
information and could conceivably appear there.

We do have a specification, RFC 3840, which allows a client to declare 
its capabilities to the server. That specification does not dictate how 
this information is used. One usage is caller preferences, RFC 3841, 
which allows for capability-based called routing. However, I think 
Helsen has in mind a usage where the provider/domain owner simply wants 
to look at this profile data for some reason, and that is certainly 
possible.

We have only a very limited set of capabilities declare right now, a 
much, much, much smaller subset of what is in UAProf.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Mike Hammer <[email-masked]>
Date: Fri, 24 Sep 2004 12:13:08 -0400

All,

It might not be in the best interest of the user to broadcast too much 
detail about the configuration of the device as this might just let 
miscreants know what sort of tools to use to attack the device.  May save 
some reconaissance/scanning time on the attacker's part.

Mike

At 11:47 AM 9/24/2004 -0400, Jonathan Rosenberg wrote:
>information about itself, such as screen size and JVM. I don't think this 
>is "presence" in the sense that much of this information is probably not 
>useful to watchers. However, it does represent valid device information 
>and could conceivably appear there.
>
>We do have a specification, RFC 3840, which allows a client to declare its 
>capabilities to the server. That specification does not dictate how this 
>information is used. One usage is caller preferences, RFC 3841, which 
>allows for capability-based called routing. However, I think Helsen has in 
>mind a usage where the provider/domain owner simply wants to look at this 
>profile data for some reason, and that is certainly possible.
>
>We have only a very limited set of capabilities declare right now, a much, 
>much, much smaller subset of what is in UAProf.
>
>-Jonathan R.
>
>
>
>Paul Kyzivat wrote:
>
>>Helsen,
>>of the presence document, rather than a subscriber to presence. Is that right?
>>client of the PS. What is it doing that requires it to know this information?
>>In general the device will probably be publishing its own presence status 
>>to the presence server. If so the extension you suggest would simply 
>>cause it to push this invariant information over and over.
>>This kind of info can already be polled using OPTIONS. Why isn't that enough?
>>     Paul
>>Helsen Frank wrote:
>>
>>>Hello,
>>>
>>>