1 / 8

draft-lonnfors-simple-prescaps-ext-02

draft-lonnfors-simple-prescaps-ext-02. Mikko Lönnfors mikko.lonnfors@nokia.com #IETF58. Changes since -01 version. Harmonization with draft-ietf-sip-callee-caps-01 New XML schema Separate elements for all attributes Some editorial cleanup. Open issue (<contact URI>).

nonnie
Download Presentation

draft-lonnfors-simple-prescaps-ext-02

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-lonnfors-simple-prescaps-ext-02 Mikko Lönnforsmikko.lonnfors@nokia.com #IETF58

  2. Changes since -01 version • Harmonization with draft-ietf-sip-callee-caps-01 • New XML schema • Separate elements for all attributes • Some editorial cleanup

  3. Open issue (<contact URI>) • What should be the contact URI if <prescaps> elements are present? • In “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)” it is not recommended to assign feature sets into AoR • In presence many services probably want to use AoR as contact URI • Proposal: not restrict SIP URIs that can be placed as contact URI

  4. Open issue (What capabilities) • In “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)” it is recommended that UA should declare all features associated to particular Contact address • In presence tuples can represent many things: service, device, presentity. • Also authorization policies may limit the information that is visible for watchers • Proposal: no need to express full feature sets but only those that are relevant for particular service/tuple

  5. Open issue (contacting particular UA) • In the past there has been desire to enable routing based on <prescaps> elements • Still, presence is more about user preferences • Authorization policies may restrict watchers access to all <prescaps> elements • Currently drafts says that building Accept-Contact based on <prescaps> elements can be done. • Do we need something else?

  6. Open issue (syntax) • List type of features (like methods) • At a moment draft doesn’t provide possibility for negations, separation between token/string • Solution 1: • <methods>INVITE, !MESSAGE, OPTIONS</methods> • Solution 2: <methods> <method>INVITE</method> <method negated="true">MESSAGE> </methods>

  7. Open issue (extension tags) • At a moment only possibility to add new tags is to define new XML namespace. This is probably too heavy • Proposal: • Define elements for different types of extension feature tags: boolean, integer, string, token, range. • <string name="new-string“ negated=“true”>Foobar</string> • <token name="new-token“ negated=“false”>ball</token>

  8. Next Steps • Adopt as WG item?

More Related