Subject: AW: [Geopriv] common policy update

From: "Tschofenig, Hannes" <[email-masked]>
Date: Fri, 21 Oct 2005 16:39:53 +0200

hi jonathan,

thanks for the feedback. 
i reflected your comments considering my other mail about the update problem. 

i haven't added more text on the internationalization front. 

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]] 
> Gesendet: Freitag, 21. Oktober 2005 06:52
> An: Tschofenig, Hannes
> Cc: [email-masked]
> Betreff: Re: [Geopriv] common policy update
> 
> 
> Comments on the condition pieces. Its looking better, but not 
> there yet:
> 
> >  protocol-specific documents.  As usual, if the condition 
> is omitted,
> >    identities are not considered and, thus, the condition 
> matches any
> >    user.
> 
> ..matches any user, authenticated or not.
> 
> 
> >  This document defines the following scheme types:
> > 
> >    o  sip
> > 
> >    o  mailto
> > 
> >    o  xmpp
> > 
> > 
> > 
> > 
> > Schulzrinne, et al.      Expires April 23, 2006             
>    [Page 14]
> > > 
> > Internet-Draft                Common Policy                 
> October 2005
> > 
> > 
> >    o  tel
> > 
> >    Further schemes are subject to IANA registration.
> 
> there was no registry defined in the iana considerations 
> section. I dont 
> think you need one though. I would instead state that the values can 
> constitute any URI scheme registered in the URI schemes registry 
> (http://www.iana.org/assignments/uri-schemes) by the 
> procedures in RFC 
> 2717. If you do that, you don't need to enumerate any schemes.
> 
> 
> > An identity condition matches if any of its child elements 
> (i.e., the
> >    <one> and the <many/> elements defined in this document) 
> matches with
> >    the authenticated identity, i.e., the results of the 
> individual child
> >    element matches are combined with a logical OR.
> 
> Its a bit unclear which child you mean. I think this is 
> better phrased 
> as, "The identity condition evalues to true if the OR of all of the 
> children of <identity> evalues to true."
> 
> > A <many/> element does not match, if any of the <except> elements
> >    that are its children matches with the authenticated 
> identity, i.e.,
> >    the exception results are combined with a logical OR.
> 
> this probably belongs in the section on Matching Multiple Entities
> 
> > The schemes 'sip', 'mailto' and 'xmpp' fall into the category of
> >    identifiers that have a username and domain part and are 
> therefore
> >    treated as described above and have the semantic of a 
> single entity
> >    (i.e., <one/> element) or a group of entities (i.e., <many/>).
> 
> this is confusing. I think you mean to say that the sip, 
> mailto and xmpp 
> schemes are applicable to the <one> and <many> elements.
> 
> > 7.1.2.  Matching One Entity
> > 
> >    The <one/> element matches exactly one entity or user.
> 
> you dont' actually define how you match the identity of the 
> originator 
> to the <any> condition. You need to talk about whether the 
> matching is 
> scheme specific if a scheme is specified. If not specified, 
> what about 
> case sensitivity? i18n? etc.
> 
> I think you should say:
> 
> Matching depends on whether the scheme attribute is present 
> or not. If 
> the scheme attribute is present, the identity of the WR is 
> represented 
> as a URI. Generally, this URI scheme will be a function of the using 
> protocol. The procedure for determing a URI that identifies the WR is 
> defined by protocol specifications making use of the common policy 
> framework. If this scheme is not amongst the schemes in the 'schemes' 
> attribute, the <entity> condition doesnt match and is 
> considered FALSE. 
> If the scheme is present, the value of the 'id' attribute is 
> converted 
> into a URI of that scheme, based on a conversion process defined by 
> specification defined for that URI scheme. Once the 
> conversion is done, 
> the resulting URI is compared to the URI identifying the WR 
> according to 
> URI equivalence rules for that scheme. If there is a match, 
> the <entity> 
> condition is considered TRUE.
> 
> If the scheme attribute is not present, The entity of the WR is 
> represented in the form user@domain. If the using protocol does not 
> provide an identity that is representable in that form, the <entity> 
> condition doesnt match and is considered FALSE. If the using protocol 
> does provide an identity that is representable in that form, it is 
> taken. The procedure for determing a user@domain form that identifies 
> the WR is defined by protocol specifications making use of the common 
> policy framework. This identifier is compared to the value of the id 
> attribute. The comparison is done based on case sensitive string 
> comparison for the user part, and case insensitive for the 
> domain part.
> 
> 
> 
> The above text is weak in the i18n area, I suspect there is something 
> easily referenceable here. Another thing thats missing is a clear 
> definition of the characters allowed for the user part. One 
> idea is to 
> use the NAI from rfc2486, which defines a BNF but not 
> equivalence rules 
> or i18n considerations.
> 
> 
> 
> > 7.1.3.  Matching Multiple Entities
> > 
> >    The <many/> element is used to match one or more 
> entities based on
> >    "wildcard" conditions, based on domains.
> 
> This section is missing the high level idea of how this 
> works. The idea, 
> I think, is that the identity of the WR is matched against 
> each of the 
> children of <many>, which can be <domain> or <except>. If it 
> matches at 
> least one of the <domain> elements, and doesn't match any of the 
> <except> elements, the <many> condiiton is true. If the 
> identity matches 
> at least one of the <domain> elements, but matches at least 
> one of the 
> <except> elements, the <many> condition is false. If the identity 
> doesn't match any of the <domain> elements, the <many> condition is 
> false. If there are no <domain> elements, its treated as if 
> there were 
> one and the identitiy of the WR matches. If there are no <except> 
> elements, its treated as if there were one and the identity of the WR 
> does not match.
> 
> 
> With this logic, all of your subsections are examples which show how 
> this works, rather than being a definitive definition of the logic to 
> execute, which is hard to extract from the use cases.
> 
> 
> > The <many/> element enclosing one or more <except domain="..."/>
> >    elements matches any user from any domain except those 
> enumerated.
> 
> this doesn't match the syntax of the example, which is 
> <except><domain 
> name="...">.
> 
> > The <except id="..."/> element excludes particular users.  The
> >    exception are logically ORed.
> 
> Its not clear whether you are matching the identitiy of the 
> WR against 
> each child of <except> and then ORing the result, or rather, matching 
> against the entire <many> expression, using each except child 
> one at a 
> time, and matching the results. You intend the former I think, but it 
> could be misread. I'd suggest it say something like:
> 
> The identity of the WR is evaluated against each of the child 
> elements 
> of <except>. If any of these child elements match the idenitiy of the 
> WR, the <except> expression itself evaluates to true. If there are no 
> child elements of <except>, its as if there were one and it 
> matched the 
> identity of the WR, resulting in the evaluation of <except> to true.
> 
> You should also say that the children of <except> can be <entity> or 
> <domain>.
> 
> >            <except>
> >                <entity id="alice"/>
> >                <entity id="bob"/>
> 
> Here, there is no @domain for these, but there is above. It should be 
> one or the other. I think it should be always with the @. It 
> does mean 
> that you could write things like:
> 
> <many>
>    <domain name="example.com"/>
>    <except>
>      <entity id="[email-masked]"/>
>    </except>
> </many>
> 
> this is useless but well defined based on the logic I suggest 
> above; it 
> would always be identical to:
> 
> many>
>    <domain name="example.com"/>
> </many>
> 
> > It expresses the rule validity period by two
> >    attributes, a starting and a ending time.  Times are 
> expressed in XML
> >    dateTime format.
> 
> you don't actually express the matching rule, though its obvious. The 
> rule is this:
> 
> The validity condition is true if the current time is greater than or 
> equal to at least one <from> child, but less than the <until> child 
> after it. This represents a logical OR operation across each 
> <from> and 
> <until> pair.
> 
> 
> Thanks,
> Jonathan R.
> 
> 
> 
> 
> 
> Tschofenig, Hannes wrote:
> 
> > hi all, 
> > 
> > based on the recent discussion and the input provided by 
> martin i have
> > compiled another version of the common policy document. 
> please find it
> > at http://www.tschofenig.priv.at/TEMP/geopriv
> > 
> > ciao
> > hannes
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> 
> -- 
> 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
> 

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