Subject: URGENT: SIP ABNF

From: "Buller, Jim" <[email-masked]>
Date: Thu, 20 Aug 1998 18:13:25 +0100

----------
Thanks for your careful reading; let us know if you find anything else.

Ladies and Gentlemen,

Apologies for the URGENT header but I realize most if you shall be 
making your way towards Chicago in the next few days and thought
the contents of this mail may be of interest.

Having had a little more time to implement our parser now we have 
found what could be possible conflict scenarios with the userinfo 
field and the two kinds of  "user"; user name and telephone number
within (draft-ietf-mmusic-sip-08.ps of 7th August). 

At present, the SIP ABNF is "closely related" to that shown in RFC
2396 (URIs). This does not distinguish user names from telephone 
numbers (indeed, the telephone number form is not shown at all).

In the present draft, this discrimination between user forms is driven 
by the user-param element. The current proposal from the SIP draft 
is that one can discriminate between the two forms by the presence 
(or absence) of the "user=phone" user-param i.e. the "user=phone" 
user-param means that the user portion of the associated SIP-URL 
should be interpreted as a telephone number.

However, the following comment, "The phone identifier is to be used 
when connecting to a telephony gateway", on page 22 of the SIP 
draft implies that the user-param should be taken as an indication 
of the ->service<- to be performed i.e.  that of connection to a 
telephony gateway.

This implies an overloading of the user-param i.e. an indication 
of the interpretation of the characters making up the userinfo portion 
of the SIP-URL, PLUS an indication of the service to be provided. We 
suggest that in fact, we MAY need both.

As an example here's a scenario in which the separated service and 
format identifiers could be used: 

      a SIP Invitation has its intended correspondent shown as
      "sip:[email-masked];user=phone". The intention of the 
      requestor is that he or she wants to make a call to the 
      person identified as "mary.jones" via an Internet telephony 
      gateway; he or she wants to call mary jones over her
      telephone rather than use an Internet Telephony link. IFF 
      the SIP server has some means of mapping from 
      "[email-masked]" onto an associated telephone 
      number (for example by using an LDAP personal record) 
      then the request can be processed.

In the case of PINT, a request would not include the "telephony
gateway" service identifier (user=phone), but it might well include a 
telephone number in their request.

In summary, to improve clarity within the BNF, we would suggest that
the user-param should be used only to identify the service. 

The addition of a new token called "user-name" and a couple of small 
alterations (shown below) could then be used to identify the type of the

user part ( telephone | user-name)

userInfo = 
  user
  [ ":" password() ]

user = telephone_subscriber | userName

userName = 
  [ // Note! no initial first '-' or '+'
  (unreserved_without_minus | escaped | "&" | "=" | "$" | ",")
  *(unreserved_without_minus | escaped | "&" | "=" | "+" | "$" | ",")  
  ]

telephone_subscriber = 
  global_phone_number | local_phone_number

global_phone_number(SIP_URL holder) = 
  "+"
  ( phonedigit )+
  [ isdn_subaddress ]
  [ post_dial ]

local_phone_number = 
  "-"
  ( phonedigit | dtmf_digit | pause_character )+
  [ isdn_subaddress ]
  [ post_dial ]
}

The user-name form is restricted so that it cannot begin with either 
a "+" or "-" character.

This would provide a clear distinction between a user name and 
telephone number, and means that we now have a "format-identifier" 
embedded into the sip-url. Thus, with these changes, SIP can now both 
encode a telephone number as a uniquely distinguishable element, 
AND use the existing user-param to indicate the type of service 
required.

Hoping you find this information useful.

Kind regards,

Jim Buller and Lawrence Conroy

p.s. Minors :

Page 21

url-parameters is defined as 0 or more :

";" url-parameter

this means it is feasible for more than one ttl or maddr specification.
The one item 
we can perceive as  perhaps requiring this multiplicity is other-param
perhaps
this could be highlighted in the text.

Page 96

Line beginning :
 ;maddr=239.128.16.254 16;ttl=16

Is this a typo? Does the 16 refer to the ttl and should the ' 16'
therefore be 
removed?

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Aug 1998 17:01:38 -0400

Buller, Jim wrote:

> of the ->service<- to be performed i.e.  that of connection to a

That interpretation was not (my) intent. It always seemed rather
far-fetched that a host would need the 'user' parameter to begin with.
It was only intended for the (rare) case that a server

- can do both regular forwarding and gatewaying to the PSTN
- and has users whose names start with + or a number.

>       then the request can be processed.

I'm a little uncomfortable with expressing service requirements as part
of URLs, as their expressiveness is somewhat limited. Wouldn't it be a
better idea to either express the service desired as

- an Accept-Service: phone ;q=0.9, speech-to-text ;q=0.1 or
Call-Disposition: gateway

newly-defined definition (don't take the syntax too seriously)

or as a richer set of SDP descriptions? You might want to express things
like

"reach her by audio through either the phone (if it doesn't cost more
than $0.10/min) or by Internet (if packet loss is less than 10%) or by
text chat (if none of the above). For video, always use the Internet".
or "first try IP phone, then telephone, then pager". 

A better solution to the current simple scenario is, in my opinion, to
have the server return a list of explicit location headers, as in

Location: sip:[email-masked] ;class=... (this is her gateway number)
Location: sip:[email-masked] ;class=ip  (this is her IP telephony
connection)

and let the caller choose explicitly? 

These additional Location parameters are suggested in the current call
control spec.

> telephone number in their request.

It would also have an SDP description that lists a phone # as the
destination of media, not an IP address.

> this means it is feasible for more than one ttl or maddr specification.

An ABNF cannot easily express the fact that you can only have one
instance of each parameter. (Just like a syntax specification for a
language can't express the fact that "int x, x;" is not valid C.) The
specification gets rather more complicated if you try to express this, I
think, as you would have to say something like

url-parameters = [";" maddr-parameter] [ ";" ttl-parameter ] ...

which also implies an ordering.

> Is this a typo? Does the 16 refer to the ttl and should the ' 16'

Yes, a typo. Fixed.

-- 
Henning Schulzrinne         email: [email-masked]
Dept. of Computer Science   phone: +1 732 949 8344 (at Bell Labs)
Columbia University         fax:   +1 212 666-0140
New York, NY 10027          URL:   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Aug 1998 18:19:02 -0400

Henning Schulzrinne wrote:

> - and has users whose names start with + or a number.

Right. Basically the problem is that there is no way to know whether the
user-param was formatted based on the telephone subscriber BNF, or
email-like BNF. This tag was basically letting you know which. Whether,
once you've parsed it, you choose to execute gateway service or not, is
a different story, I agree. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen