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

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 12 Oct 2005 22:36:59 -0500

Below...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Henning Schulzrinne
> Sent: Thursday, 13 October 2005 7:00 AM
> To: Tschofenig, Hannes
> Cc: [email-masked]
> Subject: Re: AW: AW: [Geopriv] common-policy update
> 
<snip>
> 
> >
> > 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.
> 
> 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).
> 

I can give you a couple of examples where your hunch is unlikely to hold up.  I can name two large organizations that unify identities in that fashion, I suspect that the following is more likely:

<one id="[email-masked]" scheme="mailto sip"/>
<one id="[email-masked]" scheme="mailto xmpp"/>

I'd say that more organizations will attempt to get the point where this sort of consolidation is possible - it's the obvious behaviour.

> >
> > 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" />
> > "
> 
> 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.

I prefer Hannes' suggestion, removing the ability for multiple values.  It's more of a consistency thing than any idea of aesthetics.  You should then restrict sphere to one instance only and then there is no further explanation required.  In terms of parsing, XML Schema aware parsers have to be able to handle such lists; it’s an XML Schema primitive if you want to get technical - it's actually an XML primitive: "NMTOKENS".
------------------------------------------------------------------------------------------------
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]

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Oct 2005 09:45:21 -0400

> I can give you a couple of examples where your hunch is unlikely to
> hold up.  I can name two large organizations that unify identities in
> that fashion, I suspect that the following is more likely:
> 
> <one id="[email-masked]" scheme="mailto sip"/> <one
> id="[email-masked]" scheme="mailto xmpp"/>
> 
> I'd say that more organizations will attempt to get the point where
> this sort of consolidation is possible - it's the obvious behaviour.

Sure - we even have a draft that suggests that organizations *should* do 
this.

However, I think in most cases, we'll see the unadorned id, i.e., "any 
(supported) protocol that follows the user@domain pattern".

It would be a real pain if everyone had to update all their rules just 
because the corporate presence system has added, say, XMPP to their 
protocol selection. (And most users won't even know when this has 
happened, leading to frustration as in "But you're in my access list!".)

> I prefer Hannes' suggestion, removing the ability for multiple
> values.  It's more of a consistency thing than any idea of
> aesthetics.  You should then restrict sphere to one instance only and
> then there is no further explanation required.  In terms of parsing,
> XML Schema aware parsers have to be able to handle such lists; it’s
> an XML Schema primitive if you want to get technical - it's actually
> an XML primitive: "NMTOKENS". 

I guess we're agreeing. I'm not worried about the XML parser here.