Subject: [dispatch] To-URI in domain-registration

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Oct 2009 15:42:56 -0400

Howdy,
I'd like to get a consensus call on the question of what the To-URI should be for the REGISTER request of a domain registration, before finishing the next rev of the draft.  This will affect quite a bit of text in the draft (e.g., examples), and I think that the decision about that will also affect whether we need more than a Require:option-tag as well.

The choices right now are:
1) Mandate the To-URI be in the syntactical form of an AoR, including the user@ portion, the same as the From-URI.
	Pros: closer to what current proprietary and other-SDO mechanisms do, on the wire.  Therefore, presumably less of a change and less barrier to adoption.
2) Mandate the To-URI be a domain only (no user@), while the From-URI remains the "AoR" of the PBX registering.
	Pros: semantically accurate (you're registering a domain, not an AoR), and may obviate the need for a new header or param to indicate this new mechanism is being used.

Can people please indicate which they'd prefer?

Thanks!
-hadriel

---

From: "Brian Lindsay" <[email-masked]>
Date: Wed, 21 Oct 2009 15:53:10 -0400

Hi Hadriel,

    Per my comment yesterday, I'd prefer (1).

    Thanks.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Wednesday, October 21, 2009 3:43 PM
To: [email-masked]
Subject: [dispatch] To-URI in domain-registration

Howdy,
I'd like to get a consensus call on the question of what the To-URI
should be for the REGISTER request of a domain registration, before
finishing the next rev of the draft.  This will affect quite a bit of
text in the draft (e.g., examples), and I think that the decision about
that will also affect whether we need more than a Require:option-tag as
well.

The choices right now are:
1) Mandate the To-URI be in the syntactical form of an AoR, including
the user@ portion, the same as the From-URI.
	Pros: closer to what current proprietary and other-SDO
mechanisms do, on the wire.  Therefore, presumably less of a change and
less barrier to adoption.
2) Mandate the To-URI be a domain only (no user@), while the From-URI
remains the "AoR" of the PBX registering.
	Pros: semantically accurate (you're registering a domain, not an
AoR), and may obviate the need for a new header or param to indicate
this new mechanism is being used.

Thanks!
-hadriel
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Oct 2009 21:57:12 +0200

Hadriel,

I don't have a strong opinion either way, so in the interests of making progress on this important document I will go with the majority.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 21 October 2009 20:43
> To: [email-masked]
> I'd like to get a consensus call on the question of what the 
> To-URI should be for the REGISTER request of a domain 
> registration, before finishing the next rev of the draft.  
> This will affect quite a bit of text in the draft (e.g., 
> examples), and I think that the decision about that will also 
> affect whether we need more than a Require:option-tag as well.
> 
> 1) Mandate the To-URI be in the syntactical form of an AoR, 
> including the user@ portion, the same as the From-URI.
> mechanisms do, on the wire.  Therefore, presumably less of a 
> change and less barrier to adoption.
> 2) Mandate the To-URI be a domain only (no user@), while the 
> From-URI remains the "AoR" of the PBX registering.
> 	Pros: semantically accurate (you're registering a 
> domain, not an AoR), and may obviate the need for a new 
> header or param to indicate this new mechanism is being used.
>

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 21 Oct 2009 22:03:33 +0200

Hadriel,

I'd prefer option (1)

Cheers,
-Victor

-- 
Victor Pascual Ávila

---

From: "David Hancock" <[email-masked]>
Date: Wed, 21 Oct 2009 14:04:33 -0600

Hadriel - I'd prefer option 1) as well.

David

> Behalf Of Brian Lindsay
> Sent: Wednesday, October 21, 2009 1:53 PM
> To: Hadriel Kaplan; [email-masked]
> Subject: Re: [dispatch] To-URI in domain-registration
> 
>  Hi Hadriel,
>

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 21 Oct 2009 16:42:18 -0400

+1 to Option 1) as well

>  Behalf Of David Hancock
>  Sent: Wednesday, October 21, 2009 4:05 PM
>  To: Brian Lindsay; Hadriel Kaplan; [email-masked]
>  including

---

From: Bob Penfield <[email-masked]>
Date: Wed, 21 Oct 2009 16:56:01 -0400

I think option 2 is better because it is "do what I say" rather than "do what I mean". I would keep the option tag since it's an extension and requires different behavior in the registrar.

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: Wednesday, October 21, 2009 3:43 PM
To: [email-masked]
Subject: [dispatch] To-URI in domain-registration

Howdy,

Thanks!
-hadriel

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 21 Oct 2009 16:28:10 -0500

On Bob's post - I'm also assuming that we'll keep the option tag, for 
roughly the reasons Bob listed.

