Subject: [IPTEL] CPL-03 Comments and Questions

From: [email-masked]
Date: Mon, 6 Nov 2000 15:16:26 -0600

A few miscellaneous comments and questions on draft-ietf-iptel-cpl-03:

In Figures 2, 19, and 29, why doesn't the "location" node in the "voicemail"
subaction have a clear="yes" attribute? Without it, won't there often be two
locations in the location set when "redirect" is invoked?

Section 5.1.1: This section makes it sound like visual separators are
stripped from the tel subfield for tel URLs but not for sip URLs. Is that
the intention? 

Section 6: I don't suppose you'll want to be adding any new features, but
here is one that I think would fit in quite well: the ability to add a
location by modifying an address. Specifically, given an address in a
particular domain, create a new location which is the same address in a
different domain. For numeric phone numbers, this means stripping a prefix
and adding a new prefix.

Section 6.1: Should a default priority be defined?

Section 6.2: How does the source URL work? Is HTTP used to retrieve the
location URL from the source URL? How does the source URL get the
information that it needs to determine the location URL (does the CPL script
pass the addresses to the source URL)?

Section 6.3: "[Location removal] is primarily useful following a lookup
node": Could you provide an example of how this works?

Section 8.1.1, item (3): Why would the SIP From header of an incoming
message be used as the basis of the Reply-To URI?

Section 9: Should it say whether subaction names are case-sensitive?

Figure 29: Uses "address contains", but according to figure 4, "contains"
can only be used with the "display" subfield. Also, this script doesn't take
care of the "failure" case.

- Cliff Harris

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

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 13 Nov 2000 14:45:21 -0500 (EST)

> locations in the location set when "redirect" is invoked?

JR addressed this; the location's been removed by that point.

> stripped from the tel subfield for tel URLs but not for sip URLs. Is that

Nope; I corrected this.

> different domain. For numeric phone numbers, this means stripping a prefix

This seems like a fine extension, but I don't think it'd belong in the base
spec even if we weren't at last call.

> Section 6.1: Should a default priority be defined?

Yes; 1.0.  (I made this only SHOULD strength, though, since the server may
want to impose some policy here or something).

> pass the addresses to the source URL)?

I'll address this in follow-up to the subsequent discussions.

> node": Could you provide an example of how this works?

There's an example of this in Section 13.8 (Figure 24).  I've added a
forward reference.

> message be used as the basis of the Reply-To URI?

On the assumption that sip addresses and e-mail addresses often correspond.
It's a guess, but it seems more likely to be useful than the address of the
SIP server.

> Section 9: Should it say whether subaction names are case-sensitive?

Yes, it should (and they are).  Added.

> care of the "failure" case.

For the first point, fixed to "is".  For the second point, I added a note to
the discussion in section 13.11.  (Mind you, this discussion has gotten
largely lost in the text version; I think nroff may not be handling my
figures correctly.)

Thanks for your comments!

-- 
Jonathan Lennox
[email-masked]