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

From: "Eric Tremblay" <[email-masked]>
Date: Wed, 23 Jul 2008 15:21:27 -0400

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
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: <[email-masked]>
Date: Wed, 23 Jul 2008 20:59:24 -0500

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:[email-masked]] 
>Sent: Wednesday, July 23, 2008 12:21 PM
>To: Lonnfors Mikko (Nokia-D-MSW/Helsinki); Kiss Krisztian 
>(Nokia-OCTO/MtView); [email-masked]
>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:
>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">
>
>conference.winfo but not conference? Maybe an additional 
>attribute could do the trick...
>
>Best Regards,
>
>EricT
>

---

From: "Eric Tremblay" <[email-masked]>
Date: Thu, 24 Jul 2008 10:00:57 -0400

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