I believe Hadriel's question is intended to solve the question "how do I 
know that domain registration actually happened (as opposed to knowing that 
the other UA supports domain registration", raised on this list a couple of 
days ago - the guidance we got was not to rely on Requires as an indication 
that the extension was actually used).

Hope this is helpful...

Spencer

>I think option 2 is better because it is "do what I say" rather than "do 
>what I mean". I would keep the option tag since it's an extension and 
>requires different behavior in the registrar.
>
> cheers,
> (-:bob
>
>
> I'd like to get a consensus call on the question of what the To-URI should 
> be for the REGISTER request of a domain registration, before finishing the 
> next rev of the draft.  This will affect quite a bit of text in the draft 
> (e.g., examples), and I think that the decision about that will also 
> Pros: closer to what current proprietary and other-SDO mechanisms do, on 
> the wire.  Therefore, presumably less of a change and less barrier to 
> adoption.
> Pros: semantically accurate (you're registering a domain, not an AoR), and 
> may obviate the need for a new header or param to indicate this new 
> mechanism is being used.
>

---

From: Bob Penfield <[email-masked]>
Date: Wed, 21 Oct 2009 18:13:26 -0400

I understand that including the tag in a Require header does not mean that the UAS will apply that extension. However, if the UAS does apply the extension (if I understand the sentence below from section 8.2.4 correctly) it is suppose to include the tag in a Require header in the response.

   Any extensions applied to a non-421 response MUST be listed in a
   Require header field included in the response.  

So wouldn't that mean that the UAC can know for sure that 'dreg" was applied if the response has "Require: dreg"?

cheers,
(-:bob

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Wednesday, October 21, 2009 5:28 PM
To: Bob Penfield; Hadriel Kaplan; [email-masked]
Subject: Re: [dispatch] To-URI in domain-registration

Hope this is helpful...

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2009 18:56:14 -0400

> So wouldn't that mean that the UAC can know for sure that 'dreg" was applied if the response has "Require: dreg"?

I have always assumed that this means the response contains extensions 
that the UAC must understand in order to process the the response. E.g. 
extension headers in the response. I don't think it means what Bob is 
saying.

So, if the response has a "Domain-Registration: active" in the response 
to REGISTER, and the UAC needs to process that and do something as a 
result (rather than just ignore the header) then the tag in the response 
makes sense. But if the response looks identical to one where no domain 
registration occurred, then I think not.

	Thanks,
	Paul

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 22 Oct 2009 04:08:00 -0000 (UTC)

On Wed, October 21, 2009 10:56 pm, Paul Kyzivat wrote:
> Bob Penfield wrote:
>> I understand that including the tag in a Require header does not mean
>> that the UAS will apply that extension. However, if the UAS does apply
>> the extension (if I understand the sentence below from section 8.2.4
>> correctly) it is suppose to include the tag in a Require header in the
>> response.
>>
>> So wouldn't that mean that the UAC can know for sure that 'dreg" was
>> applied if the response has "Require: dreg"?
>

While that makes more sense than what the text actually says, I think Bob
is reading it correctly. Unfortunately, many of our options-tag-defining
extensions don't seem return the option tag in the response correctly.
This includes stuff I edited, like RFC 5373 (answer-mode),

Paul's idea that the response contains extensions that the UAC must
understand doesn't work, as the UAC has no way of rejecting a response
because it doesn't understand an extension. All it could do would be
discard-and-cancel, which is a bit awkward.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 22 Oct 2009 04:10:47 -0000 (UTC)

> less barrier to adoption.

If you do #1, then we need some clarity on what goes into the user portion
and how that affects authentication, etc. I suppose one could use a
"reserved" username (like "domain"), but we don't really have a registry
for that.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 22 Oct 2009 04:11:53 -0000 (UTC)

> I'd prefer option (1)

What's better about it? Is it just that it's easier to implement because
that's what you have already, or is there some sort of semantic advantage?

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 22 Oct 2009 04:18:35 -0000 (UTC)

> that the extension was actually used).

No, I think Hadriel's question goes more to "How does the registrar know
to do domain registration ratehr than AOR registration?" (at least that
was the question I asked that I think lead to this discussion).

If we go with #2, then it's easy:

If the "To:" of the request is a fully-qualifed SIP URI (an AOR), the
registrar does standard registration. If it's a naked domain, the
registrar does the new domain registration. This lets us later say "And if
it's a te;: URI, then do telephone registration", which could be a handy
extension for many people.

This is much better than using a Require option tag as a clue to engage
the new behavior. The Require is there to make registrars that don't
understand the extension fail the request instead of behaving in a
surprising manner when they try to process the faux-AOR.

--
Dean

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 21 Oct 2009 23:28:17 -0500

I must be incoherent - what Dean said is exactly what I was trying to say.

Require header field to actually require support, either domain-only To or 
some other header field to say that domain registration actually happened, 
and now we're talking about whether we key off domain-only To or some other 
header field.

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Oct 2009 09:16:34 -0400

Dean Willis wrote:
> is reading it correctly.

The quoted text says "Any extensions applied to a non-421 response". It 
doesn't say "applied to the request this response answers".

> Unfortunately, many of our options-tag-defining

Well, yes, that is all that could be done, but such is life.
If there is a disagreement between the two parties about what is to be 
supported that may be all that is possible.

Presumably the UAS doesn't apply something unless it believes the UAC 
will be able to support it, so this is the belt and suspenders approach.

Note that this is the situation for a textbook case such as 100rel. The 
response that actually includes something that must be processed (the 
reliable response with its headers) includes the Require:100rel, while 
other responses that *don't* contain such features do *not* contain the 
Require:100rel.

	Thanks,
	Paul

---

From: "Brian Lindsay" <[email-masked]>
Date: Fri, 23 Oct 2009 09:38:15 -0400

Hi,

    I think there is an aspect of backwards compatibility, with implicit
registration models, by using option (1). For example, with the existing
implicit reg model supported by PacketCable 2.0 (inherited from
3GPP/TISPAN), I believe one could setup implicit registration to
effectively register the domain.

    Regards
      Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Thursday, October 22, 2009 12:12 AM
To: Victor Pascual Avila
Cc: [email-masked]
Subject: Re: [dispatch] To-URI in domain-registration

What's better about it? Is it just that it's easier to implement because
that's what you have already, or is there some sort of semantic
advantage?

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Oct 2009 09:55:31 -0400

Along this thread, if we went with Option-1 to keep the To-URI looking like an AoR, the draft could say in fact that it really does Register that AoR in the normal Registrar AoR-Database, but that the Registrar would be provisioned to populate a Domain-Routing-Table based on the reachability info of the AoR (contact/Path).

But in my opinion the main advantage of Option-1 is really about reducing the implementation effort for IP-PBX's.  That's not a small thing, though I wonder how much effort it really is.

It's important to note, too, that Domain Registration is different from "implicit-registration" in the sense that it's not just a short-cut from registering all the phone numbers of the PBX separately.  The PBX is given a different domain, one for which it is authoritative for in the SIP sense.  All the language we have in RFC's around that applies, so that the PBX is responsible for its own AoR's and such.  It's really "peering" with the Service Provider, as opposed to being a multiple subscriber UA's of the service provider.

In that sense, I prefer Option-2, if for no other reason than it makes the vendors understand that this is not just implicit-registration a la 3gpp/tispan. (plus I think its semantically more accurate)

-hadriel

> Sent: Friday, October 23, 2009 9:38 AM
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Oct 2009 09:57:44 -0400

Right, I wasn't saying doing Option-2 of having only the domain in the To-URI would remove the need to do an option-tag.  But I think it would remove the need to have a new header or param. 

-hadriel

> should

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Oct 2009 10:09:14 -0400

Along this thread, if we decide that we need a new header as well as the option-tag, because we chose Option-1 of using a AoR in the To-URI, then I would suggest we fix this problem once and for all.  By that I mean submit yet another separate draft to create a new header called "Use-Extension" or some such, which is a list of option-tags to be used on the request/response it appears in, and an option-tag to go along with that draft to indicate support for that header.  

Not that I like the idea of another draft (or another header or option-tag for that matter), but it seems silly to create a header like "Domain-Registration: yes".

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sat, 24 Oct 2009 02:44:21 -0500

Hadriel Kaplan wrote:
> Right, I wasn't saying doing Option-2 of having only the domain in
> the To-URI would remove the need to do an option-tag.  But I think it
> would remove the need to have a new header or param.

I agree.

--
dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 24 Oct 2009 02:51:14 -0500

Hadriel Kaplan wrote:
> Along this thread, if we decide that we need a new header as well as
> the option-tag, because we chose Option-1 of using a AoR in the
> To-URI, then I would suggest we fix this problem once and for all.
> By that I mean submit yet another separate draft to create a new
> header called "Use-Extension" or some such, which is a list of
> option-tags to be used on the request/response it appears in, and an
> option-tag to go along with that draft to indicate support for that
> header.
> 
> Not that I like the idea of another draft (or another header or
> option-tag for that matter), but it seems silly to create a header
> like "Domain-Registration: yes".

This leads to the "named telco services" and the "service
identification" argument that consumed the WG for a couple of years.

See:

http://tools.ietf.org/html/draft-ietf-sipping-service-identification-03
and
http://tools.ietf.org/html/draft-drage-sipping-service-identification-03

--
Dean

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 26 Oct 2009 15:43:11 -0400

> correctly) it is suppose to include the tag in a Require header in the

