Subject: [Simple] Usage of substitution groups in draft-ietf-geopriv-common-policy

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Dec 2004 00:03:55 -0500

Folks,

In several of the simple and geopriv specifications, we are making use 
of XML substitution groups as the mechanism for document extensibility. 
These include draft-ietf-geopriv-common-policy, which is extended by 
draft-ietf-simple-presence-rules.

However, it appears that substitution groups introduce some limitations. 
Most important amongst them is that, in order to be validated against 
the schema for the baseline document, the entity doing the validation 
must be aware of the schemas for all namespaces for elements that are 
part of the substitution group. This doesn't work well in cases where we 
expect the entity creating the document to be making use of extensions 
that the entity doing the validation isn't going to be aware of (and 
shouldn't need to be).

This is particularly problematic for draft-ietf-simple-presence-rules, 
where we expect to use xcap to manipulate the documents. The xcap server 
needs to be able to validate the document according to the baseline 
schema, but it should not be required to know about all of the 
extensions that we might see in order to process the document. Right 
now, it would have to.

As a result, I'd suggest that draft-ietf-geopriv-common-policy make use 
of the <any> constructs for defining extensibility, rather than 
substitution groups.

Comments?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 14 Dec 2004 08:57:20 +0200

ext Jonathan Rosenberg wrote:

> of XML substitution groups as the mechanism for document 
> extensibility. These include draft-ietf-geopriv-common-policy, which 
> is extended by draft-ietf-simple-presence-rules.
>
> However, it appears that substitution groups introduce some 
> limitations. Most important amongst them is that, in order to be 
> validated against the schema for the baseline document, the entity 
> doing the validation must be aware of the schemas for all namespaces 
> for elements that are part of the substitution group. This doesn't 
> work well in cases where we expect the entity creating the document to 
> be making use of extensions that the entity doing the validation isn't 
> going to be aware of (and shouldn't need to be).
>
> where we expect to use xcap to manipulate the documents. The xcap 
> server needs to be able to validate the document according to the 
> baseline schema, but it should not be required to know about all of 
> the extensions that we might see in order to process the document. 
> Right now, it would have to.
>
> As a result, I'd suggest that draft-ietf-geopriv-common-policy make 
> use of the <any> constructs for defining extensibility, rather than 
> substitution groups.
>
> Comments?
>
> -Jonathan R.
>
Let's say you add a new extension e.g. <provide-dispatcher> 
transformation onto the presence rules. If you'll use <any> constraint 
in the schemas the server may validate the document although it may not 
"understand" this new transformation and the client may think that it 
will. However, if you'll use substitution groups and try to use this new 
extension the server will not validate this extension unless it has this 
new definition. So imo substitution groups provide much more consistent 
behavior in this case.  If these rules are stored within the xcap server 
the client can always query the server capabilities (which lists 
namespaces that it understands).

Of course there are situations where substitution groups don't 
necessarily fit that well, i.e. they may be too restrictive. However, I 
may have misunderstood where/how you'll want to use <any>...
br,
Jari

---

From: Hisham Khartabil <[email-masked]>
Date: Tue, 14 Dec 2004 14:10:03 +0100

On Dec 14, 2004, at 7:57 AM, Jari Urpalainen wrote:

>> In several of the simple and geopriv specifications, we are making 
>> use of XML substitution groups as the mechanism for document 
>> work well in cases where we expect the entity creating the document 
>> to be making use of extensions that the entity doing the validation 
>> isn't going to be aware of (and shouldn't need to be).
>>
>> This is particularly problematic for 
>> draft-ietf-simple-presence-rules, where we expect to use xcap to 
>> manipulate the documents. The xcap server needs to be able to 
>> validate the document according to the baseline schema, but it should 
>> not be required to know about all of the extensions that we might see 
>> in order to process the document. Right now, it would have to.
>>
> in the schemas the server may validate the document although it may 
> not "understand" this new transformation and the client may think that 
> it will. However, if you'll use substitution groups and try to use 
> this new extension the server will not validate this extension unless 
> it has this new definition. So imo substitution groups provide much 
> more consistent behavior in this case.  If these rules are stored 
> within the xcap server the client can always query the server 
> capabilities (which lists namespaces that it understands).

