[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] tel URIs in common policy



Henning Schulzrinne wrote: 
Paul Kyzivat wrote:

You have mentioned the desire to ignore the difference between sip and sips. This probably makes sense, at least most of the time. (But not always - you may only want to grant full access to your presence state, with sensitive info, over a sips connection.)

Also, schemes are more than just distinct namespaces. There are significant differences from scheme to scheme about how equivalence of names is defined. Tel URIs must be compared differently for equivalence than sip (user=ip) URIs. Separator characters must be ignored, and parameters must be properly compared. (e.g. phone-context).

I don't think there's any disagreement that E.164-style and user at host-style URIs are sufficiently different that treating them as the same space is not likely to be productive or intuitive.

Just as sip and sips URIs might be considered equivalent for purposes of identity equivalence, so may tel and sip/sips;user=phone. It seems many people prefer to use sip URIs for phone numbers, using whatever domain name is handy for them. This can cause a huge mess in determining equivalence. Technically one should not consider to sip URIs with different domains to be equivalent even if they both seem to represent the same phone number, and it gives me heartburn to suggest doing so, but pragmatically I think it must probably be supported. Specifically, I think all the following need to be considered equivalent:

    tel:+1-555-987-6543
    tel:+15559876543
    sip:+1(555)987.6543 at foo.com;user=phone
    sip:+15.55.98.76.543 at bar.net;user=phone

This seems like an item for the 'ID management' document to consider.

I'm not convinced of that. Especially given the reception in paris, I think that doc, if it goes anywhere, will end up being a best practices document focused on how managers of domains and applications manage the names they assign.

This is something entirely different. It is about matching rules.

If we don't get this right, people will end up not being able to set policy for callers without understanding how the caller is identified from each different device he uses. If you end up needing a call log to figure out how your callers are identified before you can authorize them, then the system will be nearly unusable.

I fully agree. This discussion is very much tied to the 'ID management' draft discussion. I'm on the "usability" hobby horse these days, but I think in general, these equivalences should be as consistent as possible. It is very confusing if two identifiers are treated the same in one context and then suddenly differ in another - unless there's some explicit "loose/strict" flag or other obvious indication.

They may both be related to usability, but I think they are otherwise different efforts.

We also talked last week about wildcarding. I think there will be demand/need for this. Things like:

    tel:+1-900-nnn-nnnn

Even this assumes that global form numbers are being used. Various forms of dial strings make more of a mess. But lets not discuss that for now.

How useful is this likely to be, at least for presence and access to geo information?

I guess that particular example may not be a good one, since I doubt I would ever receive a request where the caller address was a 900 number.
But other wildcards might make sense:

	tel:+1-978-936-nnnn

would cover all cisco business phones at my site. With a few similar numbers I could grant access to most cisco business phones.

Would we need to support the equivalent for domains, so that

domain="cisco.com"

matches

cisco.com
engineering.cisco.com
host17.engineering.cisco.com

[and other permutations]

I think we have to take those on a case by case basis. I don't think it generally makes sense to do that. There should be some explicit way to do it. E.g. domain="*.cisco.com" or domain="**.cisco.com".

	Paul

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple