Subject: Re: [IPTEL] Comments on RFC2806bis

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 May 2002 19:27:47 -0400

Yu, James wrote:
> Henning,
> 
> Don't know whether anyone has caught this:
> 
> In Section 4 related to "phone-context=":  change "domain" to "domainname"
> or vice versa on the next line.

Fixed in the upcoming -04. 
(http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-04.txt)

> 
> Also [11] should be 
> [11] J. Yu, "Extensions to the "tel" and "fax" URLs to Support Number
> Portability and Freephone Service," Internet Draft, Internet Engineering
> Task Force, March 1, 2002.  Work in progress.

Fixed.

> 
> Apparently, that I-D's title needs to be changed (e.g., removing "fax" URL).
> A revision will be submitted to reflect the changes based on RFC2806bis.
> 
> James

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 20 May 2002 14:04:26 -0400

> (http://www.cs.columbia.edu/~hgs/sip/drafts/draft-antti-rfc2806bis-04.txt)

The "*other" part of the global-number and local-number productions seem to have
been replaced with "*param" in "telephone-uri", however Section 5.3 still talks
about "<other>".

Question regarding naming of the "other" parameters:    Is the "m-" a prefix that
can be added to any extension parameter, or must an extension parameter be defined
and registered with an "m-" prefix from the start ?

Nit comments:
==========
Section 5.1.2:    "as as" => "as"

Section 5.3:    "in the BNF" = "in the ABNF"

Section 6:    "human- readable" => "human-readable"

Section 7.2:    `Telephone" => "Telephone" (first double-qoute formatting)

Thanks

        Flemming

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 20 May 2002 22:43:21 -0400

> been replaced with "*param" in "telephone-uri", however Section 5.3 still talks

Oops; fixed.

> and registered with an "m-" prefix from the start ?

My intent was to register it with the m- prefix from the start. I think 
it would complicate parsers if they had to worry about the same 
parameter having two names. Can you envision that the same parameter 
sometimes will be required, sometimes be optional? To me, that type of 
parameter probably assumes too much about knowing the receiver.

> Nit comments:

Thanks!

Henning

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 21 May 2002 07:48:36 -0400

> parameter probably assumes too much about knowing the receiver.

You can probably argue both ways on that, but I don't feel strongly about it. It leads
to the next question though, which is really for James: Will the yu-tel-url parameters
be prefixed with "m-" ?

Thanks

        Flemming

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 May 2002 08:17:33 -0400

> to the next question though, which is really for James: Will the yu-tel-url parameters

I actually changed from o- to m- because of James' draft. He claimed 
that all "his" parameters were optional and he didn't want to change his 
parameter names.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 21 May 2002 08:42:50 -0400

> that all "his" parameters were optional and he didn't want to change his

I must be missing something then. How can a CIC code and a routing number be optional ? Are
you saying you can just ignore carrier selection and route ported numbers to the old
exchange ?

-- Flemming