As you say, the client can query server capabilities, so if the schema 
uses the <any> instead of substitution groups, then this REQUIRES the 
client to query first if it is critical to it that the server 
understands the extension. The difference is that when using <any>, the 
client will never know whether the server understands an extension or 
not unless it queries it. For substitution, the client will know since 
the server will not validate the XML document. Requiring the client to 
query server for its capabilities is not a bad thing. So I believe that 
<any> is sufficient enough.

Regards,
Hisham

> necessarily fit that well, i.e. they may be too restrictive. However, 
> I may have misunderstood where/how you'll want to use <any>...
> br,
> Jari
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 14 Dec 2004 09:13:16 -0500

To add to this, agreeing: At least some of the XML schema verifiers give 
up after the first error. Thus, you might end up with repeatedly trying 
to determine what extensions are actually supported, by removing one 
offending part after the other. Schema validation doesn't strike me as a 
particularly useful approach to discovering server capabilities (and I 
don't think it's really designed for this).

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Dec 2004 10:06:46 -0500

Jari,

My concern is that I may sometime find myself to be an AOL subscriber 
for presence. (Perhaps because that is the only place some of my buddies 
are capable of accessing.)

I don't want to be dependent on AOL to install support for a new 
presence entity before I can begin to use it.

	Paul

---

From: Jari Urpalainen <[email-masked]>
Date: Wed, 15 Dec 2004 14:13:57 +0200

ext Paul Kyzivat wrote:

> for presence. (Perhaps because that is the only place some of my 
> buddies are capable of accessing.)
>

If it so that the client only needs to "understand" this extension I'll 
agree but if you need also the server to "understand" it then I may 
disagree.

My point was and is that we'll have to select case-by-case the extension 
model. I am assuming that we all want unambiguous and consistent 
semantics. Looking from the schema validation pov we have at least these 
possibilities:
1. using <any> with ##any or ##other namespace and with processContents 
"lax", "skip" or "strict".
2. using abstract elements with substitionGroups
The latter is the most restrictive one (and of course you'll need the 
new definitions) although there's not a big difference in that respect 
with <any> with "strict".

Speaking about the presence entity we'll get onto pidf, where the 
extension is based on <any>, "##other" and "lax" model. Let's say we are 
using rpid extension. So if the validator has rpid schema and the 
instance document uses e.g. <privacy> extension but instead of the 
requirement (<status>) puts that onto <tuple>. The validator can check 
that <privacy> is well formed and valid according to rpid schema but it 
doesn't know where it belongs within the pidf and will then validate the 
document. However, if substitutionGroup had been used it would have 
explicitly forbidden this. So my point is that abstract types with 
substitutionGroups are very explicit and imo a good way to point the 
extension places in xml documents. Using <any> introduces vagueness to 
the validation process that I would prefer to avoid. 

So to summarize my preference is abstract elements with 
substitutionGroups in this context. However, if there's really a need 
e.g. for the case where the clients can use the extension before the 
server is being updated then there is not any other alternative than to 
use <any>.

So then back to the reality, are we looking in presence authorization 
e.g. something like ?

<xs:element name="provide-extension" substitutionGroup="cr:transformation">
  ||<xs:complexType>
    <xs:any namespace="##other" processContents="lax" minOccurs="0" 
maxOccurs="unbounded">
  ||</xs:complexType>
</xs:element>

br,
Jari

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Dec 2004 10:22:48 -0500

> agree but if you need also the server to "understand" it then I may 

Yes, the distinction is key.

> with <any> with "strict".

I think the problem is that we want the best of both, and that doesn't 
seem to be possible. What I mean is:

- for those that don't understand it, we would like a treatment like 
<any> with lax or skip. (I don't know xml well enough to understand the 
difference between those.)

