Subject: AW: [Geopriv] common policy document

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 6 Jul 2005 21:06:20 +0200

hi henning, 

this is a good question. i hope aki can help us here. 
we need a rock-solid justification here since otherwise i will not change the schema (and the corresponding text) of the two documents. 

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: Henning Schulzrinne [mailto:[email-masked]] 
> Gesendet: Mittwoch, 6. Juli 2005 16:51
> An: Tschofenig, Hannes
> Cc: GEOPRIV
> Betreff: Re: [Geopriv] common policy document
> 
> 
> It seems that the attribute approach is necessary if you want 
> to replace 
> an element. As far as I know, we are only replacing whole 
> rules and it 
> seems unlikely that we'd be selecting on anything but 
> identity. However, 
>   if you have lists like
> 
> <identity>
>          <id>[email-masked]</id>
>          <id>[email-masked]</id>
>        </identity>
> 
> I don't see how attributes help here. Can you usefully select 
> on alice 
> or bob even if this is rewritten as
> 
> <id user="[email-masked]" />
> <id user="[email-masked]" />
> 
> ?
> 
> 
> Tschofenig, Hannes wrote:
> > hi all, 
> > 
> > we are currently updating the common policy document. 
> > 
> > one issue that is still not fully clear to me is how to 
> deal with the
> > issue raised by aki. aki (and jonathan) mentioned that xcap 
> works best
> > if the xml schema is designed in way that the xml elements 
> in the xml
> > documents have the following shape: 
> > 
> > (a) <id val="[email-masked]"/>
> > 
> > previously, our xml schema was written in a different way 
> such that the
> > xml documents looked like:
> > 
> > (b) <id>[email-masked]</id>
> > 
> > here are the open issues: 
> > 
> > 1) for which elements should we use approach (a) and for which other
> > elements should we use approach (b) 
> > btw, we have already noted in discussions that we will not 
> use approach
> > (a) everywhere.
> > 2) we need a few lines of text to justify why we use 
> approach (a) for
> > certain elements and again a different approach for other 
> elements (b) 
> > it would be good to mention why xcap needs this. i haven't 
> raised this
> > issue and i do not fully understand why xcap needs this i 
> would like to
> > ask someone to provide a few lines. 
> > 
> > based on the decision for (1) we need to update the xml schema / xml
> > documents (=examples) accordingly.
> > 
> > the most recent common-policy draft version can be found at : 
> > http://www.tschofenig.priv.at/TEMP/common-policy/
> > it still contains the old xml schema and examples that 
> follow appoach
> > (b). the identity section was updated based on the 
> discussions we had on
> > the mailing list and at the interim meeting. 
> > an xml schema that heavily uses approach (a) can be found 
> in the same
> > directory (along with some examples). 
> > 
> > ciao
> > hannes
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> 

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

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 07 Jul 2005 09:38:26 +0300

> > <id user="[email-masked]" />
XCAP doesn't allow text node content predicates (sorry, XPath jargon).
So adding/replacing or deleting based on this element content is not
possible. Why would that matter ? The use case is that you could add
almost blindly (unconditionally == no ETags) e.g. 
PUT ..identity/id[@user="[email-masked]"] <id
user="[email-masked]" /> so that nothing weird/unpredictable things
would happen. If this uri is as it is you could add by using positional
constraints i.e.  
PUT ..identity/id[3] <id user="[email-masked]" />
As you might guess this is unsafe if you don't use conditional requests
(If-None-Match: *). In addition, you must know the current content on
the other end, i.e. you must have at least a partial local copy of the
document (the count of <id>s). Having said that, it might be reasonable
to change this <id> uri to an attribute. The second possible change is
with <except> but I'll assume that is the only other case. 

I'll have another question about common-pol-05. I don't understand
<domain>s in <any-identity>. It seems to me that they break the
consistent model of "anything", why can't you get similar thing with
<domain>s in <identity> ?

br,
Jari

---

From: Aki Niemi <[email-masked]>
Date: Thu, 07 Jul 2005 19:54:45 +0300

Hi,

Like Jari explained, XCAP only allows node selection based on element 
name, attribute or position. It does not allow selection based on 
element content.

