Subject: [Simple] draft-ietf-simple-prescaps-ext-03 <notsupported>

From: "Beck01, Wolfgang" <[email-masked]>
Date: Mon, 21 Mar 2005 10:37:19 +0100

Section 3.2.14

"   <supported> and <notsupported> elements can contain <presence>,
   <message-summary>, <reg>, <refer>, <winfo>, <spirits-user-prof>,
   <spirits-user-prof>, <spirits-INDPs>, and <Siemens-RTP-Stats>
   followed by any number of optional extension elements from other
   namespaces."

<notsupported> would have to include all event packages not invented yet
and therefore require infite buffer space in senders and receivers.

Seriously, I can't see any value in having <notsupported> and propose
to remove it.

Wolfgang

--
Wolfgang Beck
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Mon, 21 Mar 2005 12:02:38 +0200

Hi,

<notsupported> doesn't need to include all event packages that are not
supported. You would include <notsupported> if you want that UA
receiving that information can make some kind of decisions based on that
i.e. it is used to explicitly say that some event packages are not
supported. There is no need to list all of the event packages that are
not supported using <notsupported>. 
Same functionality exits in RFC3840 but in slightly different form.
RFC3840 allows you to indicate negated values all feature tags using '!'
and this functionality is present in prescaps using <notsupported>.
I believe in most cases you can just leave not supported event packages
out.
It is probably true that use of <notsupported> is not that likely as use
of <supported> but there are still use cases for that.

- Mikko

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Beck01, Wolfgang
>Sent: Monday, March 21, 2005 11:37
>To: [email-masked]
>Subject: [Simple] draft-ietf-simple-prescaps-ext-03 <notsupported>
>
>Section 3.2.14
>
><notsupported> would have to include all event packages not 
>invented yet and therefore require infite buffer space in 
>senders and receivers.
>
>Seriously, I can't see any value in having <notsupported> and 
>propose to remove it.
>
>Wolfgang
>
>
>--
>Wolfgang Beck
>T-Systems

---

From: [email-masked]
Date: Mon, 21 Mar 2005 12:40:08 +0200

Hi,

Inline: 

>From: ext Beck01, Wolfgang [mailto:[email-masked]] 
>Sent: Monday, March 21, 2005 12:28
>To: Lonnfors Mikko (Nokia-NRC/Helsinki); [email-masked]
>Subject: AW: [Simple] draft-ietf-simple-prescaps-ext-03 <notsupported>
>
>> I believe in most cases you can just leave not supported event 
>> packages out. It is probably true that use of <notsupported> is not 
>> that likely as use of <supported> but there are still use cases for 
>> that.
>
>Could you give an example? If User Agent A wants to check if B 
>supports event package xy, it can just look into <supported>.
>If it's not there, B does not support xy.

If its not there then A just don't know if B supports is or not. In this
case B doesn't want A to make any decision based on xy.

>If B's <notsupported> contains xy, the information is 
>redundant as xy is not in <supported>.

In this case B is explicitly saying that xy is not supported and A can
make a decision based on this.

>If B's neither <notsupported> nor <supported> do contain xy, B 
>is unlikely to support xy. Again, <notsupported> is redundant.

Well, this now depends how B wants to publish it capabilities. It may be
supported or it may not but you cannot say that it is unlikely.

>I was just checking the changes between -01 and -03 and found 
>that <notsupported> was introduced after -01 (btw a 'Changes 
>from draft-..-<version>' section would be nice).

Right, <notsupported> was introduced after -01 but the same
functionality has been there all the time.

- Mikko