- for those that do understand the item, we would like it to be treated 
with the substitution group semantics.

At least I think that is what we would like for PIDF extensions. In many 
cases it is probably sufficient for the endpoints to understand the 
extensions they want and ignore the rest. And for the presence server to 
treat them generically without understanding them.

For sophisticated composition of presence documents a lack of 
understanding of an element will perhaps lead to less than perfect 
composition. But the decoupling of client evolution from server 
evolution is sufficiently important that composition needs to be 
designed to tolerate this.

> explicitly forbidden this.

Yes, this was the motivation to use substitution groups. But if the 
validator hasn't heard of <privacy> then validation fails even if it was 
used correctly.

With <any>, it will pass on the server, but hopefully the receiving 
client that does understand it will recognize that it is misplaced. But 
that recognition of being misplaced then can't be part of the formal 
validation logic, but must be hand coded.

 > So my point is that abstract types with

The tradeoff is better validation in the server, but constraint that you 
can't use a new feature until the server has been extended to support 
it. For presence I think this is a bad tradeoff.

> server is being updated then there is not any other alternative than to 

Sad. We need an extension mechanism different than what is available.

>    <xs:any namespace="##other" processContents="lax" minOccurs="0" 

Don't understand above.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Dec 2004 16:28:17 -0500

As an additional datapoint:

http://www.w3.org/TR/xmlschema-0/

says (Section 5.5):

"The lax  value of the processContents  attribute instructs an XML 
processor to validate the element content on a can-do basis: It will 
validate elements and attributes for which it can obtain schema 
information, but it will not signal errors for those it cannot obtain 
any schema information."

That seems roughly what we want, with the exception of not being able to 
constrain the positioning of elements noted below.

Note that PIDF already provides a mechanism for mandatory-to-understand 
pieces of <status> extensions. As far as I can tell, it does not, 
however, indicate whether the composer or the watcher is obligated.

Paul Kyzivat wrote:
>> If it so that the client only needs to "understand" this extension 
>> I'll agree but if you need also the server to "understand" it then I 
>> may disagree.
> 
> 
>> My point was and is that we'll have to select case-by-case the 
>> extension model. I am assuming that we all want unambiguous and 
>> consistent semantics. Looking from the schema validation pov we have 
>> at least these possibilities:
>> 1. using <any> with ##any or ##other namespace and with 
>> processContents "lax", "skip" or "strict".
>> extension is based on <any>, "##other" and "lax" model. Let's say we 
>> are using rpid extension. So if the validator has rpid schema and the 
>> that <privacy> is well formed and valid according to rpid schema but 
>> it doesn't know where it belongs within the pidf and will then 
>> validate the document. However, if substitutionGroup had been used it 
>> would have explicitly forbidden this.
> 
> 
>> server is being updated then there is not any other alternative than 
>> to use <any>.
> 
>

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 17 Dec 2004 12:30:01 +0200

ext Henning Schulzrinne wrote:

> That seems roughly what we want, with the exception of not being able 
> to constrain the positioning of elements noted below.
>
If there's only a single extension point then also this positioning 
problem vanishes. However, I still have a problem understanding 
(regarding common-policy) "what we want" as I can't see any problem with 
the current draft besides perhaps the usefulness of Content-Type 
registration which is imo needed in presence-rules instead.

> Note that PIDF already provides a mechanism for 
> mandatory-to-understand pieces of <status> extensions. As far as I can 
> tell, it does not, however, indicate whether the composer or the 
> watcher is obligated.
>
This mechanism is also beyond what schema validation can do.

> Paul Kyzivat wrote:
>
>>
>>
>>
>>> So then back to the reality, are we looking in presence 
>>> authorization e.g. something like ?
>>>
This was my attempt to ask where are the missing extension points in 
presence rules. After I re-glanced the draft I found 
<provide-unknown-attribute> which approximately does the same thing that 
I had in mind. However, looking at these <transformations> they all (at 
least most of them) are such that they can easily be implemented with 
XPath semantics which is also the model in the current filtering drafts. 
I am inclined to prefer that model because of it's  flexibility and 
inherent extensibility.

