Subject: [Enum] Re: draft-enum-sip-00.txt - AoRs

From: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Sun, 9 Mar 2003 22:39:56 +0000

Hi Jon, folks,
As the authors have tried to indicate over the chain of postings on 
the 'vovi' draft, we agree that all AoRs are not *intrisically* 
associated with a capability. However, we believe that an AoR may be 
*administratively* associated with a capability, and have described 
how this may happen through beurocratic choice.

In the process of this discussion, I have had cause to read the 'sip' 
draft in some detail, and to attempt to explain it to others. I'm not 
sure I understand it fully, hence::

 From the discussions so far, I understand that a device may register 
with a proxy when it boots or goes online. Thus it will have its own 
AoR; one associated purely with that device.

Thus, I would argue that, in practice, dynamic associations may also 
be made between two independent AoRs; one tied to a device when it 
registers, with another tied to the end user who has registered their 
presence on this device *or has associated themselves with this 
device's AoR*. Section 3 of the 'sip' draft seems to skip mention of 
this association (device AoR with User AoR) in its attempts to imply 
(quite rightly) that contact addresses are not useful for ENUM.

Note that, if the device registers on boot, it will have an AOR. 
Assuming that this device does have a given capability, this 
conflicts the suggestion in the 'sip' draft that AoRs NEVER have an 
associated capability, and that capabilities are ONLY associated with 
contact addresses. Some AoRs are capability-independent, or are 
associated with varying capability, whilst others are associated with 
devices that have a stable capability set.

Is this correct, or am I missing something in the 'sip' draft?

all the best,
   Lawrence
-- 
-----------------------------------------------------------------------
Roke Manor Research    : This information is provided "as is" and is not
<mailto:[email-masked]>: intended to create any contractual or legal
<tel:+441794833666>    : relationship.
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 10 Mar 2003 05:06:18 -0500

A little more below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) [mailto:[email-masked]]
> Sent: Sunday, March 09, 2003 2:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: draft-enum-sip-00.txt - AoRs
> 
> 
> Hi Jon, folks,

Um, that's not what I meant, no. I have an address-of-record,
sip:[email-masked]. When my devices (like my Cisco phone) boot, they
all register their contact address (a device-specific URI) under that AoR.
My AoR is not specific to that device; any number of devices may register
there - my phone doesn't have its own AoR. I'd point you to section 10 of
RFC3261 where the concepts of AoR and contact addresses are discussed.

> (quite rightly) that contact addresses are not useful for ENUM.

This analysis isn't very clear to me from a SIP perspective. A dynamic
association exists between the device's contact address and the AoR (which
is 'tied' to the end user). When a user uses a device, it registers under
their AoR. You could, for example, come over to my SIP phone, configure your
registrar and your credentials, and register from my device. Then my device
would be available through your AoR. In other words, registering your
presence on a device, and the registration of a device, are identical in SIP
terms (again, see RFC3261 section 10) - I'm not sure what distinction you're
drawing above. I think my draft is commensurable with the practices in
RFC3261.

> devices that have a stable capability set.

Again, devices don't have AoRs, they have contact addresses (that's what a
device URI is). AoRs are essentially pointers to a user, not a device.
They're capability-independent necessarily.