RE: [Sipping] I-D ACTION:draft-elwell-sipping-identity-interworki ng-00.txt

"Francois Audet" <audet@nortelnetworks.com> Fri, 30 May 2003 18:02 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19196 for <sipping-archive@odin.ietf.org>; Fri, 30 May 2003 14:02:44 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UI2IV23703 for sipping-archive@odin.ietf.org; Fri, 30 May 2003 14:02:18 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UI2IB23700 for <sipping-web-archive@optimus.ietf.org>; Fri, 30 May 2003 14:02:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19189 for <sipping-web-archive@ietf.org>; Fri, 30 May 2003 14:02:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LoB7-0007CY-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 14:00:33 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LoB6-0007CV-00 for sipping-web-archive@ietf.org; Fri, 30 May 2003 14:00:32 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UHvjB23469; Fri, 30 May 2003 13:57:45 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UHuoB23434 for <sipping@optimus.ietf.org>; Fri, 30 May 2003 13:56:50 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19107 for <sipping@ietf.org>; Fri, 30 May 2003 13:56:45 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lo5p-0007B2-00 for sipping@ietf.org; Fri, 30 May 2003 13:55:05 -0400
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19Lo5o-0007Ay-00 for sipping@ietf.org; Fri, 30 May 2003 13:55:04 -0400
Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UHtsx23018; Fri, 30 May 2003 12:55:54 -0500 (CDT)
Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <LGT165SB>; Fri, 30 May 2003 10:55:54 -0700
Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D208BD27D0@zsc3c030.us.nortel.com>
From: Francois Audet <audet@nortelnetworks.com>
To: "'Elwell, John'" <john.elwell@siemens.com>, "'sipping@ietf.org'" <sipping@ietf.org>, 'Henning Schulzrinne' <hgs@cs.columbia.edu>
Subject: RE: [Sipping] I-D ACTION:draft-elwell-sipping-identity-interworki ng-00.txt
Date: Fri, 30 May 2003 10:55:51 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C326D4.B55F0E36"
Sender: sipping-admin@ietf.org
Errors-To: sipping-admin@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>

Hi John,

In the SIP BNF description in RFC3261, on page 223, it is stated 
that if the userinfo in the SIP-URI is a telephone-subscriber 
(as opposed to a user), then the telephone-subscriber BNF is 
defined in RFC2806. (Although not explicitely stated, I assume 
it also means that the "user=phone" user-param needs to be 
included). Perhaps Henning can confirm? 

The guidance I have described below is indeed when a
telephone-subscriber instead of a user (for the userinfo) is
used. I think it would be very useful to spell out that
type of guidance in the QSIG identity interworking draft.

