Subject: Re: [sipcore] rfc4244bis: what is an AoR?

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jul 2009 17:46:47 -0400

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2009 8:19 AM
> 
> How does it matter whether there are multiple translation steps in a
> domain?
> What matters that if I sent something to: sip:[email-masked] that it
> will be delivered to the intended party. In this sense this is an AOR. I
> could put this on my business card for example.

I think part of the confusion (at least for me) is using the term "AoR" and a tag named "aor".  It's just not the cut-and-dried what is or is not an AoR, imho.  The rules by which systems change one URI to another URI can easily be viewed/described as performing a location-service lookup.  Just because a system implements those rules in a regex replacement, route tables, ENUM lookup, HSS lookup, or whatever, doesn't matter - they don't know when the URI they've changed it from was an AoR or not.  

I think what you guys are saying is "it doesn't matter" - all that matters is that a URI of a domain for which the proxy is responsible, which is used by that proxy for a location-service lookup, actually be tagged with "aor".  It's ok if that tags things which aren't "AoR's" in the classic sense, and thus more H-I entries are tagged than are really needed, because the UAS will ignore them.  Is that right?

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 16:56:36 -0500

Well, sort of.

But I can't think of cases where the tag "aor" would not be applied
to somthing that is not an AOR.

It is certainly true that not all AORs will be tagged.

In my mind, the tag meant "I recorgnize this as being the
AOR I'm responsible for, and that I'm using for the database dip".

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Wednesday, July 15, 2009 14:47
> To: SIPCORE
> Subject: Re: [sipcore] rfc4244bis: what is an AoR?
> 
> 
> 
> > What matters that if I sent something to: 
> sip:[email-masked] that 
> > it will be delivered to the intended party. In this sense 
> this is an 
> > AOR. I could put this on my business card for example.
> 
> I think part of the confusion (at least for me) is using the 
> term "AoR" and a tag named "aor".  It's just not the 
> cut-and-dried what is or is not an AoR, imho.  The rules by 
> which systems change one URI to another URI can easily be 
> viewed/described as performing a location-service lookup.  
> Just because a system implements those rules in a regex 
> replacement, route tables, ENUM lookup, HSS lookup, or 
> whatever, doesn't matter - they don't know when the URI 
> they've changed it from was an AoR or not.  
> 
> I think what you guys are saying is "it doesn't matter" - all 
> that matters is that a URI of a domain for which the proxy is 
> responsible, which is used by that proxy for a 
> location-service lookup, actually be tagged with "aor".  It's 
> ok if that tags things which aren't "AoR's" in the classic 
> sense, and thus more H-I entries are tagged than are really 
> needed, because the UAS will ignore them.  Is that right?
> 
> -hadriel
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jul 2009 18:51:11 -0400

> AOR I'm responsible for, and that I'm using for the database dip".

I think I agree with Francois, but that definition is circular.

I'm saying "its an AOR if somebody from its domain *says* its an AOR."

But I don't think thats enough - I've seen too many cases when people 
are willing to assert things that make no sense. If you just got an 
address from DHCP, then you had better not assert that some URI 
containing that is an AOR.

I think the meaning of the URI needs to be stable over some reasonably 
long period of time before it qualifies as an AOR. But the meaning of 
"meaning" is also a bit squishy there. It doesn't have to represent the 
same *person* (or call center addresses aren't AORs), and it doesn't 
have to represent the same device. It just has to represent some stable 
"role" or "presentity" or something.

Nor, IMO, does it have to translate to something else. While it might be 
unusual, it is *possible* for an AOR to resolve directly to a UAS.

And if it does translate to something else, it need not be via a 
location service, though that is a common way.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 18:14:19 -0500

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Wednesday, July 15, 2009 15:51
> To: Audet, Francois (SC100:3055)
> Cc: Hadriel Kaplan; SIPCORE
> > But I can't think of cases where the tag "aor" would not be 
> applied to 
> > somthing that is not an AOR.
> > 
> > In my mind, the tag meant "I recorgnize this as being the AOR I'm 
> > responsible for, and that I'm using for the database dip".
> 

Yes. Agree.

> But I don't think thats enough - I've seen too many cases 
> when people are willing to assert things that make no sense. 
> If you just got an address from DHCP, then you had better not 
> assert that some URI containing that is an AOR.
> 
> I think the meaning of the URI needs to be stable over some 
> reasonably long period of time before it qualifies as an AOR. 
> But the meaning of "meaning" is also a bit squishy there. It 
> doesn't have to represent the same *person* (or call center 
> addresses aren't AORs), and it doesn't have to represent the 
> same device. It just has to represent some stable "role" or 
> "presentity" or something.
> 
> Nor, IMO, does it have to translate to something else. While 
> it might be unusual, it is *possible* for an AOR to resolve 
> directly to a UAS.
> 
> And if it does translate to something else, it need not be 
> via a location service, though that is a common way.

Yes, but let's remember that this tag we called "aor" in this draft is
meant for a specific purpose, i.e., isolating the important 
URIs from the "fluff". So the job of UASs and upstream proxies
is easier.

It's not like we are going to give a plaque of congratulations 
saying "Genuine AOR (tm)" or anything like that. The point is not
to define something as an ARO. The point is to mark an address
has having value for the domain, in resolving it using it's location
service.

Like somebody else said (think it was Hadriel), this is lower-case
"aor: the tag" as opposed to upper-case "AOR: the classic definition".

If we can think of a better tag name, maybe it would help. I personally
like "aor" because frankly, even for a AOR, you can't know a URI
is an AOR, unless you are the pornographer responsible for minting it :-)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jul 2009 19:25:12 -0400

If the tag is "aor" then I think it had better mean the same thing ans 
AOR or AoR. And in the process help to tighten up the definition of that.

Having it mean "something like AoR, but not quite" is IMO a *really* bad 
idea.

If it really is different than AoR, then it had better be called 
something else, and given a clear definition that justifies a new concept.

AFAIK the point here is to identify the URI as an Address of Record. If 
we had a clear unambiguous definition of that, which was also consistent 
with common understanding of the term (by those who *ought* to know), 
then I don't think we would be having this discussion.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 15 Jul 2009 18:36:44 -0500

"aor" means it is "an AOR that I own AND I used for a
location service dip". 

I don't know if you view that as "different" or not. I guess
it's debatable.

Again, in my humble opinion, a URI is an AOR only if the domain
responsible says so. And the way it knows it's an AOR is if 
it can use it for the location service dip. 

If people don't agree with the statement, then perhaps we should
change the name of the parameter.  

> Sent: Wednesday, July 15, 2009 16:25
> If the tag is "aor" then I think it had better mean the same 
> thing ans AOR or AoR. And in the process help to tighten up 
> the definition of that.
> 
> Having it mean "something like AoR, but not quite" is IMO a 
> *really* bad idea.
> 
> If it really is different than AoR, then it had better be 
> called something else, and given a clear definition that 
> justifies a new concept.
> 
> AFAIK the point here is to identify the URI as an Address of 
> Record. If we had a clear unambiguous definition of that, 
> which was also consistent with common understanding of the 
> term (by those who *ought* to know), then I don't think we 
> would be having this discussion.
> 
> 	Thanks,
> 	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jul 2009 20:19:08 -0400

> From: Francois Audet [mailto:[email-masked]]
> Sent: Wednesday, July 15, 2009 5:57 PM
> 

I think there are cases where an "aor" tag would be applied to something that's not an AoR, and probably vice-versa.  But maybe I'm not thinking about this quite right.

Example-1: ENUM is used widely, as both a means of performing "pure" E.164 number to AoR resolution, Number Portability, inter-domain routing, intra-domain routing, and even registered contact routing.  An ENUM query can be described as a location-service lookup.  Proxies performing an ENUM query don't necessarily know what type of URI they are performing that query for.  So if they get a request for "sip:[email-masked]" and do the query and the result makes it change it for inter-domain routing, then the original URI was not a AoR; if the result made it send it to a UAS/gateway directly, then it was an AoR.  Right?  Since the proxy won't know when, it will have to tag it as AoR every time, no?