If you have a ruleset composed of a small number of rules, perhaps only 
two or three, you're bound to have identity conditions that have perhaps 
an excess of 100 <id> elements in them. In most buddy list based systems 
for presence, the actions and transformations for those 2-3 rules might 
stay fairly static, but the identities matched in those rules might 
change more often. Doing conditional updates to such a long list may be 
suboptimal.

To be able to remove or add an <id> element to the <identity> condition 
in one pass (blindly, meaning no HTTP request precondition), you'd have 
to be able to select a single buddy, even without knowing the exact 
position of the buddy in the list. Hence the attribute-based design.

Other than that, there is no difference. I bet XML-purists may prefer 
one design over the other, but I long ago forgot which one was better 
and why. To me they look the samem so it's a trivial change IMO.

Cheers,
Aki

ext Tschofenig, Hannes wrote:
> hi henning,
> 
> this is a good question. i hope aki can help us here. we need a
> rock-solid justification here since otherwise i will not change the
> schema (and the corresponding text) of the two documents.
> 
> ciao hannes
> 
> 
> 
>> -----Ursprüngliche Nachricht----- Von: Henning Schulzrinne
>> [mailto:[email-masked]] Gesendet: Mittwoch, 6. Juli 2005 16:51
>>  An: Tschofenig, Hannes Cc: GEOPRIV Betreff: Re: [Geopriv] common
>> policy document
>> 
>> 
>> It seems that the attribute approach is necessary if you want to
>> replace an element. As far as I know, we are only replacing whole 
>> rules and it seems unlikely that we'd be selecting on anything but
>>  identity. However, if you have lists like
>> 
>> <identity> <id>[email-masked]</id> <id>[email-masked]</id> 
>> </identity>
>> 
>> I don't see how attributes help here. Can you usefully select on
>> alice or bob even if this is rewritten as
>> 
>> <id user="[email-masked]" /> <id user="[email-masked]" />
>> 
>> ?
>> 
>> 
>>> 1) for which elements should we use approach (a) and for which
>>> other elements should we use approach (b) btw, we have already
>>> noted in discussions that we will not
>> 
>> use approach
>> 
>>> (a) everywhere. 2) we need a few lines of text to justify why we
>>> use
>> 
>> approach (a) for
>> 
>>> based on the decision for (1) we need to update the xml schema /
>>> xml documents (=examples) accordingly.
>>> 
>>> http://www.tschofenig.priv.at/TEMP/common-policy/ it still contains
>>> the old xml schema and examples that
>> 
>> follow appoach
>> 
>>> the mailing list and at the interim meeting. an xml schema that
>>> heavily uses approach (a) can be found
>> 
>> in the same
>> 
>>> ciao hannes
>>> _______________________________________________ Geopriv mailing
>>> list [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Jul 2005 13:09:42 -0400

The basic question is whether it is a good idea to manipulate sub-parts 
of the rule via XCAP. If bandwidth is not an issue, copying the whole 
rule, even if it contains a few hundred names, consumes no more 
bandwidth than the CNN front page, so optimizing this seems wasted effort.

For severely bandwidth-constrained devices or where incremental updates 
are desirable, restricting rules to having a single identity and 
identifying it with a rule-scoped tag avoids all of these issues. 
(Obviously, any multi-identity rule can be transformed into individual 
rules without any change in behavior.)

Henning

Aki Niemi wrote:
>>>> list [email-masked] https://www1.ietf.org/mailman/listinfo/geopriv
>>>
>>>
>>

---

From: Aki Niemi <[email-masked]>
Date: Thu, 07 Jul 2005 21:22:10 +0300

> bandwidth than the CNN front page, so optimizing this seems wasted effort.

No argument here.

> rules without any change in behavior.)

This is also a valid design alternative (probably a good one too). 
However, I think the bottom line is that the attribute-based schema 
design doesn't preclude this and others while it does enable the design 
I was describing earlier.

Seems to me it gives us more bang for the buck, and only requires a 
minor syntactic change. Unless it would break something else that I'm 
unaware of?

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Jul 2005 14:38:51 -0400

> minor syntactic change. Unless it would break something else that I'm 

FWIW, I have no objection to the change to attribute notation.