Subject: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-05.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 29 Jul 2009 17:30:12 +0300

Hi all, 

after reading RFC 4660 and RFC 4661, which is heavily used by
draft-ietf-geopriv-loc-filters-05.txt I had some concerns. RFC 4661 is a
very generic format for event notification filtering and it is good to
re-use the work that was done there. There is, however, a problem with
reusing it without putting additional restrictions on its usage, namely one
can accomplish the similar (if not the same) effect using many different
ways (at least the XML documents look different that are sent in the
SUBSCRIBE body). 

To me that sounds a lot like the issues we went through with GML. There we
also wanted to make the life of the implementer easier by restricting the
available options down to an acceptable minimum. 

I believe we should do the same with draft-ietf-geopriv-loc-filters as well.
If we find a way how to accomplish a certain functionality then the
structure of the XML document is going to be described in detail and that's
the way how it looks like and nothing else is allowed. 

Do others share my concerns? 

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Jul 2009 11:21:28 -0400

Could you cite some examples, please.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hannes Tschofenig
> Sent: Wednesday, July 29, 2009 10:30 AM
> To: [email-masked]
> Subject: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-
> 05.txt
> 
> Hi all,
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 29 Jul 2009 20:02:04 +0300

For example, RFC 4661 would allow you to detect changes in civic address
tokens in the following way:

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
    <ns-bindings>
        <ns-binding prefix="ca" 
            urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
    </ns-bindings>
    <filter id="123" uri="sip:[email-masked]">
        <trigger>
            <changed>//ca:A1</changed>
        </trigger>
    </filter>
</filter-set>

Or

<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
    <ns-bindings>
        <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
        <ns-binding prefix="gp"
urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
        <ns-binding prefix="cl"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
    </ns-bindings>
    <filter id="1" uri="sip:[email-masked]">
        <trigger>
            <changed>
 
/pidf:presence/pidf:tuple/pidf:status/gp:geopriv/gp:location-info/cl:civicAd
dress/cl:A1 
            </changed>
            <changed>
 
/pidf:presence/pidf:device/gp:geopriv/gp:location-info/cl:civicAddress/cl:A1

            </changed>
            <changed>
 
/pidf:presence/pidf:person/gp:geopriv/gp:location-info/cl:civicAddress/cl:A1

            </changed>
        </trigger>
    </filter>
</filter-set>

Do we know anything about the implementation status of RFC 4661? 

Ciao
Hannes

>From: Brian Rosen [mailto:[email-masked]] 
>Sent: 29 July, 2009 18:21
>To: 'Hannes Tschofenig'; [email-masked]
>Subject: RE: [Geopriv] My concern with 
>draft-ietf-geopriv-loc-filters-05.txt
>
>> draft-ietf-geopriv-loc-filters-05.txt I had some concerns. 
>RFC 4661 is 
>> a very generic format for event notification filtering and 
>it is good 
>> to re-use the work that was done there. There is, however, a problem 
>> with reusing it without putting additional restrictions on 
>its usage, 
>> namely one can accomplish the similar (if not the same) effect using 
>> many different ways (at least the XML documents look different that 
>> are sent in the SUBSCRIBE body).
>> 
>> To me that sounds a lot like the issues we went through with GML. 
>> There we also wanted to make the life of the implementer easier by 
>> restricting the available options down to an acceptable minimum.
>> 
>> I believe we should do the same with 
>draft-ietf-geopriv-loc-filters as 
>> well.
>> structure of the XML document is going to be described in detail and 
>> that's the way how it looks like and nothing else is allowed.
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Jul 2009 13:51:44 -0400

Having looked at this, I'm wondering if restricting (prohibiting) certain
xpath constructions is wise.  I agree suggesting specific ways (the first in
your examples) is preferred.

Do you see an actual interoperability problem, or merely an opportunity to
provide a short cut method to avoid implementing the full xpath?

Brian

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Wednesday, July 29, 2009 1:02 PM
> To: 'Brian Rosen'; [email-masked]
> Subject: RE: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-
> 05.txt
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 29 Jul 2009 21:39:49 +0300

I don't know how well RFC 4661 is interoperable. 

I care about the persons who have to implement this. 
Note that we are talking about dumping this functionality into a LIS. The
LIS will most likely have to implement this functionality without potential
for re-use with other applications.  

Maybe the implementation of RFC 4661 is simple and I am worried without a
reason. 

Ciao
Hannes