If the request has a tag in a Require header, than if the UAS does not
understand the extension, the UAS will reject the request with a 421.
There is no generic requirement that the request will trigger the
mechanisms of the extension -- the presence of "Require" is orthogonal
to the question of whether the extension causes something interesting to
happen to the request.  In particular, if "Require" is missing, the UAS
will not process the request differently.

(However, if an option-tag is present with "Supported", the definition
of the extension may cause the request to be processed differently than
it otherwise would be.)

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 26 Oct 2009 16:34:20 -0400

> of the extension may cause the request to be processed differently than

Yuck -- what I wrote is what was intended by RFC 3261, but which is
violated by a few extensions, as Hadriel points out.

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Oct 2009 19:32:11 -0500

> violated by a few extensions, as Hadriel points out.

Yeah, but Bob was talking about the presence of a Require: option-tag  
in a RESPONSE, not a request. We seem to have violated that part of  
RFC 3261 even more frequently.

--
Dean

---

From: "Middleton, David (NSN - US/Boca Raton)" <[email-masked]>
Date: Fri, 30 Oct 2009 12:40:31 -0500

Some colleagues have pointed out an aspect that I had not considered concerning the domain registration To: user part.  There are cases where an Enterprise has multiple PBXs that register and calls should be routed to one of the PBXs based on which user is called.  In other words, instead of the Enterprise with multiple PBXs appearing as one logical PBX, the Enterprise customer wants the service provider to take responsibility for distributing the calls to the specific PBX that hosts the called user.