Example-2: it is not rare for the req-uri sent to the proxy with which it does a lookup to not actually be the AoR per se - for example, the proxy may receive a req-uri of "sip:[email-masked]".  It resolves this to the registered contact for the "real" AoR of "sip:[email-masked]" - by "real" I mean the one registered and known by the UAS.  Now one could say the proxy should have added that real AoR in an H-I entry as another intermediate/internal step before resolution, because in theory the URI used for the resolution was the real AoR not the req-uri received; but that's getting into the internal mechanics of how the proxy was implemented.  For example the proxy may have done an ENUM lookup using only the username, and not know the "real" AoR's domain portion was different.  It was authoritative for "proxy1.sp.com" (it's also authoritative for "sp.com"), and it did a location lookup using "sip:[email-masked]", so all the conditions were met - but it's not the actual AoR the UAS needs to see, nor what we would consider a "classic" AoR (not what one would put on a business card, for example).  No?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 15 Jul 2009 20:25:15 -0400

> It is certainly true that not all AORs will be tagged.

I don't disagree with you on that, but it worries me.  The assumption I was going on was that the H-I list could be reduced to the set only tagged with "aor" and "mp"; would having entries not tagged "aor" which are in fact AoR's break that?  Or would those entries not matter either. (ie, would they be AoR's from a technical aspect but not necessary for consideration in app-specific uses of H-I entries?)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Jul 2009 21:35:07 -0400

> "aor" means it is "an AOR that I own AND I used for a

Hmm. the AND part is a bit troubling for me.
In this context the tag isn't added unless there is a translation 
following it, so saying "AND I translated it" is ok by me.
But IMO things can be AORs without ever using a location service. My 
example with alice and betty is one such case.

Now perhaps we can argue that if you translate an R-URI (rather than 
adding a Route header), then by definition what you did was use a 
location service. If so then I guess I am ok, but that seems odd.

	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 16 Jul 2009 09:01:30 +0200

inline...
/Hans Erik van Elburg

On Thu, Jul 16, 2009 at 2:19 AM, Hadriel Kaplan <[email-masked]>wrote:

> I think there are cases where an "aor" tag would be applied to something
> that's not an AoR, and probably vice-versa.  But maybe I'm not thinking
> about this quite right.
>
> Example-1: ENUM is used widely, as both a means of performing "pure" E.164
> number to AoR resolution, Number Portability, inter-domain routing,
> intra-domain routing, and even registered contact routing.  An ENUM query
> can be described as a location-service lookup.  Proxies performing an ENUM
> query don't necessarily know what type of URI they are performing that query
> for.  So if they get a request for "sip:[email-masked]<[email-masked]>"
> and do the query and the result makes it change it for inter-domain routing,
> then the original URI was not a AoR; if the result made it send it to a
> UAS/gateway directly, then it was an AoR.  Right?  Since the proxy won't
> know when, it will have to tag it as AoR every time, no?

In IMS this would be completely clear to me as not being one qualifying for
an aor tag, as it is proxy that acts on behalf of the originating user that
would perform the ENUM dip to be able to know where to route the request.
First when it enters the proxy(-instance) that acts on behalf of a
terminating user the aor tagging would start.

As for genuine SIP proxies  this distinction does not seem to be specified
we are having this debate.

>
> Example-2: it is not rare for the req-uri sent to the proxy with which it
> does a lookup to not actually be the AoR per se - for example, the proxy may
> receive a req-uri of "sip:[email-masked]<[email-masked]>".
>  It resolves this to the registered contact for the "real" AoR of "
> sip:[email-masked] <[email-masked]>" - by "real" I mean the one
> registered and known by the UAS.  Now one could say the proxy should have
> added that real AoR in an H-I entry as another intermediate/internal step
> before resolution, because in theory the URI used for the resolution was the
> real AoR not the req-uri received; but that's getting into the internal
> mechanics of how the proxy was implemented.  For example the proxy may have
> done an ENUM lookup using only the username, and not know the "real" AoR's
> domain portion was different.  It was authoritative for "proxy1.sp.com"
> (it's also authoritative for "sp.com"), and it did a location lookup using
> "sip:[email-masked] <[email-masked]>", so all
> the conditions were met - but it's n
>  ot the actual AoR the UAS needs to see, nor what we would consider a
> "classic" AoR (not what one would put on a business card, for example).  No?

No ;-)

You would not perform an ENUM dip for a SIP URI destined for your domain,
would you?
Also H-I is tracking internal retargets for some reason.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 16 Jul 2009 09:33:05 +0200

I'd like to understand what is wrong with the RFC3261 definition of AOR?
"Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that
points to a domain with a location service that can map the URI to another
URI where the user might be available. Typically, the location service is
populated through registrations. An AOR is frequently thought of as the
"public address" of the user."

Currently I think it is the best we have, can we agree to adopt that as
leading for the tagging procedure?

/Hans Erik van Elburg

On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyzivat <[email-masked]> wrote:

> In this context the tag isn't added unless there is a translation following
> it, so saying "AND I translated it" is ok by me.
> Now perhaps we can argue that if you translate an R-URI (rather than adding
> a Route header), then by definition what you did was use a location service.
> If so then I guess I am ok, but that seems odd.
>
>        Paul
>
>
>> responsible says so. And the way it knows it's an AOR is if it can use it
>> for the location service dip.
>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: Wednesday, July 15,
>>> 2009 16:25
>>> with common understanding of the term (by those who *ought* to know), then I
>>> don't think we would be having this discussion.
>>>
>>>        Thanks,
>>>        Paul
>>>
>>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 16 Jul 2009 09:04:27 +0100

>From that definition, I believe every entry in H-I except the last
(i.e., the Request-URI received by the UAS) would be an AOR. If not, the
request would not have got this far, because it would not have found a
domain that could route it.

Is my understanding correct? If so, what is the point of the "AOR"
indicator in H-I, if all but the last are marked "AOR"?

Perhaps there is one exception to the assumption above. A URI containing
an IP address would perhaps not be considered an AOR, because it does
not point to a domain.

John

> [mailto:[email-masked]] On Behalf Of Hans Erik van Elburg
> Sent: 16 July 2009 08:33
> To: Paul Kyzivat
> Cc: SIPCORE; Hadriel Kaplan
> "Address-of-Record: An address-of-record (AOR) is a SIP or 
> SIPS URI that points to a domain with a location service that 
> can map the URI to another URI where the user might be 
> available. Typically, the location service is populated 
> through registrations. An AOR is frequently thought of as the 
> Currently I think it is the best we have, can we agree to 
> adopt that as leading for the tagging procedure?
> 
> /Hans Erik van Elburg
> 
> 
> 	In this context the tag isn't added unless there is a 
> translation following it, so saying "AND I translated it" is ok by me.
> 	But IMO things can be AORs without ever using a 
> location service. My example with alice and betty is one such case.
> 	
> 	Now perhaps we can argue that if you translate an R-URI 
> (rather than adding a Route header), then by definition what 
> you did was use a location service. If so then I guess I am 
> ok, but that seems odd.
> 	
> 	       Paul 
> 
> 
> 
> 		responsible says so. And the way it knows it's 
> an AOR is if it can use it for the location service dip. 
> 			From: Paul Kyzivat 
> [mailto:[email-masked]] Sent: Wednesday, July 15, 2009 16:25
> 			If the tag is "aor" then I think it had 
> better mean the same thing ans AOR or AoR. And in the process 
> help to tighten up the definition of that.
> 			
> 			Having it mean "something like AoR, but 
> not quite" is IMO a *really* bad idea.
> 			
> 			If it really is different than AoR, 
> then it had better be called something else, and given a 
> clear definition that justifies a new concept.
> 			
> 			AFAIK the point here is to identify the 
> URI as an Address of Record. If we had a clear unambiguous 
> definition of that, which was also consistent with common 
> understanding of the term (by those who *ought* to know),

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 16 Jul 2009 13:21:41 +0200

Hi John,

The only reason that the aor tag was introduced, is to allow a UAS to
retrieve the aor that was used before it was replaced with the contact of
that UAS. The same semantics that P-Called-Party-ID (RFC3455) has today.

We can also live with P-Called-Party-ID, but I understood that the majority
wants to resolve all these requirements with one core-SIP header i.e.
History-Info.

So what do you think would be the proper definition for the foo tag?

Would tightening the definition to only apply to the home proxy of the
called user help?
Is a URI only an AOR when it is replaced with a registered contact address?
(This would do for the retrieval of the called AOR by the UAS.)

/Hans Erik van Elburg

On Thu, Jul 16, 2009 at 12:21 PM, Elwell, John <
[email-masked]> wrote:

> Hans Erik,
>
> Either these entities don't modify the Request-URI (and therefore don't
> generate a H-I entry) or they consider themselves responsible for that
> domain and change the Request-URI. Whether or not they really are
> responsible for the domain, by changing the Request-URI they are
> assuming responsibility, and therefore would qualify for adding 'aor' to
> the H-I entry. Certainly they could easily "misinterpret" the spec in
> that way.
>

Of course you can assume responsibility when your not responsible for the
domain, you cant claim that this implies that your responsible for the
domain. If implementors use nonsensical reasoning then nonsensical systems
will result. There is nothing that we can do about that, other then employ
other implementors that apply proper reasoning.

>
> So we have nodes that "misinterpret" the spec (because the definition of
> AOR is too loose) and insert 'aor' when they shouldn't, and legacy nodes
> that don't insert 'aor' when they should (or misinterpret the spec and
> fail to add 'aor'. So what really is the value of this tag?
>

Same.

>
> For this tag to be of any value, we need a much tighter definition of
> AOR (or if we change the name of the tag to 'foo', a much tighter
> definition of foo). Unless we can come up with a tight definition, I am
> not at all convinced we are going down a path that is really likely to
> improve interoperability.
>

Agree that we need an unambiguous definition.

> > Sent: 16 July 2009 10:18
> > To: Elwell, John
> > Proxies that are not responsible for the domain,  routing
> > proxies, statesless proxies, SIP aware firewalls, SBC's in
> > their role of SBC, P-CSCF, would not mark it with an aor tag.
> > So not all H-I entries will be marked with aor.
> >
> > Also given this defintion, TEL-URL will never be marked an AOR.
> >
> >
> > /Hans Erik van Elburg
> >
> >
> >
> > On Thu, Jul 16, 2009 at 10:04 AM, Elwell, John
> > <[email-masked]> wrote:
> >
> >

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 16 Jul 2009 13:10:35 +0200

Agree with Paul.

In terms of process, I understand the current definition of the tag is based on the RFC 3261 defn of AOR. How do we need to change that definition to represent what people now understand. (current text follows)

   o  AOR indicator: The AOR indicator is to mark an URI entry as being
      an Address Of Record.

and

   o  AOR indicator (hi-aor): An optional parameter for the History-Info
      indicating that the hi-targeted-to-uri is an Address Of Record (as
      defined in section 6/[RFC3261]) .  The hi-aor parameter is added
      by a proxy or redirect server to a hi-entry when it recognizes the
      URI in the last entry as a URI in its abstract location service
      (and then it can be routed accordingly).  Therefore, the hi-aor
      parameter (i.e., "aor") is not added for a hi-entry when it is
      first added in a History-Info header field, but rather is added
      when the retargeting actually occurs - i.e., the parameter
      indicates that the specific hi-targeted-to-uri that was retargeted
      was an AOR and thus the previous information in the request-URI
      may be "lost".  Upon receipt of a request or response containing
      the History-Info header, a UA can determine a "lost" target AOR
      for a request by traversing the HI entries in reverse order to
      find the first one tagged with a specific hi-aor parameter.

Then we can think of a name.

Keith

> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, July 16, 2009 12:25 AM
> To: Francois Audet
> when people 
> >> are willing to assert things that make no sense.
> >> If you just got an address from DHCP, then you had better 
> not assert 
> >> that some URI containing that is an AOR.
> >>
> >> But the meaning of "meaning" is also a bit squishy there. 
> It doesn't 
> >> have to represent the same *person* (or call center 
> addresses aren't 
> >> AORs), and it doesn't have to represent the same device. 
> It just has 
> >> to represent some stable "role" or "presentity" or something.
> >>
> >> Nor, IMO, does it have to translate to something else. 
> While it might 
> >> be unusual, it is *possible* for an AOR to resolve 
> directly to a UAS.
> >>
> URIs from 
> > the "fluff". So the job of UASs and upstream proxies is easier.
> > 
> > It's not like we are going to give a plaque of 
> congratulations saying 
> > "Genuine AOR (tm)" or anything like that. The point is not 
> to define 
> > something as an ARO. The point is to mark an address has 
> having value 
> > for the domain, in resolving it using it's location service.
> > 
> > If we can think of a better tag name, maybe it would help. I 
> > personally like "aor" because frankly, even for a AOR, you 
> can't know 
> > a URI is an AOR, unless you are the pornographer responsible for 
> > minting it :-)
> >

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 16 Jul 2009 13:19:04 +0100

