Subject: Re: [Sipping] draft-ietf-sipping-e164-00.txt

From: [email-masked]
Date: Fri, 7 Dec 2001 11:28:30 EST

In a message dated 12/6/01 5:45:51 PM Eastern Standard Time, 
[email-masked] writes:

> Hi,
>  
>  Just to make sure people realize, since there was quite a bit of
>  feedback over this draft submission, that this was not a new draft.
>  Rather, it is a minor update incorporating feedback from a working group
>  last call. It became a 00 draft again because was renamed to reflect its
>  status as a SIPPING wg item. Since most of the new feedback seems not to
>  concern changes since the last called version, I am not quite sure how
>  to proceed. Perhaps the chairs would like to comment? (This is not to
>  pick on Mike; there were several people who responsed. More in fact than
>  did in the actual last call.)
>  
>  In any case, my responses to your actual comments are inline:
>  
Thanks for responding. Yes, it's always a problem when new people/comments 
are made. This has always been something to deal with in organizations that 
change participants over time. As a draft progresses through the process 
(e.g., becomes a WG draft) it naturally opens it to wider scrutiny, 
especially since many don't have the time to carefully review every 
individual draft that initially gets submitted.

I didn't intended to raise new technical issues - only to question things 
that I can't understand based on my 20+ years of experience in telephony 
standards for the PSTN. I believe the intent is to produce an RFC which can 
be understood by those outside of the IETF who have the same type of 
experience that I have.

>  On Mon, 2001-12-03 at 18:55, [email-masked] wrote:
>  > My comments on draft-ietf-sipping-e164-00:
>  > 
>  > Nits: There are a number of places in this draft where there is a 
paragraph 
>  > with extra indentation, some of which appear at first as if they intend 
to 
>  > indicate that the indented paragraph is quoted from some other place 
such as 
>  > RFC  2916. Unless there is a specific reason for this indentation, which 
>  > needs to be made clear, this extra indentation needs to be removed.
>  
>  Usually that is intended to reflect additional descriptive, explanatory
>  text, or otherwise non-normative text. It is a common practice in I-Ds.
>  Of course, it is always possible that there is a formatting problem that
>  does not render on my computer, so if you see a specific location that
>  does not reflect this usage, please let me know.
>  
I understand that this is a common practice, but it is not defined as part of 
the formatting standards for RFCs or used in all cases. I thought that the 
use of the key words (like SHOULD) took care of this. In any event, I don't 
see the distinction between, for example, the indented paragraph in Section 4 
and the non-indented ones in Section 9.
>  > 
>  > Confusion is caused in Section 4 by describing sip URLs as containing 
e.164 
>  > numbers and the example:
>  > 
>  >     sip:[email-masked];user=phone
>  > 
>  > In E.123 (referenced in E.164), + indicates (in written phone numbers) 
that 
>  > an international prefix is required. It therefore indicates that what 
follows 
>  > is a standard international phone number, i.e., begins with the country 
code 
>  > and is globally unique (or "globally-scoped").
>  > 
>  > After saying that "both examples describe a globally-scoped telephone 
>  > number", the draft goes on, correctly, to say that this representation 
of the 
>  > phone number for SIP is "locally-scoped", since it contains a host name, 
and 
>  > that a UAC "should not use a DNS query to resolve a number". It is true 
that 
>  > the number can only have a meaning within the confines defined by that 
host. 
>  > (It may very well be the same string as a globally-scoped phone number 
or a 
>  > portion of it without the country code, but as far as we are concerned, 
that 
>  > is coincidental. Only the designated host knows how to interpret the 
number. 
>  > It could be a private number that just happens to look like a global 
e.164  
>  > number.)
>  
>  It seems to me you are confusing the idea of phone number scope with
>  domain name scope--they are not the same thing. For example,
>  "sip:[email-masked];user=phone" would be interpreted
>  differently depending on whether the element doing said interpretation
>  was "example.com" or something else. An element that is not responsible
>  for the "example.com" domain should not attempt to interpret the user
>  part of the URL. It doesn't matter whether the user part is
>  "+1234567890" or "dontreadme". Only an element responsible for
>  "example.com" has any business making that interpretation.
>  
>  Now, if the element is indeed responsible for example.com, it gets to
>  interpret the user part. In this example, we have hinted to example.com
>  that we intended the user part to be a phone number, and by using the
>  "+" prefix, we have told example.com that the number is globally
>  routable.
>  > 
This is exactly the point and, I believe, the source of confusion that has 
lead to a number of comments. The originator can not "hint" at the way the 
url should be interpreted. Only the receiving element responsible for the 
specified domain can know how to interpret it (and must define the format). 
As you said above, the example given "would be interpreted differently 
depending on whether the element doing the interpretation was 'example.com' 
or something else". (Actually, another element besides example.com can't 
interpret it.) That means that the phone number portion is not globally 
scoped, so should not be shown with a "+". I think all examples of a SIP: url 
should be with something like "SIP:[email-masked]", not something 
that looks like an e.164 number. A specific host could define its format to 
be exactly like an e.164 number, but that's outside this spec.

