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

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 22 Oct 2009 00:34:32 -0400

Ok, so how many laps around the rat hole do we have to take till we converge on a solution?

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Dean Willis <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Thu Oct 22 00:28:17 2009
Subject: Re: [dispatch] To-URI in domain-registration

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

> On Wed, October 21, 2009 9:28 pm, Spencer Dawkins wrote:
>> 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).
>
> 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
>
>
> 

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