The semantics for P-Called-Party-ID are indeed a lot clearer.

John 

> Sent: 16 July 2009 12:22
> Cc: SIPCORE
> The only reason that the aor tag was introduced, is to allow 
> a UAS to retrieve the aor that was used before it was 
> replaced with the contact of that UAS. The same semantics 
> that P-Called-Party-ID (RFC3455) has today.
> 
> We can also live with P-Called-Party-ID, but I understood 
> that the majority wants to resolve all these requirements 
> with one core-SIP header i.e. History-Info.
> 
> Would tightening the definition to only apply to the home 
> proxy of the called user help?
> Is a URI only an AOR when it is replaced with a registered 
> contact address? (This would do for the retrieval of the 
> called AOR by the UAS.)
> 
> /Hans Erik van Elburg
> 
> 
> 
> On Thu, Jul 16, 2009 at 12:21 PM, Elwell, John 
> Of course you can assume responsibility when your not 
> responsible for the domain, you cant claim that this implies 
> that your responsible for the domain. If implementors use 
> nonsensical reasoning then nonsensical systems will result. 
> There is nothing that we can do about that, other then employ 
> 	>       >               I don't know if you view that 
> as "different" or
> 	>       > not. I guess
> 	>       >               it's debatable.
> 	>       >
> 	>       >               Again, in my humble opinion, a 
> URI is an AOR
> 	>       > only if the domain
> 	>       >               If people don't agree with the 
> statement, then
> 	>       > perhaps we should
> 	>       >                       Subject: Re: [sipcore] 
> rfc4244bis: what
> 	>       > is an AoR?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jul 2009 10:07:50 -0400

> I'd like to understand what is wrong with the RFC3261 definition of AOR? 

OK, rather than continuing to trust my memory I went back and reviewed 
the definition of AOR and Location Service in 3261, as well as the 
discussion around the use of the latter.

I conclude that the existing definition of AOR is at least close, and 
that most of the cases I listed before fit within it.

In particular, it seems that any translation of the incoming R-URI into 
a new value for the target set, except values received via 3xx 
responses, can be construed as coming from the use of a location 
service. This includes db lookups (such as ENUM) and algorithmic 
transformations.

I see a couple of cases that that aren't covered  by the above that IMO 
ought to be considered AORs:
- If I become the owner of domain kyzivat.com, have it point to
   a server of mine, and establish a UA on that server that responds to
   sip:[email-masked], then IMO sip:[email-masked] ought to be
   considered an AOR even though there is no location service and no
   domain proxy involved in accessing it.

   This wouldn't be important to the H-I discussion very often. But
   it might be if a request reached it, and it then chose to return a
   3xx response. In that case I would think it should mark its own H-I
   entry as an AOR.

- TEL URIs are currently never AORs because the def of AOR says they
   must be sip or sips URIs. But I think it makes a lot of sense to
   consider TEL URIs to be AORs. I do however realize this may  be
   controversial.

Aside from discussing if something should be tweaked to address these 
two cases I guess I am ok with the 3261 definition.

	Thanks,
	Paul

> points to a domain with a location service that can map the URI to 
> another URI where the user might be available. Typically, the location 
> service is populated through registrations. An AOR is frequently thought 
> of as the "public address" of the user."
> 
> On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     Francois Audet wrote:
> 
>         responsible says so. And the way it knows it's an AOR is if it
>         can use it for the location service dip.
>             From: Paul Kyzivat [mailto:[email-masked]
>             <mailto:[email-masked]>] Sent: Wednesday, July 15, 2009
>             16:25
>     [email-masked] <mailto:[email-masked]>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 10:25:52 -0500

Hi Hadriel,

In my humble opinion, those 2 examples are in fact AORs.

I.e., they "map" to another URI where the user may be available.

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Wednesday, July 15, 2009 17:19
> To: Audet, Francois (SC100:3055); SIPCORE
> Subject: RE: [sipcore] rfc4244bis: what is an AoR?
> 
> 
> 
> I think there are cases where an "aor" tag would be applied 
> to something that's not an AoR, and probably vice-versa.  But 
> maybe I'm not thinking about this quite right.
> 
> Example-1: ENUM is used widely, as both a means of performing 
> "pure" E.164 number to AoR resolution, Number Portability, 
> inter-domain routing, intra-domain routing, and even 
> registered contact routing.  An ENUM query can be described 
> as a location-service lookup.  Proxies performing an ENUM 
> query don't necessarily know what type of URI they are 
> performing that query for.  So if they get a request for 
> "sip:[email-masked]" and do the query and the result 
> makes it change it for inter-domain routing, then the 
> original URI was not a AoR; if the result made it send it to 
> a UAS/gateway directly, then it was an AoR.  Right?  Since 
> the proxy won't know when, it will have to tag it as AoR 
> every time, no?
> 
> Example-2: it is not rare for the req-uri sent to the proxy 
> with which it does a lookup to not actually be the AoR per se 
> - for example, the proxy may receive a req-uri of 
> "sip:[email-masked]".  It resolves this to the 
> registered contact for the "real" AoR of 
> "sip:[email-masked]" - by "real" I mean the one registered 
> and known by the UAS.  Now one could say the proxy should 
> have added that real AoR in an H-I entry as another 
> intermediate/internal step before resolution, because in 
> theory the URI used for the resolution was the real AoR not 
> the req-uri received; but that's getting into the internal 
> mechanics of how the proxy was implemented.  For example the 
> proxy may have done an ENUM lookup using only the username, 
> and not know the "real" AoR's domain portion was different.  
> It was authoritative for "proxy1.sp.com" (it's also 
> authoritative for "sp.com"), and it did a location lookup 
> using "sip:[email-masked]", so all the conditions 
> were met - but it's not the actual AoR the UAS needs to see, 
> nor what we would consider a "classic" AoR (not what one 
> would put on a business card, for example).  No?
> 
> -hadriel
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 10:36:02 -0500

In my opinion, if a proxy does a Call Forwarding
(for example), on a number that it believes it
owns, in fact that is an AOR and would be marked as
such.

Where this gets form complicated, and where I think you
have a point, is when using phone numbers (say, embedded
in a SIP URI, but where the domain is effectively meaningless).
A proxy may redirect, say, sip:[email-masked];user=phone to
sip:[email-masked];user=phone.

This type of stuff has created problems for us before.

Using the current draft rules, the second entry would be marked
with mp, and the first one may or may not be marked with aor. And
that's where the ambiguity is. Specifically, most algorithm need the
first entry, not the second. But you don't know that it was
a "redirection" unless you look at the second one. I believe 
anything that relies on "go to X and look at X-1" (or X+1) is
risky since the entry may not be there. It would be better if
the non-fluff entry was always flagged. I don't think our draft
today achieves this with the specific case of "mapped".

One potential way around this would be to move the "mp" tag
back to mean "the entry that was mapped" instead of leaving
it where it is now, on the second entry, as "the number it was
mapped too". Or maybe have aor-same and aor-mapped.

Comments?

> Sent: Wednesday, July 15, 2009 17:25
> I don't disagree with you on that, but it worries me.  The 
> assumption I was going on was that the H-I list could be 
> reduced to the set only tagged with "aor" and "mp"; would 
> having entries not tagged "aor" which are in fact AoR's break 
> that?  Or would those entries not matter either. (ie, would 
> they be AoR's from a technical aspect but not necessary for 
> consideration in app-specific uses of H-I entries?)
> 
> -hadriel
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 10:42:25 -0500

Right, what's missing in there is a qualifier
that only the entity responsible for the domain
in the entry can mark it as an AOR.

To me this is self-obvious in RFC 3261. You can't 
recognize an AOR just by looking at a URI. You HAVE
to be the domain of the URI to know if it's an AOR.

But we can certainly make that clear in the text.

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Thursday, July 16, 2009 04:11
> To: Paul Kyzivat; Audet, Francois (SC100:3055)
> In terms of process, I understand the current definition of 
> the tag is based on the RFC 3261 defn of AOR. How do we need 
> to change that definition to represent what people now 
> understand. (current text follows)
> 
> > AFAIK the point here is to identify the URI as an Address 
> of Record. 
> > If we had a clear unambiguous definition of that, which was also 
> > consistent with common understanding of the term (by those 
> who *ought* 
> > to know), then I don't think we would be having this discussion.
> > 
> > 	Thanks,
> > 	Paul
> > 
> > Francois Audet wrote:
> > >  
> > >

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 10:44:50 -0500

Yep, and I thing this definion is EXACTLY what we are using in the document.

________________________________

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: Thursday, July 16, 2009 00:33
	To: Paul Kyzivat
	Cc: Audet, Francois (SC100:3055); SIPCORE; Hadriel Kaplan
	Subject: Re: [sipcore] rfc4244bis: what is an AoR?

	"Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user."

	Currently I think it is the best we have, can we agree to adopt that as leading for the tagging procedure?

	/Hans Erik van Elburg

		Francois Audet wrote:

		Hmm. the AND part is a bit troubling for me.
		In this context the tag isn't added unless there is a translation following it, so saying "AND I translated it" is ok by me.
		But IMO things can be AORs without ever using a location service. My example with alice and betty is one such case.
		
		Now perhaps we can argue that if you translate an R-URI (rather than adding a Route header), then by definition what you did was use a location service. If so then I guess I am ok, but that seems odd.
		
		       Paul 

			Again, in my humble opinion, a URI is an AOR only if the domain
			responsible says so. And the way it knows it's an AOR is if it can use it for the location service dip. 
			If people don't agree with the statement, then perhaps we should
			change the name of the parameter.  

				-----Original Message-----
				From: Paul Kyzivat [mailto:[email-masked]] Sent: Wednesday, July 15, 2009 16:25
				To: Audet, Francois (SC100:3055)
				Cc: Hadriel Kaplan; SIPCORE
				Subject: Re: [sipcore] rfc4244bis: what is an AoR?
				
				If the tag is "aor" then I think it had better mean the same thing ans AOR or AoR. And in the process help to tighten up the definition of that.
				
				Having it mean "something like AoR, but not quite" is IMO a *really* bad idea.
				
				If it really is different than AoR, then it had better be called something else, and given a clear definition that justifies a new concept.
				
				AFAIK the point here is to identify the URI as an Address of Record. If we had a clear unambiguous definition of that, which was also consistent with common understanding of the term (by those who *ought* to know), then I don't think we would be having this discussion.
				
				       Thanks,
				       Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 10:50:03 -0500

