Subject: [Simple] Presence rules and polite-block

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 3 May 2006 19:47:01 -0500

Reading through the simple-presence-rules draft [1], I note that the "polite-block" value for the <sub-handling> element seems a little out of place.  I understand that this may be in line with existing implementations, but I think that, semantically, the "polite-block" is a better logical fit for the <transformations> section.

The difference between the "polite-block" and "allow" values are only in the way that the final document is constructed.  They both affect the state machine in the same way - in the description you use "polite-block" or "allow" in the same way.

Recommendation by pseudo-example:

<rule id="ero628hi8j1s">
  <conditions></conditions>
  <actions><pr:sub-handling>block|confirm|allow</pr:sub-handling></actions>
  <transformations><pr:polite-block/></transformations>
</rule>

The <polite-block> element would have to override all other transformations.  Since the effective difference between "polite-block" and "allow" is seen later in the processing stage, this will probably clean code.

An unrelated suggestion: In section 4, I had to read it twice to get the implication that F(D) was a noop.  Perhaps you could clarify this by using something more explicit: Dn = F(Do), Dn = F(F(Do)), Dn = F(Dn) {where Dn = notification document, Do = original document}

Nit: Page 11, first line: s/four/three/

Regards,
Martin 

[1] http://tools.ietf.org/html/draft-ietf-simple-presence-rules-05.txt

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 15 May 2006 20:54:20 -0400

Thomson, Martin wrote:

> Reading through the simple-presence-rules draft [1], I note that the
> "polite-block" value for the <sub-handling> element seems a little
> out of place.  I understand that this may be in line with existing
> implementations, but I think that, semantically, the "polite-block"
> is a better logical fit for the <transformations> section.

We have discussed this, in fact.

The complication is that 'polite-block' isn't the same as any of the 
other transformations at all. The problem is that the model in 
presence-rules is that you have some 'raw' presence document with all of 
the data in it. The transformations that get applied to the document all 
  determine which information in the document can be revealed to 
watchers. Polite block isn't removing information at all. Instead, its 
suggesting that the presence server make up some kind of fake presence 
document and then send that to the watcher. We found it difficult to 
represent this as a transformation in the same way the others are 
represented.

As a consequence of this different, the other transformations defined in 
presence-rules don't make sense in conjunction with polite-block. This 
dependence required us to move polite-block to an action.

> 
> The difference between the "polite-block" and "allow" values are only
> in the way that the final document is constructed.  They both affect
> the state machine in the same way - in the description you use
> "polite-block" or "allow" in the same way.

They affect the watcher state machine in the same way, but not the other 
aspects of presence server behavior.

> <rule id="ero628hi8j1s"> <conditions></conditions> 
>  <transformations><pr:polite-block/></transformations> </rule>
> 
> The <polite-blocth esmtp (Exim 4.43) id 1FfseJ-00013E-Q4
	for [email-masked]; Tue, 16 May 2006 02:03:19 -0400
Date: Mon, 15 May 2006 20:54:20 -0400
From: Jonathan Rosenberg <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: [email-masked]
Subject: [Simple] Re: Presence rules and polite-block

Thomson, Martin wrote:

> Reading through the simple-presence-rules draft [1], I note that the
> "polite-block" value for the <sub-handling> element seems a little
> out of place.  I understand that this may be in line with existing
> implementations, but I think that, semantically, the "polite-block"
> is a better logical fit for the <transformations> section.

We have discussed this, in fact.

The complication is that 'polite-block' isn't the same as any of the 
other transformations at all. The problem is that the model in 
presence-rules is that you have some 'raw' presence document with all of 
the data in it. The transformations that get applied to the document all 
  determine which information in the document can be revealed to 
watchers. Polite block isn't removing information at all. Instead, its 
suggesting that the presence server make up some kind of fake presence 
document and then send that to the watcher. We found it difficult to 
represent this as a transformation in the same way the others are 
represented.

As a consequence of this different, the other transformations defined in 
presence-rules don't make sense in conjunction with polite-block. This 
dependence required us to move polite-block to an action.

> 
> The difference between the "polite-block" and "allow" values are only
> in the way that the final document is constructed.  They both affect
> the state machine in the same way - in the description you use
> "polite-block" or "allow" in the same way.

They affect the watcher state machine in the same way, but not the other 
aspects of presence server behavior.

> <rule id="ero628hi8j1s"> <conditions></conditions> 
>  <transformations><pr:polite-block/></transformations> </rule>
> 
> The <polite-block> element would have to override all other
> transformations.  Since the effective difference between
> "polite-block" and "allow" is seen later in the processing stage,
> this will probably clean code.

The fact that it 'overrides' everything else is a sure sign that this 
doesn't work. A criteria for something being its own permission (as 
discussed in common-policy) is that it is orthogonal to other things.

> 
> 
> An unrelated suggestion: In section 4, I had to read it twice to get
> the implication that F(D) was a noop.  Perhaps you could clarify this
> by using something more explicit: Dn = F(Do), Dn = F(F(Do)), Dn =
> F(Dn) {where Dn = notification document, Do = original document}

I'm not sure further mathematical notation would clarify this. Instead I 
just added some text that states explicitly that its a no-op:

  In other words, further applications of the privacy filtering
operation would not result in any further changes of the document,
making further application of the filtering operation a no-op.

> Nit: Page 11, first line: s/four/three/

fixed.

Thanks for your comments,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

k> element would have to override all other
> transformations.  Since the effective difference between
> "polite-block" and "allow" is seen later in the processing stage,
> this will probably clean code.

The fact that it 'overrides' everything else is a sure sign that this 
doesn't work. A criteria for something being its own permission (as 
discussed in common-policy) is that it is orthogonal to other things.

> 
> 
> An unrelated suggestion: In section 4, I had to read it twice to get
> the implication that F(D) was a noop.  Perhaps you could clarify this
> by using something more explicit: Dn = F(Do), Dn = F(F(Do)), Dn =
> F(Dn) {where Dn = notification document, Do = original document}

I'm not sure further mathematical notation would clarify this. Instead I 
just added some text that states explicitly that its a no-op:

  In other words, further applications of the privacy filtering
operation would not result in any further changes of the document,
making further application of the filtering operation a no-op.

> Nit: Page 11, first line: s/four/three/

fixed.

Thanks for your comments,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com