Subject: [Geopriv] xcap, common-policy and geopriv-policy

From: "Guenther, Christian" <[email-masked]>
Date: Wed, 25 May 2005 17:56:52 +0200

Hi,

with respect to the xcap issue of the common-policy schema, Jonathan
suggested (April 19)
to fix the problem either

1) by transferring the element content into the value of an attribute, 
or
2) by adding to the element an attribute whose value distinguishes the
element from elements of the same name.

For example, <id>[email-masked]</id> should then be replaced by either

1) <id nai="[email-masked]"/>,
or
2) <id val="1">[email-masked]</id>.

As far as I can see, proposal 1) works well as long as the element in
question (<id>) does not have child elements. In the geopriv-policy
schema, however, we have the geospatial-loc-condition element, for
instance, which can be the root of the element tree

<geospatial-loc-condition>
<polygon>
<point>
<lat><lon>.

Suppose there are two such instances of the geolocation-loc-condition
element in the conditions part of a given rule and xcap is supposed to
select one of them. According to proposal 1), we had to transform the
entire element tree into the value of an attribute in some way.
Therefore, I prefer proposal 2), since then we could simply write down

<geospatial-loc-condition val="1">...</geospatial-loc-condition> and
<geospatial-loc-condition val="2">...</geospatial-loc-condition>,

so that xcap could easily select one of the two geospatial-loc-condition
elements. 

Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Aki Niemi
Sent: Mittwoch, 18. Mai 2005 15:39
To: Tschofenig, Hannes
Cc: [email-masked]
Subject: Re: [Geopriv] revised identity text

Hi All,

Hannes asked me to summarize an issue that was sent to the SIMPLE WG 
about common-policy. This is an issue in the context of manipulating 
common-policy rules using XCAP.

The problem is that XCAP only allows selection (and therefore addition, 
removal and modification) of nodes based on element name, attribute and 
position. It doesn't support selection based on element content. 
Therefore selecting <id> elements within the <identity> seems 
unnecessarily hard, since the rule maker always needs an up-to-date copy

of the <identity> element to find out the position of the correct <id> 
to be selected.

To fix this, there has been a proposal to tweak the <id> element such 
that instead of:

<id>[email-masked]</id>

it becomes:

<id value="[email-masked]" />

Selecting this element is much easier in XCAP simply using the attribute

value as the node selector, and also seems like a minor change to 
common-policy schema.

Cheers,
Aki

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

---

From: "Ono, Kumiko" <[email-masked]>
Date: Wed, 25 May 2005 15:13:17 -0400

Hannes and all,

My explanation of the JIS address code at the iterim meeting was not 
clear enough. I related the JIS address code to postal code 
inappropriately. So let me briefly explain these two codes and how the 
JIS addres code is used in emergency call.

- Postal code
The Japanese postal address code, seven-digit format, consists of an 
identifier of a mail delivery office and an extension code. The 
extension code gerenally identifies a town. It can also identify an 
enterprise where receives large volumes of mails, or a floor level of a 
very tall office building. Ultimately postal code is assigned based on 
mail volumes and per mail delivery office. The first two-digit code is 
not always one to-one correspond with a prefecture.

- the JIS address code
This consists of 11 digits. The first two digits are assigned to a 
prefecture, 3rd to 5th digits to a city or a district, 6th to 8th to a 
town and 9th to 11th to an area. The last three digit code can be also 
assinged to each floor if the remaining code (first eight digit) 
represents a very tall office building. For detail, please refer to the 
appendix in draft-arai-ecrit-japan-req-01.txt

- How to select a PSAP by using the JIS address code.
A PSAP/jurisdiction can be selected basically by using the first five-
digit of the JIS address code as an index key combined with the 
emergency identifier, such as 110(police) or 119(fire). The next three 
digits (town level information) are used in case when the primary PSAP 
is congested, in order to find a secondary PSAP which is usually in the 
next city or district.
The last three digits (area/floor level information) is not in use for 
selecting a PSAP.

I don't have any knowledge of how this JIS address code is used within 
PSAP, if it's used.

[FYI] Location addresses in Japan
Most of streets other than major avenues are not named in Japan.
We divide a town into some areas, subareas and blocks, and number them 
accordingly.

I hope this is helpful to those interested in how the JIS address code 
is used.

Thanks,
Kumiko

---

From: Aki Niemi <[email-masked]>
Date: Thu, 26 May 2005 17:08:36 +0300

Hi,

Inline.

ext Guenther, Christian wrote:
> question (<id>) does not have child elements.

As it shouldn't. If it did, then you at least need conditional updates.

> In the geopriv-policy

I think this is far less important in these kind of cases. Sure the val 
attribute provides a key, but it isn't naturally a unique one (like the 
identity is). Therefore, you still need a local copy to determine the 
value of this attribute in order to select the appropriate condition 
using the val attribute as the node selector.

You couldn't just "blindly" remove a condition because the handle is a 
random one. Unless you're suggestion is to always order these elements 
so that the val actually represents the position of the element, then 
you end up wasting many more round trips in ordering than potentially 
you might save as a result of it.

However, I could see a similar need for the <domain> and the <id>s under 
<except> elements. These also have the necessary uniqueness to serve as 
a handle.

Cheers,
Aki