Example-1: ENUM is used widely, as both a means of performing "pure" E.164 number to AoR resolution, Number Portability, inter-domain routing, intra-domain routing, and even registered contact routing.  An ENUM query can be described as a location-service lookup.  Proxies performing an ENUM query don't necessarily know what type of URI they are performing that query for.  So if they get a request for "sip:[email-masked] <mailto:[email-masked]> " and do the query and the result makes it change it for inter-domain routing, then the original URI was not a AoR; if the result made it send it to a UAS/gateway directly, then it was an AoR.  Right?  Since the proxy won't know when, it will have to tag it as AoR every time, no?

	In IMS this would be completely clear to me as not being one qualifying for an aor tag, as it is proxy that acts on behalf of the originating user that would perform the ENUM dip to be able to know where to route the request. First when it enters the proxy(-instance) that acts on behalf of a terminating user the aor tagging would start.

	As for genuine SIP proxies  this distinction does not seem to be specified we are having this debate.

I have this feeling that I'm missing a suttlety here because of my lack of knowledge of IMS....
 
Say I call sip:[email-masked] <mailto:[email-masked]> ;user=phone. My proxy is "sp.com", right? 
 
Then sp.net does ENUM query. Then it forwards the request to whatever the result of the ENUM query was, say sip:[email-masked] <mailto:[email-masked]> ;user=phone. Correct?
 
So the ;aor tag would be added by example.com. Is this what you are saying?
 
If so, I think I agree.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 11:11:49 -0500

Ok, it seems we are reaching the same conclusions. 
(This is why we took care to really go back to reading 3261
when writting this draft).

In any case, see below:

> Sent: Thursday, July 16, 2009 07:08
> To: Hans Erik van Elburg
> OK, rather than continuing to trust my memory I went back and 
> reviewed the definition of AOR and Location Service in 3261, 
> as well as the discussion around the use of the latter.
> 
> I conclude that the existing definition of AOR is at least 
> close, and that most of the cases I listed before fit within it.
> 
> In particular, it seems that any translation of the incoming 
> R-URI into a new value for the target set, except values 
> received via 3xx responses, can be construed as coming from 
> the use of a location service. This includes db lookups (such 
> as ENUM) and algorithmic transformations.
> 
> I see a couple of cases that that aren't covered  by the 
> above that IMO ought to be considered AORs:

I would actually consider that to be a location service. It's kind of
trivial obviously, it sends it kyzivat@localhost, but it's still there.
And it does route it to paul instead of peter or mary.

>    consider TEL URIs to be AORs. I do however realize this may  be

Yes, agree. Definition in 3261 explicitly covers only SIP and SIPS.

I think we all know there are lots of unanswered questions about 
usage of Tel URIs in SIP. Not sure what we can do about it for now.
We specifically avoided getting into this rat-hole in the draft.

> Aside from discussing if something should be tweaked to 
> address these two cases I guess I am ok with the 3261 definition.

Excellent!

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 11:18:02 -0500

I'll do the following changes:

   o  AOR indicator: The AOR indicator is to mark an URI entry as being
      recognized as an Address Of Record by the domain of the entry.

and

   o  AOR indicator (hi-aor): An optional parameter for the History-Info
      indicating that the hi-targeted-to-uri is recognized as an Address Of 
	Record (as defined in section 6/[RFC3261]) by the domain of the 
	entry. [...]

I therefore don't think we need to change the name.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 16 Jul 2009 22:20:08 +0200

yes
/Hans Erik van Elburg

On Thu, Jul 16, 2009 at 5:50 PM, Francois Audet <[email-masked]> wrote:

>
>
>  Example-1: ENUM is used widely, as both a means of performing "pure"
>> E.164 number to AoR resolution, Number Portability, inter-domain routing,
> Say I call sip:[email-masked] <[email-masked]>;user=phone.
> My proxy is "sp.com", right?
>
> Then sp.net does ENUM query. Then it forwards the request to whatever the
> result of the ENUM query was, say sip:[email-masked]<[email-masked]>;user=phone.
> Correct?
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 15:38:10 -0500

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Thursday, July 16, 2009 01:04
> To: Hans Erik van Elburg; Paul Kyzivat
> From that definition, I believe every entry in H-I except the 
> last (i.e., the Request-URI received by the UAS) would be an 
> AOR. If not, the request would not have got this far, because 
> it would not have found a domain that could route it.

No, this is false: not all entries will be aors.

For example, I call you, my request gets routed to [email-masked] (your
registered contact). You send a 302 to [email-masked], and it recurses all the way
to [email-masked] (another registered contact).

In this case, you'll have an entry in the middle ([email-masked]) that is not 
an AOR.

> indicator in H-I, if all but the last are marked "AOR"?

The point of AOR is marking useful entries differently than pointless
ones.

There are lots of other examples. You have to remember that in H-I, normally
all proxies are supposed to add entries even if they don't own the domain,
and even if they don't change anything.

- I send a request to sip:[email-masked] from sip:[email-masked].
  My proxy adds the entry sip:[email-masked], but it doesn't mark it
  as AOR because it doesn't own it. It will only be marked as AOR by YOUR proxy when
  it reaches it.

- Strict-routing. None of the strict-routing proxy addresses would be marked as AOR.

- Manual digit manipulation done by outgoing proxies (i.e., sip:[email-masked]
  will not be marked as AOR). When it ultimately gets mapped to sip:+4901234567@siemens-
  enterprise.com;user=phone) by YOUR proxy (as per first bullet), then it gets marked.

The AOR marking allows to eliminate a lot of redundant (in best case) or innacurate entries 
and facilitate parsing of H-I by UAS.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Jul 2009 18:53:02 -0400

I am not understanding. Inline

Francois Audet wrote:
>         inter-domain routing, intra-domain routing, and even registered
>         contact routing.  An ENUM query can be described as a
>         location-service lookup.  Proxies performing an ENUM query don't
>         necessarily know what type of URI they are performing that query
>         for.  So if they get a request for "sip:[email-masked]"
>         and do the query and the
>         result makes it change it for inter-domain routing, then the
>         original URI was not a AoR; if the result made it send it to a
>         UAS/gateway directly, then it was an AoR.  Right?  Since the
>         proxy won't know when, it will have to tag it as AoR every time, no?
> 
> 
>     In IMS this would be completely clear to me as not being one
>     qualifying for an aor tag, as it is proxy that acts on behalf of the
>     originating user that would perform the ENUM dip to be able to know
>     where to route the request. First when it enters the
>     proxy(-instance) that acts on behalf of a terminating user the aor
>     tagging would start.
> 
> Say I call sip:[email-masked];user=phone. My proxy is "sp.com", 
> right?
>  
> Then sp.net does ENUM query.

If we assume that ENUM qualifies as a location service (and I am now 
convinced that it does), then this URI *is* an AOR in sp.com.

> Then it forwards the request to whatever 
> the result of the ENUM query was, say sip:[email-masked];user=phone. Correct?
>  

That URI can also be an AOR.

I agree that sip:[email-masked];user=phone probably *should* not be 
an AOR if sp.com is not responsible for that phone number. But does that 
mean we should exclude ENUM from being considered a location service?

Or must we dice things finer, and say that if translate with ENUM and 
the result happens to be in your own domain then it was an AOR, but if 
it wasn't in your own domain then it wasn't an AOR?

This gets into the whole TEL URI thing. IMO a TEL URI ought to be 
considered an AOR, and *everybody* is allowed to make that 
determination, not just its "domain". (It has no domain.)

But when you start putting tel uri syntax into sip URIs it gets ugly. I 
guess some say you are not allowed to form such a thing unless the 
domain *is* the owner of the phone number. But that is an unreasonable 
approach. IMO the user part is just another name in that domain, and is 
valid or not according to that domain. If it chooses to interpret as an 
E.164 number, and use ENUM to translate it, then that is its business. 
And superficially that makes it an AOR.

	Thanks,
	Paul

> If so, I think I agree.
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 16 Jul 2009 17:37:02 -0700

> convinced that it does), then this URI *is* an AOR in sp.com.

No, because it's not the right domain. It's doing the ENUM on a phone
number. So it really has nothing to do with a SIP scheme (a condition
for AOR, remember?).

And in fact, it goes to example.com, not sp.com

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Jul 2009 22:04:46 -0400

Actually, I think it  (the domain that was on the right hand side of the 
R-URI, and that is performing the ENUM lookup) is "the right" domain.
Of course, this turns on deciding what a SIP URI with a user part that 
happens to be digits is.
As far as I can tell, it ought to be a SIP UIR.
Therefore, if a proxy in domain sp.com receives a SIP R-URI of 
sip:[email-masked];user=phone (with the right number of digits, 
sorry), then sp.com is the responsible domain.  The fact that the proxy 
does not actually care if the target is within sp.com, and will use 
ENUM, and send the call on wherever ENUM tells it does not change the 
fact that the R-URI indicated his domain, the proxy understand the 
domain, and understand the rules of the domain.  That domain just has a 
lot of implicit registration, and an ENUM based location service.  So be it.

(Now, at least in my opinion, if any proxy outside of sp.com tries that 
trick it is just plain wrong.  But that is, I think, a different 
discussion.)

Yours,
Joel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 17 Jul 2009 09:40:44 +0200

sounds reasonable.
/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 4:04 AM, Joel M. Halpern <[email-masked]>wrote:

> sip:[email-masked] <[email-masked]>;user=phone (with the
> right number of digits, sorry), then sp.com is the responsible domain.
>  The fact that the proxy does not actually care if the target is within
> sp.com, and will use ENUM, and send the call on wherever ENUM tells it
> does not change the fact that the R-URI indicated his domain, the proxy
> understand the domain, and understand the rules of the domain.  That domain
> just has a lot of implicit registration, and an ENUM based location service.
>  So be it.
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Jul 2009 11:43:48 +0100

