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

From: [email-masked]
Date: Wed, 27 Oct 2004 09:16:03 +0300

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Oct 2004 10:10:17 -0400

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