Of course, it would also be doable to use the user instead of the
telephone-subscriber field in the userinfo. In that case, 
essentially any type of user@hostport format is allowed, and there
is not much guidance we can give. It then becomes a matter of 
converting phone numbers to SIP URIs. QSIG-Private/Level1=265-3756 could
be mapped to sip:2653756@foo.com, (or sip:audet@foo.com for that matter). 

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com] 
> Sent: Friday, May 30, 2003 06:52
> To: Audet, Francois [SC100:4K02:EXCH]; 'sipping@ietf.org'
> Subject: RE: [Sipping] I-D 
> ACTION:draft-elwell-sipping-identity-interworki ng-00.txt
> 
> 
> Francois,
>  
> Thanks for your comments. Concerning your point about 
> phone-context, I am not sure that this parameter is defined 
> for a SIP URI (as opposed to a Tel URL). The only reference I 
> can find in RFC3261 is an example at the end of 19.1.6. I 
> agree that your proposed use of this parameter might be 
> useful, but I am reluctant to propose anything without a 
> clearer indication that this is indeed a standard part of the 
> SIP URI. Any other opinions?
>  
> John
>  
> John Elwell - Technical Consultant 
> Tel: +44 (0)115 943 4989 
> Fax: +44 (0)115 943 4969 
> e-mail: mailto:john.elwell@siemens.com 
> <mailto:john.elwell@siemens.com>  
> web: http://www.siemens-design-services.com
> <http://www.siemens-design-services.com/>  
> 
> Siemens Communications 
> Technology Drive, Beeston, Nottingham, NG9 1LA.  England. 
> 
> "Siemens Communications - a division of Siemens plc,  
> Registered No: 727817, England. Registered office: Siemens 
> House, Oldbury, Bracknell, Berkshire, RG12 8FZ.
> 
> This communication contains information which is confidential 
> and may also be privileged. It is for the exclusive use of 
> the addressee. If you are not the addressee please note that 
> any distribution, reproduction, copying, publication or use 
> of this communication or the information is prohibited. If 
> you have received this communication in error, please contact 
> us immediately and also delete the communication from your 
> computer. We accept no liability for any loss or damage 
> suffered by any person arising from use of this e-mail."
> 
>  
> 
> -----Original Message-----
> From: Francois Audet [mailto:audet@nortelnetworks.com]
> Sent: 29 May 2003 20:23
> To: 'Elwell, John'; 'sipping@ietf.org'
> Subject: RE: [Sipping] I-D 
> ACTION:draft-elwell-sipping-identity-interworki
> ng-00.txt
> 
> 
> 
> Hi John, 
> 
> This is a very useful document. 
> 
> In any case, I've got a few comments: 
> 
> - I would like to see a mention of how to relate SIP URIs and 
> tel URIs 
>   for QSIG phone numbers by putting an explicit reference to section 
>   19.1.6 of RFC 3261. This could be somewhere in your draft, 
> perhaps in 
>   section 11.2.2. 
> 
> - There doesn't seem to be much guidance in your draft of how to 
>   indicate QSIG type of number information using the phone-context. 
>   This is precisely the type of thing that the phone-context was 
>   created to do for "local" numbers (i.e., within a private domain). 
>   For example, a enterprise foo.com might decide to use the following 
>   mapping for NPI/TON to phone-context: 
> 
>         NPI=Private ISO/IEC 11571, TON= phone-context= 
>       ----------------------------------------------------- 
>         level 2 regional number                 level2.foo.com 
>         level 1 regional number                 level1.foo.com 
>         local (level 0) number                  level0.foo.com 
>         PISN-specific number                    special.foo.com 
>         unknown number                          unknown.foo.com 
> 
>   Of course, an enterprise could choose to use a 
> phone-context of foo.com 
>   as the highest level of the phone number hierarchy, be it 
> Level 2 or Level 1. 
>   Also, the host could be diffent that the domain in the 
> phone-context: you 
>   could have foo.com in the phone-context and 
> serviceprovider.net as the host 
>   domain. Also, this is just an example: the idea is that the 
> enterprise 
>   would assign diffent phone contextes to different QSIG 
> types of number. 
> 
>   This would yield SIP URIs like 
>         sip:53756;phone-context=level0.foo.com@foo.com;user=phone 
>         sip:265-3756;phone-context=level1.foo.com@foo.com;user=phone 
>         sip:6-911;phone-context=secial.foo.com@foo.com;user=phone 
>   
>   This is probably something that should also go in section 11.2.2. 
>   
>   All this is very much in line with draft-antti-rfc2806bis-08. 
> 
> > -----Original Message-----
> > From: Elwell, John [ mailto:john.elwell@siemens.com
> <mailto:john.elwell@siemens.com> ] 
> > Sent: Thursday, May 29, 2003 07:38
> > To: 'sipping@ietf.org' 
> > Subject: RE: [Sipping] I-D 
> > ACTION:draft-elwell-sipping-identity-interworki ng-00.txt 
> > 
> > 
> > This document has been produced in ECMA, and comments of the
> > SIP community are invited prior to finalisation of the ECMA 
> > publication during the coming weeks. 
> > 
> > john.elwell@siemens.com
> > 
> > 
> > > -----Original Message-----
> > > From: Internet-Drafts@ietf.org [ mailto:Internet-Drafts@ietf.org
> <mailto:Internet-Drafts@ietf.org> ] 
> > > Sent: 29 May 2003 12:20
> > > Cc: sipping@ietf.org 
> > > Subject: [Sipping] I-D 
> > > ACTION:draft-elwell-sipping-identity-interworking-00.txt 
> > > 
> > > 
> > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories. 
> > > 
> > > 
> > >     Title           : User identification in a SIP/QSIG 
> environment 
> > >     Author(s)       : J. Elwell 
> > >     Filename        : 
> > > draft-elwell-sipping-identity-interworking-00.txt 
> > >     Pages           : 31 
> > >     Date            : 2003-5-28 
> > >     
> > > This document examines means of identifying or naming users of
> > > telephony services within an enterprise. Numeric names 
> > (numbers) are
> > > used in traditional Private Integrated Services Networks (PISNs)
> > > using QSIG as the network signalling protocol. They are 
> > also used for
> > > external communication, e.g., with a public Integrated Services
> > > Digital Network (ISDN). Names need not be numeric in Internet 
> > > Protocol (IP) networks employing signalling protocols such as the 
> > > Session Initiation Protocol (SIP). This document 
> therefore looks at 
> > > naming schemes that are appropriate within enterprise IP 
> > networks, in
> > > particular enterprise IP networks employing SIP as the signalling
> > > protocol. It also investigates naming schemes that are 
> > appropriate in
> > > a mixed QSIG/SIP enterprise network and the treatment of
> > names at an
> > > interworking point. It details the use of names not only for
> > > selecting a user to participate in a call, but also as a means of 
> > > identifying a user in a call to other users in that call. 
> ENUM and 
> > > private ENUM-like services are also examined. 
> > > 
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-elwell-sipping-ident
> <http://www.ietf.org/internet-drafts/draft-elwell-sipping-ident>  
> > ity-interworking-00.txt
> > 
> > To remove yourself from the IETF Announcement list, send a 
> message to
> > ietf-announce-request with the word unsubscribe in the body 
> > of the message. 
> > 
> > Internet-Drafts are also available by anonymous FTP. Login
> > with the username "anonymous" and a password of your e-mail 
> > address. After logging in, type "cd internet-drafts" and then 
> >       "get draft-elwell-sipping-identity-interworking-00.txt". 
> > 
> > A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>  
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>  
> 
> 
> Internet-Drafts can also be obtained by e-mail. 
> 
> Send a message to: 
>         mailserv@ietf.org. 
> In the body type: 
>         "FILE 
> /internet-drafts/draft-elwell-sipping-identity-interworking-00.txt". 
>         
> NOTE:   The mail server at ietf.org can return the document in 
>         MIME-encoded form by using the "mpack" utility.  To use this 
>         feature, insert the command "ENCODING mime" before the "FILE" 
>         command.  To decode the response(s), you will need 
> "munpack" or 
>         a MIME-compliant mail reader.  Different 
> MIME-compliant mail readers
> 
>         exhibit different behavior, especially when dealing with 
>         "multipart" MIME messages (i.e. documents which have 
> been split 
>         up into multiple messages), so check your local 
> documentation on 
>         how to manipulate these messages. 
>                 
>                 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft. 
> _______________________________________________
> 
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> <https://www1.ietf.org/mailman/listinfo/sipping>  
> This list is for NEW development of the application of SIP 
> Use sip-implementors@cs.columbia.edu for questions on current 
> sip Use sip@ietf.org for new developments of core SIP 
> 
>