> Sent: 16 July 2009 21:38
> To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat
[JRE] OK, I had forgotten about redirection.

>   as AOR because it doesn't own it. It will only be marked as 
[JRE] Well, the point is it gets marked as AOR at some point, so the
fact that not all entries mark it as AOR is irrelevant.

> and facilitate parsing of H-I by UAS.
[JRE] I appreciate the intent, but I am just concern about the looseness
of the definition.

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 17 Jul 2009 11:46:53 +0100

> ([email-masked]) that is not 
[JRE] Thinking about this further, I believe this DOES fit the
definition for AOR. In other words, my UAS is responsible for
10.10.15.12 and its "location service" tells it that the contact for
elwell is [email-masked].

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Jul 2009 08:58:28 -0400

Francois Audet wrote:
> number.

Its doing an ENUM on a phone number from the user part of a sip URI with 
domain name sp.com.

Assuming its the sp.com domain that is doing the ENUM query, then it is 
the *right* domain. If the proxy was not responsible for the sp.com 
domain then it shouldn't be doing the translation, using ENUM or 
anything else.

> So it really has nothing to do with a SIP scheme (a condition
> for AOR, remember?).
> 

What does that have to do with anything?

If this number was looked up in a location service that was populated 
via REGISTER, and the result was in example.com you wouldn't be arguing 
that meant this couldn't be an AOR.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Jul 2009 10:52:11 -0400

> Sent: Thursday, July 16, 2009 8:37 PM
> 

Did you intend for this to be "sp.net" and thus a different domain from "sp.com"?  Or was that a typo?  I am assuming it was a typo.

> number. So it really has nothing to do with a SIP scheme (a condition

Regardless of whether ENUM is doing it on a phone number sans domain or not, it MUST be marked as an "aor".  Think of it this way:
Suppose you call "sip:[email-masked]", and sp.com does an ENUM lookup on 18005551212, and the NAPTR result translated it to the non-800 specific number for it.  The freephone-model/redirection-usage NEEDs to see that 18005551212. No?

That's also why I think you'd want Tel-URI's - because sp.com could have received a Tel-URI with it and done that ENUM lookup.

> And in fact, it goes to example.com, not sp.com

So?  As far as the sp.com Proxy cares, it has done an ENUM lookup and gotten a result which changes the req-uri and makes it route the call.  As far as it knows, "sip:[email-masked]" is a contact address of a PSTN-Gateway or registered UA, in which case per the rules "sip:[email-masked]" WAS an AoR; whereas if "sip:[email-masked]" is another peer domain then it's not an AoR??

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 17 Jul 2009 22:13:25 +0200

inline...
/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <[email-masked]>wrote:

> Did you intend for this to be "sp.net" and thus a different domain from "
> sp.com"?  Or was that a typo?  I am assuming it was a typo.
>
>
> Regardless of whether ENUM is doing it on a phone number sans domain or
> not, it MUST be marked as an "aor".  Think of it this way:
> Suppose you call "sip:[email-masked] <[email-masked]>",
> and sp.com does an ENUM lookup on 18005551212, and the NAPTR result
> translated it to the non-800 specific number for it.  The
> freephone-model/redirection-usage NEEDs to see that 18005551212. No?

No. The aor tag has nothing todo with the freephone case, for that case the
"mp" tag or in its absence  the first H-I entry is important to be able to
determine the original called target.

>
>
> That's also why I think you'd want Tel-URI's - because sp.com could have
> received a Tel-URI with it and done that ENUM lookup.
>
> So?  As far as the sp.com Proxy cares, it has done an ENUM lookup and
> gotten a result which changes the req-uri and makes it route the call.  As
> far as it knows, "sip:[email-masked]<[email-masked]>"
> is a contact address of a PSTN-Gateway or registered UA, in which case per
> the rules "sip:[email-masked] <[email-masked]>" WAS an
> AoR; whereas if "sip:[email-masked]<[email-masked]>"
> is another peer domain then it's not an AoR??
>

The question is if it matters in this case.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 17 Jul 2009 17:43:37 -0400

I'm confused (I know, not a hard thing to make me be apparently :().
In a previous chain of emails I thought the purpose of the "mp" flag was to indicate a retarget happened, but that the subsequent "aor" flagged URI was what would actually be used for applications, because it is the "cleaned-up" form of the URI being retargeted to, since it actually identifies what the authoritative domain which got it claims it location-service routed with.

Your response indicates that the "mp" flagged URI would actually be used by the application, even when it does not have an "aor" flag (as it would not in this case).

Which is it?  Or are the cases different for different application uses, for which flags are important?

-hadriel

________________________________
From: Hans Erik van Elburg [mailto:[email-masked]]
Sent: Friday, July 17, 2009 4:13 PM
To: Hadriel Kaplan
Cc: Francois Audet; Paul Kyzivat; SIPCORE
Subject: Re: [sipcore] rfc4244bis: what is an AoR?

inline...
/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

> From: Francois Audet [mailto:[email-masked]<mailto:[email-masked]>]
> >> Say I call sip:[email-masked]<mailto:[email-masked]>;user=phone. My proxy is "sp.com<http://sp.com>",
> >> right?
> >>
> >> Then sp.net<http://sp.net> does ENUM query.
Did you intend for this to be "sp.net<http://sp.net>" and thus a different domain from "sp.com<http://sp.com>"?  Or was that a typo?  I am assuming it was a typo.

> > convinced that it does), then this URI *is* an AOR in sp.com<http://sp.com>.
>
Regardless of whether ENUM is doing it on a phone number sans domain or not, it MUST be marked as an "aor".  Think of it this way:
Suppose you call "sip:[email-masked]<mailto:[email-masked]>", and sp.com<http://sp.com> does an ENUM lookup on 18005551212, and the NAPTR result translated it to the non-800 specific number for it.  The freephone-model/redirection-usage NEEDs to see that 18005551212. No?

No. The aor tag has nothing todo with the freephone case, for that case the "mp" tag or in its absence  the first H-I entry is important to be able to determine the original called target.

That's also why I think you'd want Tel-URI's - because sp.com<http://sp.com> could have received a Tel-URI with it and done that ENUM lookup.

> And in fact, it goes to example.com<http://example.com>, not sp.com<http://sp.com>
So?  As far as the sp.com<http://sp.com> Proxy cares, it has done an ENUM lookup and gotten a result which changes the req-uri and makes it route the call.  As far as it knows, "sip:[email-masked]<mailto:[email-masked]>" is a contact address of a PSTN-Gateway or registered UA, in which case per the rules "sip:[email-masked]<mailto:[email-masked]>" WAS an AoR; whereas if "sip:[email-masked]<mailto:[email-masked]>" is another peer domain then it's not an AoR??

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sat, 18 Jul 2009 08:54:54 +0200

Yes the relevant flags are dependent on what you in your role of UAS would
like  to retrieve.

The rules would be very simple.
To retrieve the addressed target (freephone, etc):
- traverse all H-I entries backward until an "mp" entry is found, if found
this is the addressed target
- if no "mp" found take the first H-I entry
- if no History-Info header take the Request-URI value

To retrieve the last aor before it was overwritten by contact
address (similar as P-Called-Party-ID):
- traverse all H-I entries backward until an "aor" entry is found, if found
this is the last AOR used

/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan <[email-masked]>wrote:

>  I’m confused (I know, not a hard thing to make me be apparently L).
>
> In a previous chain of emails I thought the purpose of the “mp” flag was to
> indicate a retarget happened, but that the subsequent “aor” flagged URI was
> what would actually be used for applications, because it is the “cleaned-up”
> form of the URI being retargeted to, since it actually identifies what the
> authoritative domain which got it claims it location-service routed with.
>
>
>
> Your response indicates that the “mp” flagged URI would actually be used by
> the application, even when it does not have an “aor” flag (as it would not
> in this case).
>
>
>
>   ------------------------------
>
> *From:* Hans Erik van Elburg [mailto:[email-masked]]
> *Sent:* Friday, July 17, 2009 4:13 PM
> *To:* Hadriel Kaplan
> *Cc:* Francois Audet; Paul Kyzivat; SIPCORE
>
> *Subject:* Re: [sipcore] rfc4244bis: what is an AoR?
>
>
>
> inline...
> /Hans Erik van Elburg
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 18 Jul 2009 12:11:38 -0400

Doesn't it seem wrong/dangerous to you that one application would use the "mp" flagged entry as a target, while another application uses the "aor" flagged entry as a target?  I mean really they're all looking for "targets", right?  One's just looking for the "last redirected-to" target, and the other's looking for the "last resolved-to" target.  No?

The point made by Francois in one of the emails (which made a lot of sense to me) was that you basically had to use the "aor" ones because anything else is just that local proxy's view of what its routing to, including any locally-specific "ugliness", pre-translation et al; whereas the "aor" one was what the actual targeted domain saw and used for location-service resolution and therefore was "authoritative".

-hadriel

Sent: Saturday, July 18, 2009 2:55 AM

Yes the relevant flags are dependent on what you in your role of UAS would like  to retrieve.

To retrieve the addressed target (freephone, etc):
- traverse all H-I entries backward until an "mp" entry is found, if found this is the addressed target
- if no "mp" found take the first H-I entry
- if no History-Info header take the Request-URI value

To retrieve the last aor before it was overwritten by contact address (similar as P-Called-Party-ID):
- traverse all H-I entries backward until an "aor" entry is found, if found this is the last AOR used

/Hans Erik van Elburg
On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

-hadriel

