Subject: RE: [Simple] Update to xcap authorization rules

From: [email-masked]
Date: Fri, 21 May 2004 09:28:42 +0300

Just to be clear, I was referring to the <note> elements at the presentity level, not tuple level. There can be a multiplicity of those. <provide-note> would provide all those <note> elements at the presentity level. The ones at the tuple level need different handling.

/Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 20.May.2004 13:26
> To: Niemi Aki (Nokia-M/Espoo)
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Isomaki Markus
> (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [Simple] Update to xcap authorization rules
> 
> 
> 
> 
> Aki Niemi wrote:
> 
> > 
> > 
> > ext [email-masked] wrote:
> > 
> >>>> Another thing that currently there seems to be no way of
> >>>> controlling child elements of <presence>, e.g. <note>, which is
> >>>> not within any tuple. This is allowed by PIDF, so maybe there
> >>>> should be a "provide-..." element explicitely for it.
> >>>
> >>>
> >>> I think the only thing is actually note, since basic status has to
> >>> be included I think. I can add a provide-note.
> >>
> >>
> >>
> >> Note: There can appear more than one <note> element. Would
> >> <provide-note> provide all notes?
> > 
> > 
> > I at least think it should, since I think the only reason 
> for having 
> > multiple notes would be to give each one their own 
> 'xml:lang' attribute 
> > value.
> 
> Yes, I also agree. Please take a look at the email I just sent on 
> presence rules issue 4, where I think these "provide-X" things should 
> not support complicated selection rules which allow you to 
> say for which 
> tuples you were talking about.
> 
> I think what we'll find is that, if I really want to control 
> information 
> differently in different tuples, this manifests itself by me simply 
> providing you with some tuples and not others, in which case 
> you'll get 
> the <note> that was in the tuples you get.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 May 2004 18:48:21 -0400

[email-masked] wrote:

> Just to be clear, I was referring to the <note> elements at the
> presentity level, not tuple level. There can be a multiplicity of
> those. <provide-note> would provide all those <note> elements at the
> presentity level. The ones at the tuple level need different
> handling.

Do we really need this? Seems like, in most cases, if you provide a user 
with a tuple, they'd also get the note in that tuple. As such, having a 
provide-tuple would get the job done.

Do you have a specific use case for explicitly allowing specific 
per-tuple notes, which is not better accomplished by providing the whole 
tuple or not?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 May 2004 18:48:21 -0400

-Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Mon, 24 May 2004 17:02:05 +0300

I think what Hisham is saying is that for tuples alone <provide-note> or 
even <provide-tuple> works fine.

But for <note> elements directly under <presence>, you lose the feature 
which allows you to provide different notes to different user groups. 
However, this seems like a more general problem, where the authorization 
model we have currently (authorize componenets instead of individual 
attributes) no longer works properly if the attributes aren't grouped 
under a tuple, but are under <presence> directly.

Cheers,
Aki

---

From: Aki Niemi <[email-masked]>
Date: Mon, 24 May 2004 17:02:05 +0300

Cheers,
Aki