Subject: RE: [Simple] Extend UA Capabiity Extension to PIDF

From: Helsen Frank <[email-masked]>
Date: Mon, 27 Sep 2004 13:44:03 +0200

This is indeed what I had in mind.  Thanks for the clarification.  And I
agree that this is not presence information. The approach in RFC3840 where
the device capabilities are transported in the REGISTER seems the correct
solution.  Better then having it in a NOTIFY.  However, RFC3840 does not
create the option to specify the device.  One would not have to think about
what device information a provider/PS/Application would like to have.  Just
specify which device it is and it is up to him to get the required
information (using device profiles).

Regards,

Frank

Frank Helsen - MPM/IMC System Engineer
Mail: [email-masked]
Tel:+32 14 252573
Mobile: +32 494 692959
Siemens HRT IC MN D D1

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: vrijdag 24 september 2004 17:48
To: Paul Kyzivat
Cc: Helsen Frank; [email-masked]'
Subject: Re: [Simple] Extend UA Capabiity Extension to PIDF

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.

Paul Kyzivat wrote:

> 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.
>> 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
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
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

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

---

From: Goix Walter <[email-masked]>
Date: Tue, 28 Sep 2004 16:25:16 +0200

> 
> Which I guess leaves you with option (2). There doesn't seem 
> to be much in the way of putting information there that goes 
> beyond the name and version of the binary. In web browsers 
> this information many times contains OS, and even CPU information.
> 
> Having said that though, if the intention originally was to 
> have CC/PP in SIP, then it would've been best to say so to 
> begin with...

I agree that option (2) is not the right way to go. 
Going UAProf, which may be useful for many services, implies to put
CC/PP in SIP as you said (maybe an URL into an header in some cases, or
the same URL as a XML tag in presence information), and also to extend
CC/PP with SIP-related info

> 
> > IMHO, I think having this info provided directly by the UA itself 
> > could be helpful and simplier for Application Servers or proxies to 
> > process a request based on such info.
> 
> I agree, but whether you need something beyond callee-caps 
> and User-Agent is then another question. 
> 
> Also, I think some information actually does belong in 
> presence. For example, it might be worthwhile expressing 
> maximum attachment size in a mailto tuple. Depends what you 
> would like to do, and who the primary consumer of this 
> information would be (e2e vs. e2m).

I do believe as well there is a need to put these kind of caps into
presence info. CC/PP is not the only option for this but could be a
rich, standard way to provision such info from the UA to the server, for
example through an URL into a PUBLISH header, which could also be reused
in other methods.
Once they get this info, presence servers can decide whether and how to
send this info (or part of it) to watchers, by sending an HTTL URL of
the profile into PIDF doc (this woul require watchers to have an HTTP
stack) or extracting info and putting it into some PIDF extension (like
you said "max attachment size" for example, or supported content-types
based on the SIP method or type of session, etc. that are not supported
by callee-caps). In this case, why not reuse CC/PP schema and if not
enough simply extend it? CC/PP already has a lot of info that may be
useful for watchers.

walter 

> Cheers,
> Aki

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================