From: Hans Erik van Elburg [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, July 17, 2009 4:13 PM
To: Hadriel Kaplan
Cc: Francois Audet; Paul Kyzivat; SIPCORE

inline...
/Hans Erik van Elburg

-hadriel

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sun, 19 Jul 2009 10:30:12 +0200

No not really, it is only different application retrieving different bits of
information. What is important is that they can extract this information.

/Hans Erik van Elburg

On Sat, Jul 18, 2009 at 6:11 PM, Hadriel Kaplan <[email-masked]>wrote:

>
>
> Doesn’t it seem wrong/dangerous to you that one application would use the
> “mp” flagged entry as a target, while another application uses the “aor”
> flagged entry as a target?  I mean really they’re all looking for “targets”,
> right?  One’s just looking for the “last redirected-to” target, and the
> other’s looking for the “last resolved-to” target.  No?
>
>
>
> The point made by Francois in one of the emails (which made a lot of sense
> to me) was that you basically had to use the “aor” ones because anything
> else is just that local proxy’s view of what its routing to, including any
> locally-specific “ugliness”, pre-translation et al; whereas the “aor” one
> was what the actual targeted domain saw and used for location-service
> resolution and therefore was “authoritative”.
>
>
>
> -hadriel
>
>
> *Sent:* Saturday, July 18, 2009 2:55 AM
>
> *To:* Hadriel Kaplan

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Jul 2009 12:43:25 -0500

So, we are saying it is an ;aor after all?

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: Friday, July 17, 2009 00:41
	To: Joel M. Halpern
	Cc: Audet, Francois (SC100:3055); SIPCORE; Hadriel Kaplan
	Subject: Re: [sipcore] rfc4244bis: what is an AoR?

	sounds reasonable. 

	/Hans Erik van Elburg

	On Fri, Jul 17, 2009 at 4:04 AM, Joel M. Halpern <[email-masked]> wrote:

		Actually, I think it  (the domain that was on the right hand side of the R-URI, and that is performing the ENUM lookup) is "the right" domain.
		Of course, this turns on deciding what a SIP URI with a user part that happens to be digits is.
		As far as I can tell, it ought to be a SIP UIR.
		Therefore, if a proxy in domain sp.com receives a SIP R-URI of sip:[email-masked] <mailto:[email-masked]> ;user=phone (with the right number of digits, sorry), then sp.com is the responsible domain.  The fact that the proxy does not actually care if the target is within sp.com, and will use ENUM, and send the call on wherever ENUM tells it does not change the fact that the R-URI indicated his domain, the proxy understand the domain, and understand the rules of the domain.  That domain just has a lot of implicit registration, and an ENUM based location service.  So be it.
		
		(Now, at least in my opinion, if any proxy outside of sp.com tries that trick it is just plain wrong.  But that is, I think, a different discussion.)
		
		Yours,
		Joel
		
		Francois Audet wrote:

					Say I call sip:[email-masked] <mailto:[email-masked]> ;user=phone. My proxy is "sp.com",
					right?
					 Then sp.net does ENUM query.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Jul 2009 12:45:53 -0500

> [JRE] Thinking about this further, I believe this DOES fit 
> the definition for AOR. In other words, my UAS is responsible for
> 10.10.15.12 and its "location service" tells it that the 
> contact for elwell is [email-masked].

Exactly.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Jul 2009 12:54:18 -0500

By "first H-I entry", you mean the "first from the end", i.e., "the last", right?

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: Friday, July 17, 2009 23:55
	To: Hadriel Kaplan
	Cc: Audet, Francois (SC100:3055); Paul Kyzivat; SIPCORE
	Subject: Re: [sipcore] rfc4244bis: what is an AoR?

	/Hans Erik van Elburg

	On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan <[email-masked]> wrote:

		I’m confused (I know, not a hard thing to make me be apparently :-().

		In a previous chain of emails I thought the purpose of the “mp” flag was to indicate a retarget happened, but that the subsequent “aor” flagged URI was what would actually be used for applications, because it is the “cleaned-up” form of the URI being retargeted to, since it actually identifies what the authoritative domain which got it claims it location-service routed with.

		Your response indicates that the “mp” flagged URI would actually be used by the application, even when it does not have an “aor” flag (as it would not in this case).

		-hadriel

		 

		inline...
		/Hans Erik van Elburg

		On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <[email-masked]> wrote:

		Regardless of whether ENUM is doing it on a phone number sans domain or not, it MUST be marked as an "aor".  Think of it this way:
		Suppose you call "sip:[email-masked] <mailto:[email-masked]> ", and sp.com does an ENUM lookup on 18005551212, and the NAPTR result translated it to the non-800 specific number for it.  The freephone-model/redirection-usage NEEDs to see that 18005551212. No?

		 

			> And in fact, it goes to example.com, not sp.com

			So?  As far as the sp.com Proxy cares, it has done an ENUM lookup and gotten a result which changes the req-uri and makes it route the call.  As far as it knows, "sip:[email-masked] <mailto:[email-masked]> " is a contact address of a PSTN-Gateway or registered UA, in which case per the rules "sip:[email-masked] <mailto:[email-masked]> " WAS an AoR; whereas if "sip:[email-masked] <mailto:[email-masked]> " is another peer domain then it's not an AoR??

			
			-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Jul 2009 13:04:55 -0500

In this particular example of address target, wouln't just using the same algorith, i.e., pick the last entry with "aor" actually work?
 
Yes, it could have both an "mp" and an "aor" flag.

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: Sunday, July 19, 2009 01:30
	To: Hadriel Kaplan
	Cc: Audet, Francois (SC100:3055); Paul Kyzivat; SIPCORE
	Subject: Re: [sipcore] rfc4244bis: what is an AoR?

	No not really, it is only different application retrieving different bits of information. What is important is that they can extract this information.

	/Hans Erik van Elburg

	On Sat, Jul 18, 2009 at 6:11 PM, Hadriel Kaplan <[email-masked]> wrote:

		Doesn’t it seem wrong/dangerous to you that one application would use the “mp” flagged entry as a target, while another application uses the “aor” flagged entry as a target?  I mean really they’re all looking for “targets”, right?  One’s just looking for the “last redirected-to” target, and the other’s looking for the “last resolved-to” target.  No?

		The point made by Francois in one of the emails (which made a lot of sense to me) was that you basically had to use the “aor” ones because anything else is just that local proxy’s view of what its routing to, including any locally-specific “ugliness”, pre-translation et al; whereas the “aor” one was what the actual targeted domain saw and used for location-service resolution and therefore was “authoritative”.

		-hadriel

		To: Hadriel Kaplan

		/Hans Erik van Elburg

		-hadriel

		inline...
		/Hans Erik van Elburg

		

		 

			
			-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 21 Jul 2009 21:07:47 +0100

> Sent: 21 July 2009 18:46

Francois,

I'm confused, because I thought you were arguing that it was not an AOR
in this redirection case. I had originally postulated that in most cases
all but the last H-I entry would be marked AOR, and you cited this as an
example where it wouldn't be marked as an AOR. But now you agree it
would be marked as an AOR, which seems to support my original
hypothesis.

John

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 21 Jul 2009 15:59:09 -0500

Re-reading this (again). 

I don't believe 10.10.15.12 fits the "domain" criteria in the definition
of AOR. So it would not be an AOR.

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Tuesday, July 21, 2009 13:08
> To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Paul Kyzivat
> I'm confused, because I thought you were arguing that it was 
> not an AOR in this redirection case. I had originally 
> postulated that in most cases all but the last H-I entry 
> would be marked AOR, and you cited this as an example where 
> it wouldn't be marked as an AOR. But now you agree it would 
> be marked as an AOR, which seems to support my original hypothesis.
> 
> John
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 22 Jul 2009 07:20:08 +0100

Many deployments today use IP address instead of domain (e.g., for a
SIP-PBX), so are we saying that any URIs with a SIP-PBX IP address, say,
are not AORs? This seems to underline the point that the RFC 3261
definition of AOR seems to be open to different interpretations.

John 

> Sent: 21 July 2009 21:59

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 22 Jul 2009 09:35:20 +0200

Assuming that you are talking about "- if no "mp" found take the first H-I
entry"
Then I really ment the first from teh begionning, as in this case no mapping
occured the first entry must be the best guess for the addressed target.

/Hans Erik van Elburg

On Tue, Jul 21, 2009 at 7:54 PM, Francois Audet <[email-masked]> wrote:

> *Sent:* Friday, July 17, 2009 23:55
> *To:* Hadriel Kaplan
> *Cc:* Audet, Francois (SC100:3055); Paul Kyzivat; SIPCORE
>
>> In a previous chain of emails I thought the purpose of the “mp” flag was
>> to indicate a retarget happened, but that the subsequent “aor” flagged URI
>> was what would actually be used for applications, because it is the
>> “cleaned-up” form of the URI being retargeted to, since it actually
>> identifies what the authoritative domain which got it claims it
>> location-service routed with.
>>
>>
>>
>> Your response indicates that the “mp” flagged URI would actually be used
>> by the application, even when it does not have an “aor” flag (as it would
>> not in this case).
>>
>>
>>
>> No. The aor tag has nothing todo with the freephone case, for that case
>> the "mp" tag or in its absence  the first H-I entry is important to be able
>> to determine the original called target.
>>
>>
>>
>>
>>
>>
>>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 22 Jul 2009 09:40:40 +0200

I'm confused to what is the question here, are we talking about a UAS or a
proxy?
/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 22 Jul 2009 08:49:38 +0100

Hans Erik,

When the subject came up we were talking about redirect servers, i.e.,
anything that issues a 3xx response. This may or may not be a device
that acts as a UAS for some requests.

So if I receive sip:[email-masked] and redirect it elsewhere, was
that URI an AOR or not? According to the RFC 3261 definition that
Francois cited, I think it is, i.e., I look up the URI in my location
server, find a contact and redirect to it.

John

> Sent: 22 July 2009 08:41
> Cc: Francois Audet; Paul Kyzivat; SIPCORE; Hadriel Kaplan
> I'm confused to what is the question here, are we talking 
> about a UAS or a proxy? 
> 
> /Hans Erik van Elburg
> 
> 
> 
> On Wed, Jul 22, 2009 at 8:20 AM, Elwell, John 
> 	> > From: Elwell, John 
> [mailto:[email-masked]]

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 22 Jul 2009 11:23:12 +0200

Yes your right.
This might be a nasty case, as it would result in the wrong aor being
retrieved by the next UAS being redirected to.

This could be resolved by not letting redirect servers tag aor's, but only
let proxies responsible for the domain do that.

/Hans Erik van Elburg

On Wed, Jul 22, 2009 at 9:49 AM, Elwell, John <
[email-masked]> wrote:

> So if I receive sip:[email-masked] <[email-masked]> and
> redirect it elsewhere, was

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 22 Jul 2009 09:06:21 -0500

No, it points to the fact that people don't follow RFC 3261 properly.

Perhaps the best thing to do is saying that "Some domains use
IP address(es) as domain names; in this case URIs with domain
names can be marked with the "aor" tag. Domains that use proper
DNS domain names instead of IP addresses would not mark 
URIs with IP addresses as domains with the "aor" tag."

PS: There is another alternative. We could stick to the rule
of using proper domain names for AORs. But then, UAs would have
to use them in Request-URIs, To and From, and if they want to avoid
DNS, then they'd have to use Route header (or maddr). That is cleaner,
but it a bigger change for existing deployments.

> Sent: Tuesday, July 21, 2009 23:20
> Many deployments today use IP address instead of domain 
> (e.g., for a SIP-PBX), so are we saying that any URIs with a 
> SIP-PBX IP address, say, are not AORs? This seems to 
> underline the point that the RFC 3261 definition of AOR seems 
> to be open to different interpretations.
> 
> John 
> 
> > I don't believe 10.10.15.12 fits the "domain" criteria in the 
> > definition of AOR. So it would not be an AOR.
> > 
> >  
> > 
> > > > > > In this case, you'll have an entry in the middle
> > > > > > ([email-masked]) that is not an AOR.
> > > I'm confused, because I thought you were arguing that it 
> was not an 
> > > AOR in this redirection case. I had originally postulated that in 
> > > most cases all but the last H-I entry would be marked 
> AOR, and you 
> > > cited this as an example where it wouldn't be marked as 
> an AOR. But 
> > > now you agree it would be marked as an AOR, which seems 
> to support 
> > > my original hypothesis.
> > > 
> > > John
> > > 
> > 
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 22 Jul 2009 15:42:31 +0100

Francois,

I think you are saying that we must make a distinction between domain
names and host names, and likewise between IP addresses associated with
domain names and IP addresses associated with host names. So a request
aimed at sip:[email-masked], when redirected or forwarded, would be
marked as an AOR if example.com is a domain name but not if example.com
is a host name. Similarly for sip:[email-masked], depending on
whether it represents a domain name or a host name. Do I understand you
correctly?

John

> Sent: 22 July 2009 15:06

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 22 Jul 2009 10:18:35 -0500

Yes, and also, as per Hans' previous mail, the domain in question that
marks the entry as aor MUST be the one who owns the IP address.

You are correct.

Makes sense? 

> Sent: Wednesday, July 22, 2009 07:43
> I think you are saying that we must make a distinction 
> between domain names and host names, and likewise between IP 
> addresses associated with domain names and IP addresses 
> associated with host names. So a request aimed at 
> sip:[email-masked], when redirected or forwarded, would be 
> marked as an AOR if example.com is a domain name but not if 
> example.com is a host name. Similarly for 
> sip:[email-masked], depending on whether it represents 
> a domain name or a host name. Do I understand you correctly?
> 
> John
> 
> > Perhaps the best thing to do is saying that "Some domains use IP 
> > address(es) as domain names; in this case URIs with domain 
> names can 
> > be marked with the "aor" tag. Domains that use proper DNS 
> domain names 
> > instead of IP addresses would not mark URIs with IP addresses as 
> > domains with the "aor" tag."
> > 
> > PS: There is another alternative. We could stick to the 
> rule of using 
> > proper domain names for AORs. But then, UAs would have to 
> use them in 
> > Request-URIs, To and From, and if they want to avoid DNS, 
> then they'd 
> > have to use Route header (or maddr). That is cleaner, but 
> it a bigger 
> > change for existing deployments.
> > 
> (e.g., for a 
> > > SIP-PBX), so are we saying that any URIs with a SIP-PBX 
> IP address, 
> > > say, are not AORs? This seems to underline the point that the RFC 
> > > 3261 definition of AOR seems to be open to different 
> > > interpretations.
> > > 
> > > John
> > >

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 22 Jul 2009 10:14:38 -0500

Why would you use the first???
 
It seems to me the last is more likely to be useful. E.g., I call sip:[email-masked]. I get redirected to sip:[email-masked];confnumber=87365352.
 
The useful target URI is the last one, not the first one.
 
Anyways, I guess it points to the fact of WHY we NEED H-I for target URI if there are use cases for first and use cases for last entry, for example...

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: Wednesday, July 22, 2009 00:35
	To: Audet, Francois (SC100:3055)
	Cc: Hadriel Kaplan; Paul Kyzivat; SIPCORE
	Subject: Re: [sipcore] rfc4244bis: what is an AoR?

	Assuming that you are talking about "- if no "mp" found take the first H-I entry" 

	Then I really ment the first from teh begionning, as in this case no mapping occured the first entry must be the best guess for the addressed target.

	/Hans Erik van Elburg

			

			/Hans Erik van Elburg

				-hadriel

				 

				inline...
				/Hans Erik van Elburg

				

				 

					
					-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 22 Jul 2009 23:57:15 -0500

Hi all,

In preparation for the meeting next week, I'm writting a Summary of where we
are with draft-barnes-sipcore-rfc4244bis and target-URI with regards to 
mailing list discussions.

target-URI draft:

	The authors have stopped updating the target-URI to focus their 
	energies on the 4244bis draft instead.

	The idea is that once we solve the issues remaining with 4244bis,
	targetURI will be realigned with 4244bis. This means that the
	nature of targetURI draft may change: it could become a "use
	case" illustating use cases and call flows for various target
	URI scenarios.

	So participants are invited to NOT to read the target-URI draft.

aor tag: 

	It seems that after much discussion on mailing list, after much initial
	confusion, people came around and agree that the definition from the draft does
	make sense, and does represent an AOR, as per the meaning in RFC 3261.

	Specifically, a URI entry is marked as "aor" when a proxy responsible for
	the URI recognizes it as an AOR (i.e., it uses it for a location server dip).

	One question asked on the list is how to treat IP addresses as domains?
	Can entries using IP addresses be AORs?

	The answer to that question is that when a domain uses an IP address
	as a domain name instead of a proper DNS domain name, yes, it can
	be considered an AOR. This will need to be clarified in an upcoming version.

	We might want to confirm this in Stockholm. There appears to be no other
	open issues regarding the aor tag.

rc / cc / rt tags: 

	These where created to be "precise" in their definition (i.e., mechanical), 
	but it appears that they all represent "fluff". In other words, they are not 
	normally used by algorithms. One idea being considered is "grouping" them 
	together under a single "fluff" tag (proper name to be determined). 
	No strong opinion against the grouping idea. 

	Another approach suggested was to not mark them at all (i.e., no tag).
	The concern about this approach is that in the current model, all
	rfc4244bis proxies/redirect servers will mark ALL entries, while
	RFC 4244 (old) will not, thereby allowing for distinguishing the entries,
	and allowing backward compatibility. We would therefore need to define
	another mechanism in parallel for each entry (e.g., another tag?) for 
	backward compatibility.

	Yet another approach (suggested last meeting), was to not include the
	"fluff" items at all. Again, this suffers from backward compatibility
	issues. There wasn't much discussion of this particular approach on 
	the list.

	A resolution for this particular issue, i.e., "rc/cc/rt" vs "fluff" vs
	"no tag" vs "no entry" is required. Seems like a good topic for Stockholm.

mp tag: 

	In the current draft, the "mp" tag represent the "mapped-TO" address, 
	not the mapped-FROM address. Unlike the "fluff" parameters, it means a 
	"user different from the previous one". 

target-URI algorithm for UAS:

	There were some questions on the list about algorithms for picking
	the "target URI parameter: is it the last "mp"-marked tag or is it
	the last "aor" tag. It seems that the answer to this question may
	be different based on what the assumptions people have about what
	is in fact a "target URI". It is not clear if we need to describe
	this in the draft, or even indeed if it actually makes a
	difference.

privacy: 

	RFC 3323 was written with a 2-party model. Some of the wording in 
	the documents was changed from 4244 to adapt to individual 
	H-I entries.

	It is not clear if further enhancements to RFC 3323 are required.
	We are inviting people to look at it.

I believe this is it.

Thanks.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Jul 2009 08:18:08 +0100

> [mailto:[email-masked]] On Behalf Of Francois Audet
> Sent: 23 July 2009 05:57
> To: SIPCORE
> Subject: [sipcore] draft-barnes-sipcore-rfc4244bis & 
> target-URI: Summary ofwhere we are
> 
> Hi all,
> 
[JRE] It might also be worth mentioning that there was discussion about
redirects. My understanding was that a redirecting entity could also
mark a URI as an AOR.

> 	"user different from the previous one". 
[JRE] So when I query my location server and get back a new URI, how do
I know whether it represents a different user?

[JRE] So (ignoring v1 systems), we can receive URIs with the following
tags:
- 'mp' and 'aor'
- 'mp' and not 'aor'
- 'fluff' and 'aor'
- 'fluff' and not 'aor'
I don't recall seeing anything that describes what each of these 4
possibilities means.

John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 23 Jul 2009 09:59:11 +0200

As the tags have clearly defined meanings and they are orthogonal, finding
two tags on an entry does not alter their meaning. So there is no need to
define the meanings of combinations.

"mp" means that the entry has been added to teh history due to some
mapping-translation. And "aor" means  that the entry has been input to
retarget operation by a proxy that was responsible for the uri in the
entry.

/Hans Erik van Elburg

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 23 Jul 2009 10:04:50 +0200

As said before the algorithms for a UAS are very clear.
To retrieve the addressed target (freephone, etc) (Main thing that
target-uri draft was after.):
- traverse all H-I entries backward until an "mp" entry is found, if found
this is the addressed target
- if no "mp" found take the first H-I entry
- if no History-Info header take the Request-URI value

Both values can be the same in a lot of situations. But they will not always
be.

/Hans Erik van Elburg

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Jul 2009 09:34:56 +0100

> Sent: 23 July 2009 09:05
> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & 
> target-URI: Summaryof where we are
> 
> To retrieve the addressed target (freephone, etc) (Main thing 
> that target-uri draft was after.): 
> - traverse all H-I entries backward until an "mp" entry is 
> found, if found this is the addressed target
[JRE] Would it not be better to use the To URI in this case? The
Request-URI is very unlikely to contain the addressed target.

> - traverse all H-I entries backward until an "aor" entry is 
> found, if found this is the last AOR used
[JRE] And if none found?

> 
> Both values can be the same in a lot of situations. But they 
> will not always be.
[JRE] A common situation might be as follows. Caller dials freephone
number (or group number, or whatever). Proxy resolves this to an AOR,
and because that same proxy is responsible for that domain, it resolves
it further to a contact URI. If the proxy populates H-I with both the
AOR and the contact URI, the algorithm above would work. However, I
don't think there is anything in the document to mandate that, so a
simple implementation would only insert the contact URI (assuming the
freephone number is already there). I don't think either H-I entry would
be marked as either AOR or MP in this case, would they?

John

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 23 Jul 2009 10:44:29 +0200

inline as [HE]...

/Hans Erik van Elburg

> Request-URI is very unlikely to contain the addressed target.
[HE] Not sure To URI is also very unreliable. Maybe we should say in that
case that  the addressed target could not be determined reliably.

> > found, if found this is the last AOR used

[HE] Then the info is not available.

> be marked as either AOR or MP in this case, would they?
[HE] I think they would. I believe the 4244bis and also 4244 explicitly
require internal retargets to also be recorded.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jul 2009 09:22:03 -0400

Hans Erik van Elburg wrote:
> Both values can be the same in a lot of situations. But they will not 
> always be.

I'm confused here. IIUC there has been a change to that the 'mp' tag 
marks the "mapped to" URI rather than the "mapped from" URI. If so then 
I don't see how the two are likely to be interchangable in many if any 
cases. If 'mp' marks the "mapped from" URI then I guess there would be a 
lot of equivalence.

	Thanks,
	Paul

> /Hans Erik van Elburg
> 
> 
> On Thu, Jul 23, 2009 at 6:57 AM, Francois Audet <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 23 Jul 2009 15:34:35 +0200

Not sure what you mean with interchangeability. Only thing I said is that
both algorithms may often result in returning the same URI. In a lot of
cases they will not, as they are retrieving different type of information.
/Hans Erik van Elburg

On Thu, Jul 23, 2009 at 3:22 PM, Paul Kyzivat <[email-masked]> wrote:

>> target-uri draft was after.): - traverse all H-I entries backward until an
>> "mp" entry is found, if found this is the addressed target
>> To retrieve the last aor before it was overwritten by contact address
>> (similar as P-Called-Party-ID): - traverse all H-I entries backward until an
>> "aor" entry is found, if found this is the last AOR used
>>
> I'm confused here. IIUC there has been a change to that the 'mp' tag marks
> the "mapped to" URI rather than the "mapped from" URI. If so then I don't
> see how the two are likely to be interchangable in many if any cases. If
> 'mp' marks the "mapped from" URI then I guess there would be a lot of
> equivalence.
>
>        Thanks,
>        Paul
>
>  /Hans Erik van Elburg
>>
>>
>> On Thu, Jul 23, 2009 at 6:57 AM, Francois Audet <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 23 Jul 2009 11:08:46 -0500

To URI is almost always not reliable.

	From: Hans Erik van Elburg [mailto:[email-masked]] 
	Sent: Thursday, July 23, 2009 01:44
	To: Elwell, John
	Cc: Audet, Francois (SC100:3055); SIPCORE
	Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summaryof where we are

	inline as [HE]...

	/Hans Erik van Elburg

		

	[HE] Not sure To URI is also very unreliable. Maybe we should say in that case that  the addressed target could not be determined reliably.

		[JRE] And if none found?

		

	[HE] I think they would. I believe the 4244bis and also 4244 explicitly require internal retargets to also be recorded.

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 23 Jul 2009 11:34:02 -0500

> [JRE] It might also be worth mentioning that there was 
> discussion about redirects. My understanding was that a 
> redirecting entity could also mark a URI as an AOR.

No. Those are orthogonal.

The rule is clear: the entity that recognizes the entry as an
AOR it is responsible for does the marking.

So, if I redirect an incoming session from sip:[email-masked]
to sip:[email-masked], I will add an entry so
it will look like this:

History-Info: <sip:[email-masked]>;rt;aor;index=1 
History-Info: <sip:[email-masked]>;mp;index=1.1

Then, when YOUR proxy receives the request, it will mark it
as aor and then route it to you. It will look like this:

History-Info: <sip:[email-masked]>;rt;aor;index=1
History-Info: <sip:[email-masked]>;mp;aor;index=1.1 
History-Info: <sip:[email-masked]>;rc;index=1.1.1

See the call flows in draft.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Jul 2009 18:10:05 +0100

> Sent: 23 July 2009 17:34
> To: Elwell, John; SIPCORE
> Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis & 
[JRE] Exactly - as part of redirection you have marked your H-I entry as
AOR. So I don't understand why you said "no" above.

John

> History-Info: 
> <sip:[email-masked]>;mp;aor;index=1.1

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 23 Jul 2009 12:27:56 -0500

> > So, if I redirect an incoming session from sip:[email-masked] to 
> > sip:[email-masked], I will add an entry 
> so it will 
> > look like this:
> > 
> [JRE] Exactly - as part of redirection you have marked your 
> H-I entry as AOR. So I don't understand why you said "no" above.

Because I (i.e., my UAC) has NOT marked it. My proxy did.
        ^

If my UAC had included the entry (which is legal, but uncommon), there would
be no aor tag:

  History-Info: <sip:[email-masked]>;rt;index=1

Then, my proxy "recognizes it as an aor it owns" and adds the aor tag:

                                          ^^^

Since in typical deployments, UACs don't include History-Info, the two steps above
are done by the proxy.

This is why in the new procedures in the draft, the steps are clearly defined in
sequence, i.e., 

1 - Proxy adds previous entry on behalf of UAC if not present
2 - Proxy adds aor tag to previous entry if it recognizes URI a AOR it 
    is responsible for
3 - Proxy adds new entry for new target

Makes sense?

---

From: "Ian Elz" <[email-masked]>
Date: Fri, 24 Jul 2009 15:23:06 +0200

Francois,

I don't get to attend the IETF but your input on the privacy appear to
cover the current situation.

The only issue for 4424bis is to ensure that no changes are made which
would preclude any future changes for 3rd party privacy. I would hate to
have to come back with another revision to change something that with
care now we could avoid. I don't think that there is anything at present
which falls into this scenario.

Enjoy Stockholm, it is a great place to visit (in summer).

Ian 

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: 23 July 2009 05:57
To: SIPCORE
Subject: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary
ofwhere we are

Hi all,

In preparation for the meeting next week, I'm writting a Summary of
where we are with draft-barnes-sipcore-rfc4244bis and target-URI with
regards to mailing list discussions.

target-URI draft:

	The idea is that once we solve the issues remaining with
4244bis,
	targetURI will be realigned with 4244bis. This means that the
	nature of targetURI draft may change: it could become a "use
	case" illustating use cases and call flows for various target
	URI scenarios.

aor tag: 

	It seems that after much discussion on mailing list, after much
initial
	confusion, people came around and agree that the definition from
the draft does
	make sense, and does represent an AOR, as per the meaning in RFC
3261.

	Specifically, a URI entry is marked as "aor" when a proxy
responsible for
	the URI recognizes it as an AOR (i.e., it uses it for a location
server dip).

	One question asked on the list is how to treat IP addresses as
domains?
	Can entries using IP addresses be AORs?

	The answer to that question is that when a domain uses an IP
address
	as a domain name instead of a proper DNS domain name, yes, it
can
	be considered an AOR. This will need to be clarified in an
upcoming version.

	We might want to confirm this in Stockholm. There appears to be
no other
	open issues regarding the aor tag.

rc / cc / rt tags: 

	These where created to be "precise" in their definition (i.e.,
mechanical), 
	but it appears that they all represent "fluff". In other words,
they are not 
	normally used by algorithms. One idea being considered is
"grouping" them 
	together under a single "fluff" tag (proper name to be
determined). 
	No strong opinion against the grouping idea. 

	Another approach suggested was to not mark them at all (i.e., no
tag).
	The concern about this approach is that in the current model,
all
	rfc4244bis proxies/redirect servers will mark ALL entries, while
	RFC 4244 (old) will not, thereby allowing for distinguishing the
entries,
	and allowing backward compatibility. We would therefore need to
define
	another mechanism in parallel for each entry (e.g., another
tag?) for 
	backward compatibility.

	Yet another approach (suggested last meeting), was to not
include the
	"fluff" items at all. Again, this suffers from backward
compatibility
	issues. There wasn't much discussion of this particular approach
on 
	the list.

	A resolution for this particular issue, i.e., "rc/cc/rt" vs
"fluff" vs
	"no tag" vs "no entry" is required. Seems like a good topic for
Stockholm.

mp tag: 

	In the current draft, the "mp" tag represent the "mapped-TO"
address, 
	not the mapped-FROM address. Unlike the "fluff" parameters, it
means a 
	"user different from the previous one". 

	There were some questions on the list about algorithms for
picking
	the "target URI parameter: is it the last "mp"-marked tag or is
it
	the last "aor" tag. It seems that the answer to this question
may
	be different based on what the assumptions people have about
what
	is in fact a "target URI". It is not clear if we need to
describe
	this in the draft, or even indeed if it actually makes a
	difference.

privacy: 

	RFC 3323 was written with a 2-party model. Some of the wording
in 
	the documents was changed from 4244 to adapt to individual 
	H-I entries.

	It is not clear if further enhancements to RFC 3323 are
required.
	We are inviting people to look at it.

I believe this is it.

Thanks.

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 24 Jul 2009 10:35:20 -0500

Ok, thanks.

I'm glad you are ok with the Privacy material. 

> From: Ian Elz [mailto:[email-masked]] 
> Sent: Friday, July 24, 2009 06:23
> I don't get to attend the IETF but your input on the privacy 
> appear to cover the current situation.
> 
> The only issue for 4424bis is to ensure that no changes are 
> made which would preclude any future changes for 3rd party 
> privacy. I would hate to have to come back with another 
> revision to change something that with care now we could 
> avoid. I don't think that there is anything at present which 
> falls into this scenario.
> 
> In preparation for the meeting next week, I'm writting a 
> Summary of where we are with draft-barnes-sipcore-rfc4244bis 
> and target-URI with regards to mailing list discussions.
> 
> target-URI draft:
>