Re: [Simple] draft-ietf-simple-prescaps-ext-10 comment

[<krisztian.kiss at nokia.com>]

Hi Eric,

I see your point. However, I read the bug report which says:

"Adam Roach: Truth is, once you implement a template, the implementation
technically can support applying it to anything (unless you're a really
bad
programmer).
Adam Roach: The only thing that might prevent it from working is a
decision --
either by the programmer or by the administrator -- that certain
combinations
are dangerous or silly.
Adam Roach: Ergo, it's a policy decision."

...so the question comes to my mind: is presence the right tool to
advertize what kind of policy restrictions are implemented at the UA
when applying a template package? Or, should we just leave this policy
exchange to the actual subscription transaction, i.e. let the UA
advertize support for <winfo> template package and if a UA policy
disallows certain combinations with other event packages or recursive
template support, that will be discovered during subscription time
(rejecting unallowed events with 489/403 as described in the bug
report). 
As explained in section 1.2 and 4, "This extension is only aimed for
presentities to give watchers hints about the presentity's preferences,
willingness and capabilities to communicate before watchers initiate a
communication with the presentity.", so it is not meant to replace
capability negotiation procedures with SIP. What is your view on this
option?

Cheers,
Krisztian

P.S. there's another major problem to change the draft at this point of
time: it is currently in RFC editor's queue waiting for a final
confirmation from the ADs and then the RFC is out...

>-----Original Message-----
>From: ext Eric Tremblay [mailto:eric.m.tremblay at gmail.com] 
>Sent: Wednesday, July 23, 2008 12:21 PM
>To: Lonnfors Mikko (Nokia-D-MSW/Helsinki); Kiss Krisztian 
>(Nokia-OCTO/MtView); simple at ietf.org
>Subject: draft-ietf-simple-prescaps-ext-10 comment
>
>Hi Mikko & Krisztian,
>
>In section 3.2.14:
>I wonder if representing winfo support in the <event-packages> 
>element as a single <winfo> element makes sense. Just putting 
><winfo> under a <supported> element does not mean that an 
>application supports watcher-info for all events enumerated there.
>
>I think that winfo should somehow apply to an other event. 
>Without an existing grammar to represent recursive template 
>support (or limitations of such support), I would suggest 
>representing a single level of support and then applications 
>could assume that if presence.winfo is supported, then 
>presence.winfo.winfo should also be supported. A bug already 
>exists to track this issue:
>http://bugs.sipit.net/show_bug.cgi?id=711
>
>I suggest two options:
>
>1) Allowing an optional <winfo> element under the other event 
>types (<conference>, <dialog>, <kpml>, <message-summary>, 
><poc-settings>, <presence>, <reg>, <refer>, 
><Siemens-RTP-Stats>, <spirits-INDPs>,
><spirits-user-prof>) to indicate that winfo is supported for 
>that specific event type.
>
>2) Allowing an optional "template" attribute to the event 
>types which could contain a comma separated list of templates 
>supported for this event type. <conference template="winfo,foo">
>
>How do we then represent the fact that a device only supports 
>conference.winfo but not conference? Maybe an additional 
>attribute could do the trick...
>
>Best Regards,
>
>EricT
>
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple