August 2005 IETF63 - SIPPING 1

Recommended Relationships between Different Types of Identifiers

draft-schulzrinne-sipping-id-relationships-00

Henning Schulzrinne (Columbia U.)Eunsoo Shim (Panasonic)

eunsoo@research.panasonic.comhgs@cs.columbia.edu

August 2005 IETF63 - SIPPING 2

Overview

• No public directory deployed or likely

• Often, only partial information available– e.g., auto-addressbook in mail user agents

• Set of user@domain-style identifiers– SMTP (RFC 2821)– SIP– XMPP– (also NAI: RADIUS and DIAMETER)

August 2005 IETF63 - SIPPING 3

Motivation

• User experience: Users think of addresses like alice@example.com, not sip:alice@example.com or mailto:alice@example.com

• Authentication: single sign-on identifier– also allows easy SIP account creation– create sip:alice@example.com; password mailed to

alice@example.com

• Spam prevention: use earlier email exchange as white list for SIP– “I have sent email to bob@example.com, so I’m accepting IM

from sip:bob@example.com”

• Problem: No clear guidance on identifier creation and relationships

August 2005 IETF63 - SIPPING 4

Core recommendations

• User MAY choose same user name across URIs within same domain– or stronger: Provider SHOULD assign same user part

across URI schemes

• Providers SHOULD NOT assign the same user id in different URI schemes to different people

• SIP URIs SHOULD have a working email equivalent– motivation less clear (not necessary for voicemail)– useful for initial sign-up in some scenarios

August 2005 IETF63 - SIPPING 5

Open issues

• Mapping of tel URIs to email and SIP URIs – primarily issue of separators– ignore all separators (all equivalent) OR– specific recommendation of usage

• Is this useful enough as a BCP or Informational?