Subject: AW: AW: [Geopriv] common-policy update

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 12 Oct 2005 22:43:58 +0200

hi henning, 

> > the discussion is missing because we need to re-read the 
> discussion to
> > make sure that we capture all the issues. 
> 
> This discussion probably needs to involve SIMPLE; I'm not 
> sure all the 
> interested parties hang out in this neighborhood.

that's correct. 
we should ask them for review. 

> If I recall, issues 
> included:
> 
> - Do we want to support things like tel:+49  (for all German 
> callers or 
> tel:+1-2*1-555-1212 for all callers in the 201, 212, 222, etc. area 
> codes); I think the consensus was that we'd skip this for now.
> 
> This implies that <many domain="+49">, for example, would not be 
> supported. I don't think this restriction requires a change 
> in the text 
> as you have it.

it does not require changes but maybe it would be good to state what the
non-goals are. 
in our discussions we said that only equality matching for the tel uri's
is support. 
i think that this has not changed. 

> 
> - What does the tel URI mean, in terms of protocol? Does this imply a 
> SUBSCRIBE, say, of
> 
> From: tel:+1-212-555-1234
> 
> (with some appropriate, but unspecified, authentication identity.)

that's a good question but probably something that we do not have to
give an answer for since the common-policy is very generic about this
issue anyway.  

> 
> 
> Also, 7.1.3.2 should probably be re-labeled since it describes 
> exceptions (except id=) that are individual identities, not 
> whole domains.
that's correct. i will fix it. 

suggestion:

"
Matching with Except Statements
"

> 
> 
> 
> > i think we also need to add something regarding the iana 
> registration. 
> 
> Probably. Schemes are already registered; what else were you 
> thinking of?

we haven't said what scheme's are already supported and where the
registry for these terms is. how does someone add a new scheme? 

btw, in one of the examples we use:
"
<one id="[email-masked]" schema="sip mailto xmpp"/>
"

the scheme attribute contains a list of registered schemes. that's ok
for me but requires parsing through the value of the scheme attribute. 

do we use the same mechanim for the value attribute of the sphere
element? 
since we the child elements of the <condition> element are matched using
a logical AND you cannot have more than one sphere element in the rule.
(the same is true for the other elements as well but only the sphere
element does not allow multiple values to get listed.)

the question therefore is: do we allow something like: 

"
      <sphere value="home work" />
"

ciao
hannes

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Oct 2005 16:59:49 -0400

> i think that this has not changed. 

Agreed.

> give an answer for since the common-policy is very generic about this

I suspect it wouldn't hurt to have a sentence about this, in general; 
without this, it's hard to implement any of this. This would likely be 
at the "for example" level.

> Matching with Except Statements

Matching all except users certain domains and identities?

> registry for these terms is. how does someone add a new scheme? 

Essentially, any scheme with a user notion should work. I don't think 
we'd want to have each new IM/presence/signaling scheme to have to 
register, if they already have a URI scheme.

> for me but requires parsing through the value of the scheme attribute. 

Other proposals have been made, such as
<one id="[email-masked]" scheme="sip">
<one id="[email-masked]" scheme="xmpp">

This is simpler, but a bit wordier. I don't know how often people will 
actually enumerate schemes in practice (I suspect the number will be 
rather small, but that's no more than a hunch).

>       <sphere value="home work" />

You can always make up separate rules for each sphere, so this only 
makes the presentation slightly more compact, but doesn't add new 
functionality.

I'm a bit worried about the additional complexity of supporting nesting 
inside various elements. Once you start doing that, a consistent design 
would argue for doing it for every element, not just one here and there.

It's not just the extra XML parsing, but adding enumerations 
complicates the user interface since you now have to explain another OR 
condition to users.

Henning