Part of the confusion is regarding the use of the "+". Draft-ietf-isup-03 
seems to indicate that the "+" indicates a global number (even when the 
number precedes someones host name). It also seems to indicate that the 
"user=phone" is only needed when the "+" is not present (since the "+" 
somehow means "phone").

I think the other text makes it clear that the host (example.com) could 
define the format of the stuff before the "@" any way it wants. It could use 
a leading "+" to mean anything (although this may be dumb). Or has the use of 
"+" in the SIP: url been mandated to mean that an e.164 number follows? I 
don't think so. If it was, then the two examples do in fact refer to the same 
phone number.

I know there has been a lot of discussion on this issue of the SIP: url in 
relation to a number of drafts. Somehow, it needs to be resolved and 
explained in one place.

(An additional NIT: The examples should show legitimate e.164 numbers. Any 
number starting with +1 must then be followed by exactly 10 digits and an 
assigned area code. draft-ietf-isup-03 uses +17208881000.)

>  > It would seem that the example of a telephone number for sip:... in 
>  > draft-ieft-sipping-e164 should not include the "+" before the number. In 
>  > fact, the part before the @ symbol could consist of any legitimate 
string of 
>  > characters known to the host, certainly including letters.
>  > 
>  See above.
>  
>  
>  > The statement that "both examples describe a globally-scoped telephone 
number 
>  > (i.e. E.164 number)" should be worded to say:
>  > 
>  >     The first example describes a globally-scoped telephone number 
(i.e., 
>  > E.164 number). The second example describes a telephone number which is 
>  > locally-scoped within the domain of the designated host. It may be a 
private 
>  > number or a portion of the E.164 number or it may be equivalent to the 
E.164 
>  > number.
>  > 
>  > Further, the statement in Section 6 "If the e.164 number was received 
[by a 
>  > proxy] as part of a sip URL..." causes confusion, since, by definition, 
the 
>  > sip URL does not contain an "e.164" number, or at least, it is not known 
that 
>  > it does. If anything, the statement should be something like the 
following to 
>  > remove the reference to e.164:
>  > 
>  >     If the Proxy receives a sip URL and the domain portion does not 
refer to 
>  > a domain owned ... 
>  
>  The second version may be simpler, but it seems to make normative
>  statements about SIP behavior that is beyond the scope of this draft.
>  
Regardless of the technical issue, the comment was mostly driven by reading 
the words and trying to parse them. The statement in Section 4 is "both 
examples describe a globally-scoped telephone number", but then goes on to 
explain how, in the second example, only the designated host knows how to 
interpret the number, since it is locally-scoped (regardless of the "+" being 
used).

