Subject: RE: [Sipping] RE: Comments on draft-johnston-sipping-p2p-ipcom-01.txt

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 6 Apr 2005 15:44:32 -0400

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Henning Schulzrinne
>Sent: Wednesday, April 06, 2005 2:02 PM
>To: Eunsoo Shim
>Cc: sipping
>Subject: Re: [Sipping] RE: Comments on 
>draft-johnston-sipping-p2p-ipcom-01.txt
>
>Maybe you can start writing a draft describing the 
>relationships of the various identifiers (tel, sip, email) and 
>recommended practices. I'd be happy to contribute.
>
>Basically, I think the rules are roughly:
>
>- A SIP address MUST only have the same user and domain part 
>of an email address for the same person or service, not some 
>other individual or service.

Is this the same as saying:

Once a domain has assigned a user part to one individual, 
it MUST NOT assign that user part to any other individual.

If an individual with an assigned service in a domain is assigned 
a new service, that new service MUST also use the existing user part.

A domain MAY assign aliases for the user part, so long as they 
do not conflict with already assigned user parts.

Mike

[snip]

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 06 Apr 2005 15:57:36 -0400

> it MUST NOT assign that user part to any other individual.

At the same time; clearly, some domains can and do re-use email 
identifiers once an employee or student leaves, dies or stops the 
service. (I don't think that's a good idea and we rarely do this 
locally, but this is a higher-layer problem.)

> a new service, that new service MUST also use the existing user part.

Indeed; one can argue about SHOULD vs. MUST. We would need to identify 
the "safe" user names that work across known URIs. Future URIs are 
unlikely to be an issue, given better awareness of I18N issues.