While this problem could be solved with a local policy to choose one of several contacts it is not as clean an approach as being able to treat each registration as a separate entity with it's own contact(s).  While one could propose that these be treated separately by making different sub-domains, the Enterprise most assuredly will not want to publish this sub-domain on business cards, etc. when using e-mail style addresses.  Besides, it would cause the address to change if the user moves from one PBX to another as might happen with a physical move.

Another aspect to consider is that the Enterprise user, in this scenario, is only reachable via one registered "To: user@host".  So not having separate registrations would result in a more complex definition and implementation of things like (a.) is there an unexpired binding and (b.) picking appropriate contacts by q-value.

I think this makes a strong case for having a user part in the To: header and treating each unique user@host as a separate registration à la RFC 3264.

In summary, I support Option 1) as well.

- David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Richard Shockey
Sent: Wednesday, October 21, 2009 4:42 PM
To: [email-masked]
Subject: Re: [dispatch] To-URI in domain-registration

+1 to Option 1) as well

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Oct 2009 19:37:17 -0400

David,

IIUC, you are proposing a case such as:

- a customer of sp.net has domain cust.sp.net
- the customer has two PBX systems, east and west.
- you propose that they register, respectively
   To: [email-masked], and
   To: [email-masked].
- then numbers assigned to the customer are routed
   something like:
   1-212-555-88xx -> contact from [email-masked]
   1-408-555-88xx -> contact from [email-masked]
- also, routing for names be something like:
   [email-masked]   -> contact from [email-masked]
   [email-masked] -> "
   [email-masked]   -> contact from [email-masked]
   [email-masked] -> "
   others...

Is that right?

You then can't describe that as setting up routing paths for 
cust.sp.net. You are instead describing some entirely different routing 
algorithm based on the user part.

Subdomains east.cust.sp.net and west.cust.sp.net solve this problem in 
large part - at least for the numbers.

You clearly don't find that acceptable for the names. If those names 
were exposed to end users I wouldn't find it acceptable either. (I want 
to be [email-masked], not [email-masked].)

The question is whether this is the best way to solve that problem.

I think that solution won't be very acceptable to an SP, or to the 
customer of that SP. Having the SP provision every one of your users 
just isn't going to be popular with anyone. (Unless the SP gets a big 
enough per-user fee.)

Its not quite as much of a problem with numbers, because they are likely 
to be managed in blocks. And the numbers are really owned/managed by the 
SP anyway so they are forced to do something about them.

This is also a problem that is not unique to this SP interconnect 
mechanism. It is pretty much the same problem in any big company with a 
lot of sites, even if they have a private network connecting all the sites.

What you need in this case is a proxy at the company domain level 
(cust.sp.net in this case perhaps) that has the roster of all usernames 
and a mapping to a subdomain - mapping [email-masked] to 
[email-masked].

Then, the company has one server registering To:cust.sp.net to provide 
this mapping, and other servers registering To:east.cust.sp.net, ...

	Thanks,
	Paul