br,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Dec 2004 02:49:28 -0500

inline.

> registration which is imo needed in presence-rules instead.

The problem case I am worried about is the following.

We are using xcap. A client is managing its presence authorization 
policies. It attempts to upload a document to the server. The client is 
made from a different vendor from the server, and has recently been 
upgraded to support a new permission type. This new permission is not 
understood by the server.

As currently defined, since xcap servers have to do xml validation, the 
user will not be able to upload its permissions. I believe it should be 
able to do so. We have designed the common-policy work to be "privacy 
safe" so even if permissions unknown to the server are included, 
additional information can never be leaked.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Dec 2004 02:49:28 -0500

inline.

-Jonathan R.

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

---

From: Jari Urpalainen <[email-masked]>
Date: Mon, 20 Dec 2004 19:03:30 +0200

ext Jonathan Rosenberg wrote:

>>> information, but it will not signal errors for those it cannot 
>>> obtain any schema information."
>>>
>>> That seems roughly what we want, with the exception of not being 
>>> able to constrain the positioning of elements noted below.
>>>
>> (regarding common-policy) "what we want" as I can't see any problem 
>> with the current draft besides perhaps the usefulness of Content-Type 
> policies. It attempts to upload a document to the server. The client 
> is made from a different vendor from the server, and has recently been 
> As currently defined, since xcap servers have to do xml validation, 
> the user will not be able to upload its permissions. I believe it 
> should be able to do so. We have designed the common-policy work to be 
> "privacy safe" so even if permissions unknown to the server are 
> included, additional information can never be leaked.
>
> -Jonathan R.

Thanks Jonathan for the clarification. Although I'll agree with these 
"privacy safe" issues I would still prefer the current very 
deterministic model, because imo dropping the rules that the server 
doesn't understand is exactly the right thing to do as we are expecting 
the server to do the "real" work. Furthermore, as the client already 
knows that it's using an extension  it should be able to fall back to 
the basic rules easily. So I'd rather keep the strict rules.

br,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Dec 2004 13:43:17 -0500

> the basic rules easily. So I'd rather keep the strict rules.

I don't follow you here.

With common-policy as currently defined, the server won't just "drop the 
rules it doesn't understand" - the entire document will fail validation, 
and no rules will be placed on the server at all.

Perhaps what you are proposing is that the request should fail, and that 
the client should have a way to figure out why, and then adjust its 
document to only use namespaces understood by the server?

-Jonathan R.

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 20 Dec 2004 20:48:48 +0100

On Dec 20, 2004, at 7:43 PM, Jonathan Rosenberg wrote:

>>> is made from a different vendor from the server, and has recently 
>>> been upgraded to support a new permission type. This new permission 
>>> is not understood by the server.
>>>
>>> should be able to do so. We have designed the common-policy work to 
>>> be "privacy safe" so even if permissions unknown to the server are 
>> doesn't understand is exactly the right thing to do as we are 
>> expecting the server to do the "real" work. Furthermore, as the 
>> client already knows that it's using an extension  it should be able 
>> to fall back to the basic rules easily. So I'd rather keep the strict 
>> rules.
>
> I don't follow you here.
>
> With common-policy as currently defined, the server won't just "drop 
> the rules it doesn't understand" - the entire document will fail 
> validation, and no rules will be placed on the server at all.
>
> Perhaps what you are proposing is that the request should fail, and 
> that the client should have a way to figure out why, and then adjust 
> its document to only use namespaces understood by the server?

Why wait until it fails? As I said in an earlier email, the client can 
query for server capabilities if it REQUIRES that server to support a 
certain extension. If the client doesnt care, then it just uses the 
extensions. The client doesnt care in cases where the server need not 
know the semantics of things.

