Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-02.txt

From: [email-masked]
Date: Wed, 27 Oct 2004 17:53:07 +0300

Paul,

Do you assume that prescaps would always be generated based on registration information? At least I think in many cases it will be directly published by the PUA/device itself, in which case there obviously won't be a problem in associating e.g. mobility with a device. If someone is forming prescaps based on registered contacts, I suggest to simply leave mobility away, since as you say association with any device id could be impossible, and I too woudn't like to mess the service model by talking about mobile services.

Markus

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Paul Kyzivat
> Sent: 27 October, 2004 17:10
> To: Lonnfors Mikko (Nokia-NRC/Helsinki)
> Cc: Jonathan Rosenberg; [email-masked]
> Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-prescaps-ext-02.txt
> 
> 
> Mikko,
> 
> I have some concerns about how the change in the presence data model 
> impacts this. The data model has separated device from 
> service, and I am 
> agreeing with that direction. But the information covered by 
> prescaps is 
> derived from data that is bound to registrations, and in some 
> cases it 
> may be an intermediary that transforms registration data into 
> presence data.
> 
> The problem is that callee caps needn't include any association to a 
> device. When it doesn't, it isn't possible to associate items with an 
> appropriate <device> element.
> 
> Lets consider an example:
> 
> 	REGISTER sip:atlanta.com
> 	To: sip:[email-masked]
> 	From: sip:[email-masked]
> 	Contact: sip:[email-masked];
> 		audio;
> 		mobility=mobile;
> 		description="<Alice's cellphone>"
> 
> It's clear how to construct a <tuple> from this, but I can't 
> construct a 
> device id to use in constructing a <device> in which to describe 
> mobility. I also don't know whether to associate the description with 
> the tuple or the device.
> 
> It is only mobility that presents a problem this way, since it is the 
> only capability that must be placed in devcaps. I don't have a good 
> solution here, other than to permit mobility in servcaps, 
> which Jonathan 
> won't like.
> 
> I also see another issue that I should have caught before, because it 
> isn't new. And it is as much a problem for RFC3840 as it is a 
> problem here:
> 
> The issue is how priority is represented. As part of doing 3840, 
> priority was changed from a set of tokens (non-urgent, 
> normal, urgent, 
> emergency) to numeric values (10, 20, 30, 40) so that callerprefs 
> matching on ranges would be possible. The description says
> 
>      "A value of X means that the device is willing to
>       take requests with priority X and higher."
> 
> However no actual examples are given, and the above description is 
> slightly at odds with the way numeric values are to be handled with 
> feature params. To get as close as possible to the above, and use 
> numeric values so that callerprefs matching works, a value of normal 
> ought to be represented as:
> 
> 	priority="#>=20"
> 
> If instead it were simply represented as priority="20" then 
> the 20 would 
> simply be a token, and callerprefs range matching would not work.
> 
> The impact of this on prescaps is the value of priority should permit 
> one or more numeric ranges. (Negation is also permitted, but 
> that can be 
> mapped into a different set of ranges.)
> 
> I expect this issue will require a bit more discussion. :-(
> 
> 	Paul
> 
> [email-masked] wrote:
> > Hi,
> > 
> > Below is the list of changes that have been done compared 
> to last version:
> > 
> > - prescaps now defines two XML documents (instead of one). 
> One to represent device capabilities and one to represent 
> service capabilities. This is done to align work with current 
> presence data model. I didn't include anything to describe 
> the person as I don't think it makes any sense in this draft.
> > 
> > - I have tried to address all comments received during 
> WGLC. If I have missed something please let me know.
> > 
> > - Feature tag extensibility is now handled using XML 
> substitutiongroups.
> > 
> > - Added message media feature tag. 
> > 
> > - Type media tag is still in.
> > 
> > - New IANA sections for new XML document.
> > 
> > - Some editorial fixes.
> > 
> > 
> > - Mikko
> > 
> > 
> >>A New Internet-Draft is available from the on-line 
> >>Internet-Drafts directories.
> >>This draft is a work item of the SIP for Instant Messaging 
> >>and Presence Leveraging Extensions Working Group of the IETF.
> >>
> >>	Title		: User Agent Capability Extension to Presence 
> >>			  Information Data Format(PIDF)
> >>	Author(s)	: M. Lonnfors, K. Kiss
> >>	Filename	: draft-ietf-simple-prescaps-ext-02.txt
> >>	Pages		: 30
> >>	Date		: 2004-10-26
> >>	
> >>Interoperation of Instant Messaging and Presence systems has been
> >>   defined in the IMPP working group.  The IMPP WG has come up with
> >>   baseline interoperable operations and formats for presence and
> >>   instant messaging systems.  However, these base formats 
> might need
> >>   standardized extensions in order to enable building rational
> >>   applications using presence and instant messaging.  This 
> >>memo defines
> >>   an extension  to represent RFC3840 capabilities in the Presence
> >>   Information Document Format (PIDF) compliant presence documents.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-ietf-simple-prescaps
> >>-ext-02.txt
> >>
> >>To remove yourself from the I-D Announcement list, send a 
> message to 
> >>[email-masked] with the word unsubscribe in 
> >>the body of the message.  
> >>You can also visit 
> >>https://www1.ietf.org/mailman/listinfo/I-D-announce 
> >>to change your subscription settings.
> >>
> >>
> >>Internet-Drafts are also available by anonymous FTP. Login 
> >>with the username
> >>"anonymous" and a password of your e-mail address. After logging in,
> >>type "cd internet-drafts" and then
> >>	"get draft-ietf-simple-prescaps-ext-02.txt".
> >>
> >>A list of Internet-Drafts directories can be found in
> >>http://www.ietf.org/shadow.html 
> >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >>
> >>Internet-Drafts can also be obtained by e-mail.
> >>
> >>Send a message to:
> >>	[email-masked].
> >>In the body type:
> >>	"FILE /internet-drafts/draft-ietf-simple-prescaps-ext-02.txt".
> >>	
> >>NOTE:	The mail server at ietf.org can return the document in
> >>	MIME-encoded form by using the "mpack" utility.  To use this
> >>	feature, insert the command "ENCODING mime" before the "FILE"
> >>	command.  To decode the response(s), you will need "munpack" or
> >>	a MIME-compliant mail reader.  Different MIME-compliant 
> >>mail readers
> >>	exhibit different behavior, especially when dealing with
> >>	"multipart" MIME messages (i.e. documents which have been split
> >>	up into multiple messages), so check your local documentation on
> >>	how to manipulate these messages.
> >>		
> >>		
> >>Below is the data which will enable a MIME compliant mail reader
> >>implementation to automatically retrieve the ASCII version of the
> >>Internet-Draft.
> >>
> > 
> > 
> > _______________________________________________
> > Simple mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/simple
> > 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Oct 2004 11:59:50 -0400

[email-masked] wrote:
> Paul,
> 
> Do you assume that prescaps would always be generated based on registration information?

No. But I think some will do it that way.

 > At least I think in many cases it will be directly published by the 
PUA/device itself,

Yes, I agree.

 > in which case there obviously won't be a problem in associating e.g. 
mobility with a device. If someone is forming prescaps based on 
registered contacts, I suggest to simply leave mobility away, since as 
you say association with any device id could be impossible, and I too 
woudn't like to mess the service model by talking about mobile services.

I guess leaving mobility out is an option. Not great, but perhaps a 
tolerable limitation.

	Paul