>  > 
>  > In Section 7, it is unknown what the references to "DID call" and 
"post-dial 
>  > digit strings" mean. For "DID", the gateway (and everything else) just 
sees a 
>  > normal e.164 number. (The term "DID" should disappear from the 
descriptions. 
>  > It really only refers to the signaling arrangement between central 
offices 
> 
>  > and PBXs.) For "post-dial" cases, the post-dial digits are never part of 
the 
>  > e.164 number.
>  
>  The terms were used as examples only in an explanatory (indented)
>  paragraph, and were not intended to be normative text. Would it make
>  things clearer to add a "For example,..." phrase to the offending
>  sentence?

I understand these were intended as examples, but the comment was based on an 
understanding that they are not legitimate examples with relation to 
interworking with the PSTN. The interworking this draft is dealing with is 
from e.164 numbers. If a DID function exists at the ultimate destination, 
nothing before the final PSTN switch knows anything about it. It is simply an 
interface arrangement between the final central office and a PBX. The gateway 
at the PSTN to SIP point somewhere before this certainly doesn't deal with 
this. Post dial digit strings are, by definition, after the complete e.164 
number, therefore, this is not a legitimate example. I think good examples 
would be: "A gateway might be able to construct the e.164 number from the 
dialed number in the case of private or local dialing plans. For example, it 
might map a private number into an equivalent global e.164 number or it might 
add the country code and area code to a locally dialed number." These 
examples then lead directly to the statement about use of "e164.arpa".
>  Thanks!
>  Ben.

Mike Pierce

_______________________________________________
Sipping mailing list  http://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: Ben Campbell <[email-masked]>
Date: 07 Dec 2001 11:11:47 -0600

On Fri, 2001-12-07 at 10:28, [email-masked] wrote:

[snip]

> be exactly like an e.164 number, but that's outside this spec.

Well, actually, you _can_ hint at the way a URL should be interpreted.
The user=phone parameter is in fact such a hint. Nothing says that
example.com has to honor the hint, but the hint might be useful to
example.com if it chooses to do anything with it. The point I was trying
to make is the idea of a "globally scoped PSTN number" is only
meaningful in the PSTN. Scoping of a URL (that cound coincidentally
carry a phone number) is an entirely orthagonal concept. The example
"sip:[email-masked]" (notice the +1 followed by 10 digits this
time :-) ) carries two such hints: that the user meant this as a phone
number, and said phone number is globally routable (from any point on
the PSTN). If example.com chooses to interpret the number as a phone
number it may also assume that the number can be reached from anywhere
on the PSTN. Of course, it can make those assumptions anyway; the use of
the hints is a matter of local policy.

Now, once that example.com knows it is in possesion of a globally
routable number, it could place a PSTN call from anywhere in the world
and reasonably expect it to go through. Or it could do a DNS lookup and 
redirect it to the resulting URL. Without the + sign, it _might_ be able
to decide the number is globally routable by the form of the number, or
it might be able to construct a globally routable number using some
additional information it just happens to have. But if the number does
not contain the +, and example.com cannot determine through some other
process that the number is globally routable, then it can't do these
things. (It could try, but it has no reasonable expectation of correct
results.)

> "user=phone" is only needed when the "+" is not present (since the "+" 

Hmm, I will have to track that down before responding to this point. It
seems a very bad idea to me; I should to be able to have a URL of
"sip:[email-masked]" without making any assertions about
phone numbers if I choose to do so.

> don't think so. If it was, then the two examples do in fact refer to the same 

If example.com chooses to interpret the URL as containing a phone number
at all, then they are the same phone number. The + does (or should) not
mandate a phone number. If example.com chooses to interpret it as such,
then the + means it is globally routable.

> relation to a number of drafts. Somehow, it needs to be resolved and 

Agreed, but I don't think this draft is the place for it. If we want to
make global assertions about URL interpretation, it should be in the SIP
spec.

> examples then lead directly to the statement about use of "e164.arpa".

Agreed, that seems to be a better wording.