Regards,
Hisham

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 21 Dec 2004 11:52:00 +0200

ext Hisham Khartabil wrote:

>>>> policies. It attempts to upload a document to the server. The 
>>>> client is made from a different vendor from the server, and has 
>>>> recently been upgraded to support a new permission type. This new 
>>>> permission is not understood by the server.
>>>>
>>> Thanks Jonathan for the clarification. Although I'll agree with 
>>> these "privacy safe" issues I would still prefer the current very 
>>> to fall back to the basic rules easily. So I'd rather keep the 
>>> strict rules.
>>
>>
>> I don't follow you here.
>>
yes, this is what I meant (and I certainly hope that extensions play a 
minor role here).

> know the semantics of things.

yes you can utilize server capabilities when you'll have a xcap server 
(which may not always be the case). But the use-case here is what is the 
right behavior in this context.

br,
Jari

---

From: Kamalakanta Palei <[email-masked]>
Date: Wed, 22 Dec 2004 07:58:53 -0800 (PST)

Hi

Suppose user A has logged in two different sip devices (that support presence and IM).

When a different user B sends an IM to A (say through proxy), then that IM will be delivered to which device.

Will this IM be delivered to any arbitrary device or any specific rule is there.

Any comment, highly appriciated.

Regards

Kamal

---------------------------------
Do you Yahoo!?
 Dress up your holiday email, Hollywood style. Learn more.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Dec 2004 14:04:33 -0500

Kamal,

Currently there is no simple answer to your question. But the following 
are some possible answers:

1) if you mean an IM using MESSAGE, then it will likely be forked to 
both devices.

1a) If parallel forking is used, then the message will probably be 
displayed on both devices. One of the responses will be returned to the 
sender, and the other will be suppressed by the forking proxy.

1b) If serial forking is used, then if the first accepts it, it will 
only go there.

2) if session mode IM is used via MSRP. Then there is an open issue of 
whether this will be treated like voice, where the callee is alerted and 
must answer before media is delivered, or if IM calls are implicitly 
answered, or if an "early media" session is established and the first 
message sent then.

2a) If treated like a voice call,

2a1) if parallel forking is used, then both devices will be alerted. The 
call will complete to the first one to answer, and the message will be 
delivered there. The other fork will be cancelled.

2a2) If treated like a voice call and serial forking is used, if the 
first device answers then the message will be delivered there. If the 
first device doesn't answer, the other will be tried and if it answers 
the message will go there. Except for timing, 2a1 and 2a2 are the same.

2b) If IM calls are implicitly answered,

2b1) if parallel forking is used then both devices will receive the call 
and both will answer. The first answer to reach the proxy will win, and 
the other will be cancelled. Then the message will be delivered to the 
winner. If the cancel doesn't reach the losing device in time, then both 
200s will go to the caller, which may keep one and terminate the other, 
or may keep them both. This is pretty ugly.

2c) If IM calls result in early media sessions,

2c1) If parallel forking is used, the call will go to both devices, and 
a separate early media session will be established to each. The sender 
will then send the message to both. This message will then be displayed 
on both devices. A user at one of the devices will acknowledge the 
message - possibly by just clicking, or maybe by sending a response. The 
UA can use that as indication to accept the call. When this happens, the 
proxy will cancel the other fork. The other device will then need to 
indicate that it "missed the call". The sender will then continue the 
conversation with the winning device.

2c2) if serial forking used, the call will go to one device, an early 
media session will be established, the message will be sent and 
displayed. If the user acknowledges, the call will complete to it. If 
not, the call will eventually time out and be cancelled. The device will 
indicate the missed call. Then the call will be tried to the other 
device, etc.

I find (2c) to be by far the most attractive way to handle this.

	Paul

Kamalakanta Palei wrote:
> ------------------------------------------------------------------------
> Do you Yahoo!?
> <http://us.rd.yahoo.com/evt=29909/*http://celebrity.mail.yahoo.com>
> 
> 
> ------------------------------------------------------------------------
>