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

["Eric Tremblay" <eric.m.tremblay at gmail.com>]

Hi Krisztian,

Good point, I did not read the bug report like this, but this makes
more sense to me now. So this should apply to Allow-Event and the
sip.events UA caps. I see that there are some implementations that do
place presence.winfo (or even presence.winfo.winfo) into their
Allow-Event and I would assume they would do the same in sip.events.
However, when mapping this to PIDF UA Caps, they would have to include
the <winfo> element if any of their supported events include winfo,
without specifying for which event it is supported. It is then up to
the recipient of this information to find out if winfo is supported
for a specific event using the standard SIP mechanism.

Thanks for the clarification. I agree it was quite late to change the
spec, but we at least have some justifications logged into the mailing
list now :)

Best Regards,

EricT


On Wed, Jul 23, 2008 at 9:59 PM,  <krisztian.kiss at nokia.com> wrote:
> 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