>Sent: 29 July, 2009 20:52
>Having looked at this, I'm wondering if restricting 
>(prohibiting) certain xpath constructions is wise.  I agree 
>suggesting specific ways (the first in your examples) is preferred.
>
>Do you see an actual interoperability problem, or merely an 
>opportunity to provide a short cut method to avoid 
>implementing the full xpath?
>
>Brian
>
>> For example, RFC 4661 would allow you to detect changes in civic 
>> address tokens in the following way:
>> 
>> <?xml version="1.0" encoding="UTF-8"?> <filter-set 
>> xmlns="urn:ietf:params:xml:ns:simple-filter">
>>     <ns-bindings>
>>         <ns-binding prefix="ca"
>> <?xml version="1.0" encoding="UTF-8"?> <filter-set 
>> xmlns="urn:ietf:params:xml:ns:simple-filter">
>>     <ns-bindings>
>> >> to re-use the work that was done there. There is, however, a 
>> >> problem with reusing it without putting additional restrictions on
>> >its usage,
>> >> namely one can accomplish the similar (if not the same) effect 
>> >> using many different ways (at least the XML documents look 
>> >> different that are sent in the SUBSCRIBE body).
>> >>
>> >> structure of the XML document is going to be described in detail 
>> >> and that's the way how it looks like and nothing else is allowed.
>> >>

---

From: ashok malhotra <[email-masked]>
Date: Wed, 29 Jul 2009 15:44:58 -0700

A couple of comments re. RFC 4661

1. As you know, RFC 4661 was written with the SIP protocol in mind.  So, 
the filters it discusses are
a bit different from what would be needed for Geopriv.  So, I assume you 
are planning on using the spirit,
not the letter of RFC 4661.

2.  Please, please do not try and subset XPath.  I realize that XPath is 
a complex specification but if you
try and subset it you will open yourself to months of argumentation.  
Second, most vendors already have a
XPath implementation and it's better to just use it rather than prepare 
an implementation for a subset of XPath

All the best, Ashok

Hannes Tschofenig wrote:
>> draft-ietf-geopriv-loc-filters- 
>>     
>>> 05.txt
>>>
>>>>> From: [email-masked] 
>>>>>           
>> [mailto:[email-masked]] On 
>>     
>>>>> Subject: [Geopriv] My concern with 
>>>>>           
>> draft-ietf-geopriv-loc-filters- 
>>     
>>>>> 05.txt
>>>>>
>>>>> Hi all,
>>>>>
>>>>> There we also wanted to make the life of the implementer 
>>>>>           
>> easier by 
>>     
>>>>> If we find a way how to accomplish a certain 
>>>>>           
>> functionality then the 
>>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 29 Jul 2009 18:11:13 -0500

>Do others share my concerns?

I agree with you. These RFCs are written from the point of view of a 
WG member having spent a lot of time in the WG monitoring or actively 
participating in the discussions about these efforts.

Each are hard to get your head around the totality of what is in or 
out of scope of these docs, and the examples are poor IMO - providing 
very little help.

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 30 Jul 2009 02:29:54 -0500

1. I think that you've confused this with something else, we're talking about SIP here as well.  In effect, GEOPRIV are just adding location support to SIP presence.

2. That boat sailed with 4661.

--Martin

> Behalf Of ashok malhotra
> Sent: Thursday, 30 July 2009 12:45 AM
> To: Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-
> 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]

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 30 Jul 2009 02:48:00 -0500

I very much agree with your suggestion that we constrain how 4661 is used.  A profile would greatly help.

Of course, there is a concern that if we specify a profile, there will be consumers of filters that do not implement the full generic functionality.  But I think that we can demonstrate that this complete implementation is unlikely or even impossible.

I reviewed 4661 late in the piece and made a comment about how difficult it would be to implement and how its generic nature was also its biggest weakness.

For instance, there is a requirement that if a required element is specified then that implicitly requires that all other XML nodes necessary to make the document valid.  This is actually quite difficult to implement.  As long as you have a simple schema, it's probably workable, but complex content models are something of a challenge.  I can also give examples of cases where it is possible to specify an element in such a way that this could be achieved in several ways.

PIDF-LO is a great example of such a problem.  //ca:A1 can be included, validly, in any of several trees, as you mentioned earlier.

Specifying values in the changed element is different.  Implementation is relatively easy.  All the filter does is establish a node set - and thereby a set of values - that the server extracts from documents and monitors for changes.  That is fairly easily implementable.

I don't want this to head in a direction where we invite string matching or other such un-interoperable hacks.  That is, I don't want someone to look for "//${ca}:A1" or something like that.  

--Martin

> Sent: Wednesday, 29 July 2009 8:40 PM