Subject: [Sipping] GRUU Issue: who did I call?

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jan 2005 11:00:20 -0500

At various times over the last several months I have had side 
conversations about problems with GRUUs. This came up most recently in 
the "modeling dispatchers in the data model" thread.

A significant issue that has been brought up is:

To an outside observer, including the client using it, a GRUU may well 
have a form that doesn't correlate in any apparent way to who was 
called. And the timespan over which a GRUU remains valid may be very 
bounded.  This could have at least two effects:

- when reviewing a history of past calls, (e.g. a bill), it may be
   impossible to determine "who did I call?".

- Sending a new request to the old GRUU may well also not work.
   This negates the experimental approach to answering the "who did
   I call?" question, and also other usages, such as "I want to ask
   one more question of that guy Alice forwarded me to yesterday."

This issue has been identified in the context of using GRUUs as the 
contact addresses in PIDF tuples. But it applies equally to GRUUs used 
in other contexts, such as call transfer.

I think this subject deserves attention, so I want to kick off some 
discussion on the subject.

==================

I don't think it means GRUUs are a bad idea. But it does mean that more 
information needs to be captured for historical purposes. We need to 
figure out what that is.

In some cases there are conflicting objectives:
- obfuscation of the callee identity may be intentional
- bounding the reachability of the callee may be intentional

In other cases this may not be so. E.g. in the case of presence there 
typically in no reason to hide who this is about - the presence document 
  is there to make it explicit.

Even when the callee is not interested in cooperating, the caller 
typically has some context that can help - at least to qualify who the 
target was and possibly to obtain a callable address even if the gruu 
itself has become invalid.

One partial answer would be to come up with a recommended way to encode 
GRUUs so that the AoR is retrievable by anyone. This would of course 
have to be optional for the cases where obfuscation is desired.

Solutions that don't require cooperation are also needed. For instance, 
when calling an address retrieved from a PIDF document, it would be very 
helpful to include the presentity address somewhere in the request, 
where it could be captured and stored as part of the call detail.

Similarly, when acting on a REFER, it might be helpful to ensure that 
info about the referror is associated with the resulting request. (This 
may already be sufficiently addressed.)

	Thoughts?
	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: David R Oran <[email-masked]>
Date: Fri, 21 Jan 2005 12:04:19 -0500

Naive question - isn't the only way to answer the "who did I call" 
question is "the AoR"? I think that means it's incumbent on the Calling 
UAC to keep track of which GRUUs have been associated with which AoRs. 
I suspect this is no different than trying to base call logs and other 
similar things on contact addresses alone, which we know won't work. If 
the problem is that some interactions can't be tied to an AoR that does 
strike me as a serious problem and one deeper than just the 
introduction of GRUUs.

On your second point, If GRUUs time out there may be a good reason 
(e.g. bound the time you can use this handle to send me a request), but 
if there isn't a good reason then it behooves us to enforce that GRUUs 
by default have a temporal validity equal to that of the associated 
AoR.

If I'm completely missing the boat here excuse me and try again to 
explain the problem.

On Jan 21, 2005, at 11:00 AM, Paul Kyzivat wrote:

> I don't think it means GRUUs are a bad idea. But it does mean that 
> more information needs to be captured for historical purposes. We need 
> to figure out what that is.
>
> typically in no reason to hide who this is about - the presence 
> document  is there to make it explicit.
>
> One partial answer would be to come up with a recommended way to 
> encode GRUUs so that the AoR is retrievable by anyone. This would of 
> course have to be optional for the cases where obfuscation is desired.
>
> Solutions that don't require cooperation are also needed. For 
> instance, when calling an address retrieved from a PIDF document, it 
> would be very helpful to include the presentity address somewhere in 
> the request, where it could be captured and stored as part of the call 
> detail.
>
> info about the referror is associated with the resulting request. 
> (This may already be sufficiently addressed.)
>
> 	Thoughts?
> 	Paul
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jan 2005 13:36:41 -0500

David R Oran wrote:
> UAC to keep track of which GRUUs have been associated with which AoRs. I 

That is one answer, to at least part of the problem. But it presumes 
some things:

- For the calling UAC to do it, it must have the AoR. In case of
   presence, that's pretty easy. In cases like call transfer, it
   may not be available as things stand.

- Having UAC do it is straightforward if it has it and the UAC is
   the one keeping the records. But if the records are being kept
   in the network somewhere (e.g. billing records for calls), this
   may be a problem because the UAC may have no well defined way to
   convey this info to the place where it is recorded.

> suspect this is no different than trying to base call logs and other 

Depends on how the call was initiated, and where in the call path the 
info is captured. If the call was initially to the AoR, then that is in 
the To header and can be captured by anyone on the path. But if the call 
was originally to the GRUU (perhaps as result of REFER), then it will 
probably be in the To as well.

> strike me as a serious problem and one deeper than just the introduction 
> of GRUUs.

Yes. Some of this is broader than GRUUs. For instance, If Alice calls 
Bob but is forwarded to Charlie, what does call log show? What should it 
show? If next month Alice wants to followup, is there some way to get to 
Charlie directly, rather than Bob?

> On your second point, If GRUUs time out there may be a good reason (e.g. 
> bound the time you can use this handle to send me a request), but if 
> there isn't a good reason then it behooves us to enforce that GRUUs by 
> default have a temporal validity equal to that of the associated AoR.

There has been some hesitation to require this, because it imposes a 
strong constraint on how GRUUs are implemented. But I think I agree that 
some kind of constraint or guidance here would be useful. I'm suggesting 
that in absence of reasons to contrary, the GRUU be constructed so that 
the AoR can be derived from it. For instance this could be achieved if 
the GRUU was just an AoR with a special URI parameter. Then the AoR 
could be retrieved by just removing the parameter.

> If I'm completely missing the boat here excuse me and try again to 

No, you are not. This isn't rocket science. Its stuff that has been 
sitting there staring us in the face. But unless I am missing something, 
it also isn't a solved problem.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 21 Jan 2005 14:26:19 -0600

On Jan 21, 2005, at 11:04 AM, David R Oran wrote:

> question is "the AoR"?

Actually, there are three questions to consider:

1) Who did I reach?

2) By what mechanism or address did I reach them?

3) How might I go about reaching them again?

#1 argues for the completion of Response Identity work.

#2 is arguably a GRUU, or an AoR, or a Contact, or something 
indefinite, including possibly an execution sequence involving all of 
the above plus Request History.

#3 argues for inclusion of an AoR for future reference in the Response 
Identity.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Jan 2005 15:42:36 -0500

Dean Willis wrote:
> #2 is arguably a GRUU, or an AoR, or a Contact, or something indefinite, 
> including possibly an execution sequence involving all of the above plus 
> Request History.
> 

These are all good points. They are subtly different from "who did I 
call?" It is a relevant question even if I reached somebody different 
from that. But if I had 1-3 I might not feel much need for this.

I think the response identity work may still be some ways off, and 
deployment probably much further. And even then there will be many who 
simply won't want to provide it. In that case I still want some useful 
approximation to "who did I call".

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 23 Jan 2005 18:24:21 -0800

Hmm - this looks like it might be going down the path of confusing user
Identity in things like To and From with things that go in the contact or
via header.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Jan 2005 23:02:17 -0500

> Identity in things like To and From with things that go in the contact or

I don't think the cases I am thinking of do. Consider the simple case of:

- I check presence of sip:[email-masked]

- I pick a tuple from that. It has a contact of
   sip:[email-masked]

- I call that.

- A month later, looking back at the call records, I wonder what I
   was calling.

That does show how certain behavior by the UAC could help. If it just 
put the presentity address in the To, and the contact address from the 
tuple in the R-URI, then maybe the right info would be retained.

That violates my expectation that the UAC will start out with To and 
R-URI the same, but in this case it makes sense.

	Paul

---

From: "Mike Hammer" <[email-masked]>
Date: Tue, 25 Jan 2005 10:52:11 -0500

Paul,

Keep in mind that the "traditional" view was that the person transferring
the call would be the one to pay for the call.  While in SIP, the new call
is direct from the original caller to the endpoint, you may still want to
keep that billing convention possible.  For that, some type of charge number
(rather than AoR) would be more appropriate for privacy reasons.

Second, in many cases, the reason you called the first party (i.e. a
secretary) was to intentaionally insert a gatekeeper to protect the boss
from unwanted, disruptive calls.  So, making the "who I go connected to" AoR
available may constitue a breach of privacy.

Much of what you are pondering is analagous to the Connected Line
Indentification Presentation (COLP) and Restreiction (COLR).  As a result,
the temporary, random/anonymouse, non-reusable nature of the GRUU is a
feature not a drawback.  I would suggest that the extension of the
Privacy-Asserted-Identity work to cover connected parties, or some new
capability is more in line with what you are searching for.

Hopefully this fleshes out the problem a little more.

Mike

   >-----Original Message-----
   >From: [email-masked] 
   >[mailto:[email-masked]] On Behalf Of Paul Kyzivat
   >Sent: Sunday, January 23, 2005 11:02 PM
   >To: Cullen Jennings
   >Cc: sipping
   >Subject: Re: [Sipping] GRUU Issue: who did I call?
   >
   >
   >
   >Cullen Jennings wrote:
   >> 
   >> Hmm - this looks like it might be going down the path of 
   >confusing 
   >> user Identity in things like To and From with things that 
   >go in the 
   >> contact or via header.
   >
   >That does show how certain behavior by the UAC could help. 
   >If it just put the presentity address in the To, and the 
   >contact address from the tuple in the R-URI, then maybe the 
   >right info would be retained.
   >
   >That violates my expectation that the UAC will start out 
   >with To and R-URI the same, but in this case it makes sense.
   >
   >	Paul
   >
   >>>the request, where it could be captured and stored as 
   >part of the call detail.
   >>>
   >>>Sipping mailing list  
   >https://www1.ietf.org/mailman/listinfo/sipping
   >>>This list is for NEW development of the application of SIP Use 
   >>>[email-masked] for questions on current sip Use 
   >>>[email-masked] for new developments of core SIP
   >> 
   >> 
   >
   >Use [email-masked] for questions on 
   >current sip Use [email-masked] for new developments of core SIP
   >

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jan 2005 18:49:50 -0500

> Hopefully this fleshes out the problem a little more.

Mike. The points you make above do apply to some of the cases, but not 
all of them. The use in presence is the case that first stimulated this 
issue, and maybe it was wrong to try to over-generalize it.

What are your thoughts on the presence case below?

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Wed, 26 Jan 2005 14:41:57 +0200

Hi Paul,

Thanks for bringing this issue up.

I've had a doubt about using GRUUs in the presence context, and 
admittedly haven't perhaps expressed clearly why. The problem you 
outline is one of the reasons why. When we say GRUU, we should really be 
saying AoR (plus a gruuness token).

I think what is required is that we split an AoR into a hierarchy. 
Meaning that an AOR describes an entity, which may optionally have a set 
of "resources" that if necessary can be directly addressed. Contact 
addresses could be registered for AoRs directly, or under GRUUs. I don't 
know any other way to express this than a figure.

Instead of what we currently have:

                            +-------------+
                            |             |
                            |             |
                            |    GRUU     |----------------------+
                            |             |                      |
                            |             |                      |
                            +-------------+                      |
                                   | 0..1                        |
                                   |                             |
                                   | associated-with             |
                                   |                             |
                                   |                             |
                                   | 1                           |
                           +----------------+                    |
                           |                |                    |
                  +--------|  instance ID/  |------+             |
                  |        |    AOR Pair    |      |             |
                  |        |                |      |             |
                  |        +----------------+      |             |
                  |                                |             |
                  |                                |             |
                  |                                |      |translates
                  V                                V             |to
           +--------------+                  +-----------+       |
           |              |                  |           |       |
           |   instance   |                  |    AOR    |       |
           |      ID      |                  |           |       |
           |              |                  +-----------+       |
           +--------------+                        |             |
                  ^                                |             |
                  |                                |             |
                  |                                |             |
                  |                                |is-bound-to  |
                  |        +----------------+      |             |
                  |        |                |      |             |
                  |        |                |      |             |
                  +--------|  Contact URI   |<-----+             |
                           |                | 0..*               |
                           |                |                    |
                           +----------------+                    |
                              0..1 ^                             |
                                   |                             |
                                   +-----------------------------+

I think we want:

                  +-------------+
                  |             |
                  |             |
                  |     AOR     |
                  |             |
                  |             |
                  +-------------+
                     |        |
         is-bound-to |        |  is-associated-with
                     |        '--------------------+
                     |                             |
                     V 0..*                        V 0..*
              +-----------+                  +-----------+
              |           |    is-bound-to   |           |
              |  Contact  |<-----------------|    GRUU   |
              |           |0..1              |           |
              +-----------+                  +-----------+
                                                   | 1
                                                   |
                                                   V 1
                                             +-----------+
                                             |           |
                                             | Instance- |
                                             |     ID    |
                                             |           |
                                             +-----------+

Namely, a GRUU could never exist without an AoR, in fact it *is* the AoR 
with an additional unique parameter -- a combination for which a UA 
owning the related instance-ID can register a specific contact for.

If we add an optional rule that allows a proxy to retarget a request 
that arrives with the above kind GRUU in its Request-URI to *any* 
contact under the AoR in the absence of any registered GRUU contacts, we 
get the (I think valuable) property, that a GRUU has the same validity 
proerties as the AoR. If the GRUU is forgotten, the URI behaves exactly 
as the AoR. Also, it is then trivial to determine for what AoR this GRUU 
belongs to as they are one and the same.

I haven't fully thought about the implications of this, but it might 
mean that we are ultimately talking about two different features, that 
share some requirements for gruuness properties, but with different 
temporal persistency requirements. One is the blind transfer problem, or 
conference focus problem, where I think the GRUU really need not be 
valid beyond the dialog. The other is more a problem of encoding routing 
state into the URI, so that that URI can then be used in places where 
the validity requirements are indefinite (like in presence). Maybe the 
same mechanism can be used for both, I don't know but probably so.

In short, the proposal would be to move GRUU from being a separate URI 
into a parameter of the AoR, along with the grid. I *think* this should 
be a minor change to the GRUU spec as it currently stands, but might 
solve at least my concerns over the use of it.

Thoughts?

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jan 2005 11:42:31 -0500

> saying AoR (plus a gruuness token).

I think you go a little too far here.

I think it would be good for the relationship of the gruu to the AOR to 
be apparent when the provider of it has no reason to hide the 
relationship. But I think there are also cases where hiding it may be 
desired, so it shouldn't be excluded. Of course there will be 
consequences to hiding it, which need to be taken into account.

> Instead of what we currently have:

I am not sure that either of these models reflects what I have in mind 
especially well. But drawing UML diagrams in text isn't fun, and so I 
won't try it here right now.

The key feature isn't the actual relationships, but which relationships 
can be learned by examining a URI.

> Namely, a GRUU could never exist without an AoR, in fact it *is* the AoR 

This rules out the possibility of someone that knows they have a 
globally routable contact just using it. (Or at least using it and 
calling it a GRUU.)

> belongs to as they are one and the same.

That concept requires some work.

This is starting to look very much like just another way to encode a 
callerpref into a URI. (I want to call this URI, but prefer only a 
contact with a particular instance-id.)

Routing to any contact other than the intended one also violates the 
"contract" that we have tried to impose for GRUUs. If the actual AoR can 
be retrieved by the caller from a GRUU, then I think it would be cleaner 
to let it try the GRUU, and then if that fails and it wishes, try again 
with the AOR.

	Paul

---

From: "Mike Hammer" <[email-masked]>
Date: Wed, 26 Jan 2005 14:27:36 -0500

Paul,

If there is no hard and fast rule that requires the R-URI to be the same as
the To header, then this seems to be a non-problem.  Could you clarify what
is the problem Cullen's suggestion?

Mike

   >From: Paul Kyzivat [mailto:[email-masked]] 
   >Sent: Tuesday, January 25, 2005 6:50 PM
   >To: Mike Hammer
   >Cc: 'Cullen Jennings'; 'sipping'
   >> Keep in mind that the "traditional" view was that the person 
   >> transferring the call would be the one to pay for the 
   >call.  While in 
   >> SIP, the new call is direct from the original caller to 
   >the endpoint, 
   >> you may still want to keep that billing convention possible.  For 
   >> that, some type of charge number (rather than AoR) would 
   >be more appropriate for privacy reasons.
   >> 
   >> secretary) was to intentaionally insert a gatekeeper to 
   >protect the 
   >> boss from unwanted, disruptive calls.  So, making the "who I go 
   >> connected to" AoR available may constitue a breach of privacy.
   >> 
   >> Indentification Presentation (COLP) and Restreiction 
   >(COLR).  As a 
   >> result, the temporary, random/anonymouse, non-reusable 
   >nature of the 
   >> GRUU is a feature not a drawback.  I would suggest that 
   >the extension 
   >> of the Privacy-Asserted-Identity work to cover connected 
   >parties, or 
   >> some new capability is more in line with what you are 
   >searching for.
   >> 
   >Mike. The points you make above do apply to some of the 
   >cases, but not all of them. The use in presence is the case 
   >that first stimulated this issue, and maybe it was wrong to 
   >try to over-generalize it.
   >

---

From: "Mike Hammer" <[email-masked]>
Date: Wed, 26 Jan 2005 15:13:38 -0500

Aki,

I went back and read the GRUU draft and found much of the tutorial
description of this rather convoluted and difficult to fathom until I had
read the whole document.  I think it would have been more comprehensible if
the diagram were drawn more like:

        +----------------------------------------------+
        |  +--------+                    +----------+  |
        |  |        | is associated with |          |  |
        |  |  AoR   |--------------------| instance |  |
        |  |        |                    |    ID    |  |
        |  +---+----+                    +----------+  |
        |      |                                       |
        +------|------------------------------+--------+
            is | 1                         is | 1
         bound |                        bound |
            to | 0*N                       to | 0*1
           +---+-----+                   +----+-----+
           | Contact |   translates to   |  GRUU    |
           |   URI   |<------------------|   URI    |
           |         |  0*1          0*1 |          |
           +---------+                   +----------+

I am a little leery of your suggestion of routing a request with a GRUU to
any contact under an AoR, if the GRUU is not regeistered to that AoR.  That
seems open to mischief.

Last, I always try to think how this would work for roaming mobile/nomad
users.  Unfortunately, the GRUU draft seems to use only a single example.com
domain.  I assume a nomad that might need to register in a visited domain
and get a GRUU based on the visited domain.  That GRUU can then be published
as a contact in the Presence information for that UA.  As a result the
domain of the GRUU and the domain of the AoR could be different.

While that scenario may be only one of many ways this could work (and not
the best), I don't see anything precluding that and requiring that the GRUU
domain and AoR domain be the same.  So, I am not sure the path you are
heading is generically applicable.

Just thinking aloud,
Mike

   >[mailto:[email-masked]] On Behalf Of Aki Niemi
   >Sent: Wednesday, January 26, 2005 7:42 AM
   >To: ext Paul Kyzivat
   >Cc: Cullen Jennings; sipping
   >I've had a doubt about using GRUUs in the presence context, 
   >and admittedly haven't perhaps expressed clearly why. The 
   >problem you outline is one of the reasons why. When we say 
   >GRUU, we should really be saying AoR (plus a gruuness token).
   >
   >Meaning that an AOR describes an entity, which may 
   >optionally have a set of "resources" that if necessary can 
   >be directly addressed. Contact addresses could be 
   >registered for AoRs directly, or under GRUUs. I don't know 
   >any other way to express this than a figure.
   >
   >|translates
   >Namely, a GRUU could never exist without an AoR, in fact it 
   >*is* the AoR with an additional unique parameter -- a 
   >combination for which a UA owning the related instance-ID 
   >can register a specific contact for.
   >
   >If we add an optional rule that allows a proxy to retarget 
   >a request that arrives with the above kind GRUU in its 
   >Request-URI to *any* contact under the AoR in the absence 
   >of any registered GRUU contacts, we get the (I think 
   >valuable) property, that a GRUU has the same validity 
   >proerties as the AoR. If the GRUU is forgotten, the URI 
   >behaves exactly as the AoR. Also, it is then trivial to 
   >determine for what AoR this GRUU belongs to as they are one 
   >and the same.
   >
   >I haven't fully thought about the implications of this, but 
   >it might mean that we are ultimately talking about two 
   >different features, that share some requirements for 
   >gruuness properties, but with different temporal 
   >persistency requirements. One is the blind transfer 
   >problem, or conference focus problem, where I think the 
   >GRUU really need not be valid beyond the dialog. The other 
   >is more a problem of encoding routing state into the URI, 
   >so that that URI can then be used in places where the 
   >validity requirements are indefinite (like in presence). 
   >Maybe the same mechanism can be used for both, I don't know 
   >but probably so.
   >
   >In short, the proposal would be to move GRUU from being a 
   >separate URI into a parameter of the AoR, along with the 
   >grid. I *think* this should be a minor change to the GRUU 
   >spec as it currently stands, but might solve at least my 
   >concerns over the use of it.
   >
   >Thoughts?
   >
   >Cheers,
   >Aki
   >
   >ext Paul Kyzivat wrote:
   >> 
   >> 
   >> Cullen Jennings wrote:
   >> 
   >>>
   >>> user Identity in things like To and From with things 
   >that go in the 
   >>> contact or via header.
   >> 
   >> 
   >with To and 
   >>>> conversations about problems with GRUUs. This came up 
   >most recently 
   >>>> in the "modeling dispatchers in the data model" thread.
   >>>>
   >>>> To an outside observer, including the client using it, 
   >a GRUU may 
   >>>> well have a form that doesn't correlate in any apparent 
   >way to who 
   >>>> was called. And the timespan over which a GRUU remains 
   >valid may be 
   >>>> very bounded.  This could have at least two effects:
   >>>>
   >>>> contact addresses in PIDF tuples. But it applies 
   >equally to GRUUs 
   >>>> used in other contexts, such as call transfer.
   >>>>
   >>>> more information needs to be captured for historical 
   >purposes. We 
   >>>> need to figure out what that is.
   >>>>
   >>>> In other cases this may not be so. E.g. in the case of presence 
   >>>> there typically in no reason to hide who this is about - the 
   >>>> presence document  is there to make it explicit.
   >>>>
   >>>> typically has some context that can help - at least to 
   >qualify who 
   >>>> the target was and possibly to obtain a callable 
   >address even if the 
   >>>> gruu itself has become invalid.
   >>>>
   >>>> Similarly, when acting on a REFER, it might be helpful 
   >to ensure 
   >>>> that info about the referror is associated with the resulting 
   >>>> request. (This may already be sufficiently addressed.)
   >>>>
   >>>> Thoughts?
   >>>> Paul
   >>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jan 2005 16:00:00 -0500

> is the problem Cullen's suggestion?

Which suggestion? I think you mean the one about putting the presentity 
URI in the To. I believe that was actually my suggestion. (Hard to 
follow the quoting.)

It is entirely feasible. But there is no reason to believe it will be 
done, unless someone suggests that it should. It seems that general 
behavior in the absence of rules to the contrary is for the UAC to 
obtain an address, and then construct a call with it, putting that URI 
in both R-URI and To-URI.

	Paul

>    >>    >most recently in 
>    >>    >purposes. We need 
>    >>    >qualify who the

---

From: Aki Niemi <[email-masked]>
Date: Thu, 27 Jan 2005 14:58:39 +0200

Inline.

ext Paul Kyzivat wrote:
>> outline is one of the reasons why. When we say GRUU, we should really 
>> be saying AoR (plus a gruuness token). 
> 

I think you are right. But also seems to me that the scenario where I
want a GRUU to simply be a globally routable end of a dialog but need
proxy assistance in making it so is very different from the one where I
want a presence watcher the ability to address a sub-resource of the
AoR. I'll note that some URI schemes have already a similar concept, in
the form of a "username@domain/resource".

The ability to hide the relationship of the address of the sub-resource 
from the AoR seems least likely in the latter scenario. So it may be 
that there are (at least) two distinct groups of usages that may well 
deserve slightly different mechanisms as well.

...snip...

> can be learned by examining a URI.

Agreed. And my UML is probably a bit rusty. But generally there
would need to be an ability to tell by looking at a GRUU to which AoR it
belongs to, but not the other way around. (So seems at least that my 
figure has incorrect navigability.)

> globally routable contact just using it. (Or at least using it and 

Right, I talk about this a bit below. Maybe we've wrongfully grouped a 
set of problems together here that don't necessarily belong in the same 
problem space?

>> contact under the AoR in the absence of any registered GRUU contacts, 
>> we get the (I think valuable) property, that a GRUU has the same 
>> validity proerties as the AoR. If the GRUU is forgotten, the URI 
>> behaves exactly as the AoR. Also, it is then trivial to determine for 
>> what AoR this GRUU belongs to as they are one and the same.
> 
> 

But isn't that ultimately what a GRUU is used for?

> to let it try the GRUU, and then if that fails and it wishes, try again 

True, that is why I said it should be an *optional* feature. There are 
ways to make this fall back more apparent, too. For example, redirecting 
a GRUU with a 301/302. Simply stripping the params from the AoR and 
trying again would work too.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2005 09:25:49 -0500

Aki,

So far this seems to be mostly a dialog between the two of us. I think 
we are getting close to agreement. But I would like to hear some other 
voices in this conversation - especially Jonathan and Henning who also 
have strong opinions on this.

	Paul

Aki Niemi wrote:
>> I think it would be good for the relationship of the gruu to the AOR 
>> to be apparent when the provider of it has no reason to hide the 
>> The key feature isn't the actual relationships, but which 
>> relationships can be learned by examining a URI.
> 
> 
>> "contract" that we have tried to impose for GRUUs. If the actual AoR 
>> can be retrieved by the caller from a GRUU, then I think it would be 
>> cleaner to let it try the GRUU, and then if that fails and it wishes, 
>> try again with the AOR.
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jan 2005 10:16:43 -0500

My inclination would be to make the AOR that fathers the GRUUs easily 
identifiable, for the reasons mentioned. In addition, diagnosing 
problems seems much easier and we can get some of the benefits of the 
<i-belong-to> element in presence without defining this.

Is there a reason *not* to do this?

Another question is whether the GRUU should indicate its lifetime, 
either as a class ("in-dialog only" or "permanent") or more precisely.

(I suspect there is agreement that there are cases where one might want 
to create anonymous GRUUs, but anonymity doesn't seem a general 
requirement.)

Paul Kyzivat wrote:
>>>> outline is one of the reasons why. When we say GRUU, we should 
>>>> really be saying AoR (plus a gruuness token). 
>>>
>>>
>>>
>> The ability to hide the relationship of the address of the 
>> sub-resource from the AoR seems least likely in the latter scenario. 
>> So it may be that there are (at least) two distinct groups of usages 
>> that may well deserve slightly different mechanisms as well.
>>
>> ...snip...
>>
>>> I am not sure that either of these models reflects what I have in 
>>> mind especially well. But drawing UML diagrams in text isn't fun, and 
>>> so I won't try it here right now.
>>>
>> set of problems together here that don't necessarily belong in the 
>> same problem space?
>>
>>>> contact under the AoR in the absence of any registered GRUU 
>>>> contacts, we get the (I think valuable) property, that a GRUU has 
>>>> the same validity proerties as the AoR. If the GRUU is forgotten, 
>>>> the URI behaves exactly as the AoR. Also, it is then trivial to 
>>>> determine for what AoR this GRUU belongs to as they are one and the 
>>>> same.
>>>
>>>
>>>
>>>
>> ways to make this fall back more apparent, too. For example, 
>> redirecting a GRUU with a 301/302. Simply stripping the params from 
>> the AoR and trying again would work too.
>>
>> Cheers,
>> Aki
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2005 10:27:44 -0500

> to create anonymous GRUUs, but anonymity doesn't seem a general 

It may be that in cases where you need anonymous GRUUs you really also 
need an anonymous AoR.

	Paul

---

From: "Mike Hammer" <[email-masked]>
Date: Thu, 27 Jan 2005 11:47:52 -0500

What do you mean by father.  This suggests a parent-child relationship in
naming, i.e. hierarchical.

Is the domain of the AoR and the GRUU required to be the same?

I thought they can and should be independent.  Please point me to where this
requirement exists, if it does.

Mike

   >[mailto:[email-masked]] On Behalf Of Henning Schulzrinne
   >Sent: Thursday, January 27, 2005 10:17 AM
   >To: Paul Kyzivat
   >Cc: sipping
   >My inclination would be to make the AOR that fathers the 
   >GRUUs easily identifiable, for the reasons mentioned. In 
   >addition, diagnosing problems seems much easier and we can 
   >get some of the benefits of the <i-belong-to> element in 
   >presence without defining this.
   >
   >Another question is whether the GRUU should indicate its 
   >lifetime, either as a class ("in-dialog only" or 
   >"permanent") or more precisely.
   >
   >(I suspect there is agreement that there are cases where 
   >one might want to create anonymous GRUUs, but anonymity 
   >doesn't seem a general
   >requirement.)
   >
   >Paul Kyzivat wrote:
   >> Aki,
   >> 
   >>>> relationship. But I think there are also cases where 
   >hiding it may 
   >>>> be desired, so it shouldn't be excluded. Of course 
   >there will be 
   >>> proxy assistance in making it so is very different from 
   >the one where 
   >>> I want a presence watcher the ability to address a 
   >sub-resource of 
   >>> the AoR. I'll note that some URI schemes have already a similar 
   >>> concept, in the form of a "username@domain/resource".
   >>>
   >>>> mind especially well. But drawing UML diagrams in text 
   >isn't fun, 
   >>>> and so I won't try it here right now.
   >>>>
   >>> Agreed. And my UML is probably a bit rusty. But 
   >generally there would 
   >>> need to be an ability to tell by looking at a GRUU to 
   >which AoR it 
   >>>>> Namely, a GRUU could never exist without an AoR, in 
   >fact it *is* 
   >>>>> the AoR
   >>>>
   >>>>
   >>>>
   >>> Right, I talk about this a bit below. Maybe we've 
   >wrongfully grouped 
   >>> a set of problems together here that don't necessarily 
   >belong in the 
   >>> same problem space?
   >>>
   >>>>> If we add an optional rule that allows a proxy to retarget a 
   >>>>> request that arrives with the above kind GRUU in its 
   >Request-URI to 
   >>>>> *any* contact under the AoR in the absence of any 
   >registered GRUU 
   >>>> cleaner to let it try the GRUU, and then if that fails and it 
   >>>> wishes, try again with the AOR.
   >>>
   >>>
   >>>
   >>> True, that is why I said it should be an *optional* 
   >feature. There 
   >>> are ways to make this fall back more apparent, too. For example,

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Jan 2005 12:12:23 -0500

> the diagram were drawn more like:

This isn't right though. An AOR is not associated with a single instance ID.

> domain of the GRUU and the domain of the AoR could be different.

I think this is out of scope for this document.

> heading is generically applicable.

I think you mean, there is nothing that stops you from having AoRs in 
two domains, and obtaining GRUUs from each, which I agree with. If you 
are implying that I have an AOR in one domain, and a GRUU allocated from 
a domain in which I don't have an AOR, I think that requires inspection. 
I don't see that you want that or even need it in many roaming situations.

If you consider the IMS roaming model, The GRUU would be allocated from 
the home provider, placed in the contact. When a call is made to it, it 
goes to the home provider, and gets routed through the visited network 
using the Route headers learned from Path.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Jan 2005 12:12:49 -0500

inline.

> have strong opinions on this.

Well, I have strong opinions on everything Paul ;)

>> the form of a "username@domain/resource".

I don't see these as very different. In all cases, we have a requirement 
to have a URI that routes to an instance. In some usages, we have an 
additional requirement (it would seem), that it be possible to associate 
this instace with its AOR, and in other cases, we want it to be 
impossible to make this determination.

So, the question then, is what mechanism to use here. I don't want two 
of them. I think we have several options:

1. The URI is of the form sip:user/instance-id@domain;user=sub-resource

We define a new value of the user-part of the URI that gives explicit 
meaning to this user part as having two components - a username and an 
instance ID.

Since the URI is an explicit function of the AOR, they are readily 
allocated and no registration processing is needed per se; the endpoint 
can merely construct one from its own AOR and instance ID.

The drawback of this approach is that we force well-defined structure on 
URI, and this rules out anonymous GRUU unless you also have an anonymous 
AOR (do we need anonymous gruu without anonymous AOR??). It also always 
reveals the instance IDs to everyone, which may not be desirable. But, 
if the GRUU is long-lived, does it matter?

Proxies in the network not familiar with this form may get upset by it.

Advantage is that it vastly simplifies the GRUU draft itself, and allows 
the AOR to be readily known.

2. The GRUU form is sip:user@domain;instance=instanceID

Similar to above; perhaps less upsetting for proxies not familiar with 
the form.

3. The GRUU form is sip:<domain-assigned-user-part>@domain;aor=<aor>

We keep the current GRUU form, but add an optional AOR parameter that 
indicates the AOR associated with the GRUU.

4. The GRUU form is the same. You get the AOR by sending an OPTIONS to 
the GRUU, and we provide the AOR through response identity.

This is an interesting possibility, but it may not give you the "right 
answer" depending on what you want to know. If complex call forwarding 
logic results in the request going to someone else, it may not help if 
you want to know, "who was I trying to reach when I made this call".

I'm on the fence about which of these I like, leaning to (1). Generally 
I hate the idea of defining implicit structure to a URI. But, the use of 
the user parameter makes the structure quite explicit. I don't really 
like (3), since I don't like polluting the URI with parameters they 
convey *characteristics* of the URI (like its AOR). (4) seems reasonable 
but more complex.

Do people see other choices?

Just for fun, I'll throw another wrench in here.

Thinking about this as a "sub-resource" concept, we are instructing the 
home proxy to route the call to a particular instance. That represents 
the first level in a resource hierarchy. The grid parameter represents a 
second level in the hierarchy - its used by the instance itself to 
dispatch to particular "applications" in the endpoint. As such, one 
might even consider something like this for the GRUU structure:

sip:username/instance-id/grid@domain;user=sub-resource

When the proxy receives this, it translates the request URI, placing the 
contact there but still including the grid:

sip:contact-user-part/grid@contact-domain-part;user=sub-resource

>>> relationships can be learned by examining a URI.

I think the requirement is to learn them from the URI. One other option 
is that the URI can be queried to learn the AOR if that is desired. That 
allows the information to be provided selectively based on the querier. 
This comes at increased system complexity of course..

>> But isn't that ultimately what a GRUU is used for?

Careful here. Our original solutions for this did in fact use caller 
prefs with an instance ID in the accept-contact. It had many problems, 
mostly around the fact that it was unreliable and based on routing rules 
that were not explicit.

>> the AoR and trying again would work too.

I think its a big mistake to route to another contact. The explicit 
meaning of the GRUU is that it routes to the instance, period.

Previously in this thread, there was a statement about the unclear 
temporal scope of the GRUU. I agree this is now unclear in the spec. I 
point to this text however:

However, at any time in the future, should a Contact
    become bound to that same AOR, and that Contact is associated with
    the same instance ID, the domain SHOULD create the same GRUU that was
    previously associated with that instance ID/AOR pair.  Indeed, this
    requirement would ideally be a MUST if it was achieveable, but even
    with the stateless algorithm described above, key rotation or server

Rosenberg              Expires December 31, 2004                [Page 8]

Internet-Draft               GRUU Mechanism                    July 2004

    failures may cause the GRUU associated with an instance ID/AOR pair
    to change.  The value of associating the GRUU with an instance ID/AOR
    pair, as opposed to a Contact URI/AOR pair, is that the association
    can transcend changes in IP address.  As a result, domains SHOULD
    make every effort possible to maintain the association for as long as
    possible.

which, I think, makes it clear that the intent is that GRUUs live 
"forever", to the greatest extent that this is achievable in practice.

Thanks,
Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2005 16:55:06 -0500

> Well, I have strong opinions on everything Paul ;)

It takes one to know one :-)

>>>> relationship. But I think there are also cases where hiding it may 
>>>> be desired, so it shouldn't be excluded. Of course there will be 

I am more concerned with forcing a structure on the user part of AORs 
than the other points. If we were starting over I might be ok with that, 
but it seems kind of late to do that now. Also, it presents problems if 
the AOR you want a gruu for is phone number based and so has its syntax 
defined by the tel format.

> Proxies in the network not familiar with this form may get upset by it.

Slash is legal in the user part, so I don't see how they could get upset 
with it. (Proxies that *support* assignment of gruus like this would 
need to understand it.)

> Similar to above; perhaps less upsetting for proxies not familiar with 

I find this much preferable. It fixes the problems I have with (1).

I presume this could still support sub-resources as well:

     sip:user@domain;instance=instanceID;user=sub-resource

> indicates the AOR associated with the GRUU.

Ugh.

> you want to know, "who was I trying to reach when I made this call".

This doesn't work in the case where a proxy retains state for GRUUs 
rather than encoding it in the name of the GRUU. Once it has lost this 
state, it will also be unable to recover the AOR.

> convey *characteristics* of the URI (like its AOR). (4) seems reasonable 

Everything you say here suggests you ought to like (2), but you don't 
mention it.

> sip:contact-user-part/grid@contact-domain-part;user=sub-resource

You are confusing me. I thought you were using "user=sub-resource" as 
just alternative syntax to grid. But here you have both.

This suffers from the same problems as (1).

>>>> mind especially well. But drawing UML diagrams in text isn't fun, 

Technically this may be so. But being able to derive it be examination 
is a great advantage. If I am looking at the itemized bill from my 
provider, being able to derive it by eye is much more convenient than 
having to use some tool to make the query.

Bottom line: I vote for (2). If you want anonymity, get a temporary AOR.

	Paul

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jan 2005 17:04:18 -0500

> requirement exists, if it does.

There is no such requirement in order to simply meet the GRUU property 
(Globally Routable Unique Uri). If you have such a thing handy that you 
can use for a contact address, feel free to use it.

The *mechanism* that has been proposed to generate GRUUs for those that 
don't have them but want them does have a parent-child relationship.

And then there are use cases (e.g. the presence case) where it might be 
convenient if this parent-child relationship was present and discernable 
by anybody.

Perhaps it is wrong to seek the convenient convergence of these things. 
Maybe if we fixed other things there would no longer be any important 
reason to want to exploit this relationship. The use case is calling to 
the address in a presence tuple. If the call was also constructed so it 
identified the presentity as well as the contact address then this 
discussion might be a lot less interesting.

I could be convinced either way at this point.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Fri, 28 Jan 2005 12:12:01 +0200

ext Jonathan Rosenberg wrote:
...snip...

> impossible to make this determination.

Sounds reasonable.

> the AOR to be readily known.

I'm afraid this won't go over too well with some sysadmins. Also, I 
think there are some push-to-talk systems that already have a similar 
mechanism for creating groups under a user's user-id. The danger here is 
that we pick the same separator used in those systems.

And even if we manage to pick a separator that isn't currently used, 
it's one less separator to be used in future (proprietary) schemes to 
split the userpart. Since we're already doing IETF standards action 
here, it's better to register a parameter instead.

> Similar to above; perhaps less upsetting for proxies not familiar with 

I would prefer this approach over any of the others. As Paul suggests, 
it is also trivial to add the grid in there, creating yet another layer 
in the hierarchy.

> Do people see other choices?

How about a new URI scheme, called "gruu". Just kidding... ;)
...snip...

> meaning of the GRUU is that it routes to the instance, period.

Fair enough.

Cheers,
Aki

---

From: "Mike Hammer" <[email-masked]>
Date: Fri, 28 Jan 2005 11:46:39 -0500

>From: Jonathan Rosenberg [mailto:[email-masked]] 
   >Sent: Thursday, January 27, 2005 12:12 PM
   >To: Mike Hammer
   >Cc: 'Aki Niemi'; 'ext Paul Kyzivat'; 'Cullen Jennings'; 'sipping'
   >> description of this rather convoluted and difficult to 
   >fathom until I 
   >> had read the whole document.  I think it would have been more 
   >> comprehensible if the diagram were drawn more like:
   >> 
   >>         |  |        |     Note 1         |    ID    |  |
   >>         Note 1:  The same AoR value can be associated with
   >>         additional Instance-Ids to create other tuples.
   >

But, the document is clearly talking about AoR-InstanceID tuples each as a
distinct entity that gets mapped to a GRUU.  This picture does not suggest
that the same AoR could not be associated with another InstancsID to create
another unique tuple.  Perhaps this could be handled via a note as added
above.  It is probably not possible to diagram all angles to this, so it is
just a matter of choosing which relationships to emphasize.

   >> I am a little leery of your suggestion of routing a 
   >request with a 
   >> GRUU to any contact under an AoR, if the GRUU is not 
   >regeistered to 
   >> that AoR.  That seems open to mischief.
   >> 
   >> Last, I always try to think how this would work for roaming 
   >> mobile/nomad users.  Unfortunately, the GRUU draft seems 
   >to use only a 
   >> single example.com domain.  I assume a nomad that might need to 
   >> register in a visited domain and get a GRUU based on the visited 
   >> domain.  That GRUU can then be published as a contact in 
   >the Presence 
   >> information for that UA.  As a result the domain of the 
   >GRUU and the domain of the AoR could be different.
   >

Agree.  This was just background for understanding what restrictions there
might be to usage, given the specification in the document.

   >> While that scenario may be only one of many ways this 
   >could work (and 
   >> not the best), I don't see anything precluding that and 
   >requiring that 
   >> the GRUU domain and AoR domain be the same.  So, I am not 
   >sure the 
   >> path you are heading is generically applicable.
   >
   >I think you mean, there is nothing that stops you from 
   >having AoRs in two domains, and obtaining GRUUs from each, 
   >which I agree with. If you are implying that I have an AOR 
   >in one domain, and a GRUU allocated from a domain in which 
   >I don't have an AOR, I think that requires inspection. 

That is one alternative that I was exploring (but may have wandered too far
out of bounds).
1. Is it possible?
2. Is it useful?
3. Is it harmful?
4. Should that be precluded?

   >If you consider the IMS roaming model, The GRUU would be 
   >allocated from the home provider, placed in the contact. 
   >When a call is made to it, it goes to the home provider, 
   >and gets routed through the visited network using the Route 
   >headers learned from Path.

Thanks for the reminder.  Given that many seem to be converging on IMS-based
solution, I will assume that is the model most will follow.

Thanks,
Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jan 2005 05:35:44 -0500

inline.

Paul Kyzivat wrote:

>> allocated and no registration processing is needed per se; the 
>> endpoint can merely construct one from its own AOR and instance ID.
>>
>> The drawback of this approach is that we force well-defined structure 
>> on URI, and this rules out anonymous GRUU unless you also have an 
>> anonymous AOR (do we need anonymous gruu without anonymous AOR??). It 
>> also always reveals the instance IDs to everyone, which may not be 
>> desirable. But, if the GRUU is long-lived, does it matter?
> 
> 
> but it seems kind of late to do that now.

I think it can work if you put the user part in there to be explicit 
that you are creating such structure. Thats what its for.

> Also, it presents problems if 

That is a good point.

> with it. (Proxies that *support* assignment of gruus like this would 

My concern would be the presence of the user part with a new value. It 
*should* be OK if a proxy is properly compliant to rfc3261, but too many 
implementations I suspect only accept user=phone, user=ip or no user 
parameter, and would choke on anything else.

> 
>> Advantage is that it vastly simplifies the GRUU draft itself, and 
>> allows the AOR to be readily known.
>>
>>

I'm confused. You don't need the user=sub-resource in this case. Its 
point was to indicate that the user part contained the AOR and the 
sub-resource (where the sub-resource is the instance ID). If you already 
have the instance as a URI param, what is the point of the user part?

>> indicates the AOR associated with the GRUU.

I don't like it either.

> state, it will also be unable to recover the AOR.

Which its not supposed to do; the implementation is supposed to retain 
the GRUU for as long as possible.

> 
>> I'm on the fence about which of these I like, leaning to (1). 
>> Generally I hate the idea of defining implicit structure to a URI. 
>> But, the use of the user parameter makes the structure quite explicit. 
>> I don't really like (3), since I don't like polluting the URI with 
>> parameters they convey *characteristics* of the URI (like its AOR). 
>> (4) seems reasonable but more complex.
> 
> 

I was leaning towards (1) since I think its architecturally more sound, 
but it has the potential compatibility issues as above.

>> Thinking about this as a "sub-resource" concept, we are instructing 
>> the home proxy to route the call to a particular instance. That 
>> represents the first level in a resource hierarchy. The grid parameter 
>> represents a second level in the hierarchy - its used by the instance 
>> itself to dispatch to particular "applications" in the endpoint. As 
>> such, one might even consider something like this for the GRUU structure:
>>
>> When the proxy receives this, it translates the request URI, placing 
>> the contact there but still including the grid:
>>

No, I meant user=sub-resource to mean that the user part consisted of 
both the AOR and the instance ID. grid is sort of another layer of 
sub-resource, and so the above form seemed natural to me. If you use the 
instance URI parameter, you could encode the grid in there I suppose:

sip:user@domain;instance=<instance-id>/<grid>

>> I think the requirement is to learn them from the URI. One other 
>> option is that the URI can be queried to learn the AOR if that is 
>> desired. That allows the information to be provided selectively based 
>> on the querier. This comes at increased system complexity of course..
> 
> 

I agree that it is easier.

> Bottom line: I vote for (2). If you want anonymity, get a temporary AOR.

We have a few variations on two (all syntactic for the most part):

2a: sip:user@domain;instance=<instance-id>;grid=<grid-val>

2b: sip:user@domain;sub-resource=<instance-id>/<grid>

I have been thinking about a use case (one we really haven't considered) 
that might argue for (1) or a variant on it. Consider a user, joe smith, 
that gets sip service from a SIP provider, provider.com. Joe installs a 
"home SIP proxy" that allows him to have multiple phones, each of which 
registers to his own proxy, each for a different member of his family 
(for example, one for his wife alice and his son jack). Joe has only a 
single account with provider.com, [email-masked], so the home proxy 
registers to provider.com with a single contact that resolves to the 
home proxy, but makes use of the grid parameter to demux calls to 
different members of his family.

So, the home proxy registers to provider.com thusly:

REGISTER provider.com
To: sip:[email-masked]
From: sip:[email-masked]
Contact: sip:[email-masked];instance=family

If we go with approach 1 above, his wife Alice could have an AOR for 
herself which is:

sip:smith/family/[email-masked];user=sub-resource

when this arrives at provider.com, it gets translated to:

sip:family/[email-masked]

and gets sent to the home proxy. That proxy figures out that the call is 
for alice and proxies it to her devices (each member of the family would 
have a separate account on the home proxy).

Now, sip:smith/family/[email-masked];user=sub-resource is almost 
something you'd be willing to put on a business card. If you drop the 
user=sub-resource and just use sip:smith/family/[email-masked], that 
is definitely something one could put on a business card.

This would then allow a user to set up entire home networks that reside 
off of a single user account on a provider. Its sort of like a home 
router that acts as a DHCP client towards the service provider, and a 
DHCP server towards the home network.

If you take this a step further, and allow for arbitrary hierarchy in 
the user part (or instance parameter), you allow for much fancier 
situations, in which joe can have a home proxy to manage the family 
accounts, and each family member could have their own proxy that manages 
their own devices, etc. Or, more interestingly, a small enterprise could 
buy a single account from a provider, and then have a small enterprise 
proxy that manages users in the enterprise. Those users themselves might 
have proxies for their own devices, etc.

Making this work ONLY requires the grid concept, but if you want the 
feature that the URI constructed to reach you looks nice enough to put 
on a card, it argues for approach 1.

Hope this makes some sense,

Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 28 Jan 2005 14:43:45 -0500

> parameter, and would choke on anything else.

Since the SBC vendors are now dealing with the various SIP 
backwards-compatibility and can cure implementor laziness issues, we no 
longer have to constrain our design choices by the capabilities of the 
slowest implementor.

[Ducking...]

Seriously: Before making design choices based on surmised implementation 
defects, we might want to ascertain the scope of any problem. It would 
be sad if we not only worry about deployability with broken 
implementations, but in addition do self-censorship anticipating such 
brokenness.

---

From: Dean Willis <[email-masked]>
Date: Fri, 28 Jan 2005 13:55:18 -0600

On Jan 27, 2005, at 11:12 AM, Jonathan Rosenberg wrote:

> inline.
>
> Paul Kyzivat wrote:
>
>> Aki,
>> So far this seems to be mostly a dialog between the two of us. I  
>> think we are getting close to agreement. But I would like to hear  
>> some other voices in this conversation - especially Jonathan and  
>> Henning who also have strong opinions on this.
>

Of course one might argue that there is a distinction to be made  
between opinions that are strongly held and opinions that are  
technically strong, but I have no opinion on the matter.

. . .

> Similar to above; perhaps less upsetting for proxies not familiar with  

I believe I once proposed and endorsed this form, and I still like it a  
lot. I would note that several variations might suffice for  
sub-addressing, including dot-sequence notation and additional  
parameterization.

sip:aorid@domain;instance=instanceID.subinstanceID.susubinstanceID  and  
maybe more dots . . .

or

sip:aorid@domain;instance=instainceID;subinstance=subinstanceID; 
moreparameters=cool

> indicates the AOR associated with the GRUU.

I respond to this one with  a profoundly unreasoned "yuck!" based  
strictly on the aesthetic principles.

> you want to know, "who was I trying to reach when I made this call".

I find this one very attractive. Although it suffers from the possible  
inability to recover the associated AOR at some point in the future  
(depending on the aor-gruu associative function), it would seem that if  
one thought one was going to need to know, one could ask in close  
proximity to the actual usage of the GRUU in question. This approach  
also preserves the greatest flexibility for referential anonymization.

And just as we find today a need for throwaway email identities, we may  
find it useful to have throwaway entity references, a  task for which  
ephemeral GRUUs might be well-suited.

--
dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jan 2005 16:12:28 -0500

inline.

Jonathan Rosenberg wrote:
> inline.
> 
> Paul Kyzivat wrote:
> 
>>> So, the question then, is what mechanism to use here. I don't want 
>>> two of them. I think we have several options:
>>>
>>> meaning to this user part as having two components - a username and 
>>> an instance ID.
>>>
>> than the other points. If we were starting over I might be ok with 
>> that, but it seems kind of late to do that now.
> 
> 

Ahh! I entirely missed what you were doing. New value of user= parameter 
changing interpretation of user-part.

But now that I get it, I hate it.

>>> Similar to above; perhaps less upsetting for proxies not familiar 
>>> with the form.
>>

Sorry. Related to my misunderstanding above, and compounded. How about:

     sip:user@domain;instance=instanceID;grid=whatever

>>> 4. The GRUU form is the same. You get the AOR by sending an OPTIONS 
>>> to the GRUU, and we provide the AOR through response identity.
>>>
>>> This is an interesting possibility, but it may not give you the 
>>> "right answer" depending on what you want to know. If complex call 
>>> forwarding logic results in the request going to someone else, it may 
>>> not help if you want to know, "who was I trying to reach when I made 
>>> this call".
>>

Long as possible doesn't necessarily mean forever, or even "one month".

>>> But, the use of the user parameter makes the structure quite 
>>> explicit. I don't really like (3), since I don't like polluting the 
>>> URI with parameters they convey *characteristics* of the URI (like 
>>> its AOR). (4) seems reasonable but more complex.
>>

What's unsound about (2)?

>> just alternative syntax to grid. But here you have both.

Got it now.

> sip:user@domain;instance=<instance-id>/<grid>

Yeah, could do that. But if these are the responsibility of different 
entities, then making them separate parameters seems attractive.

It really shouldn't matter to anyone using the URI - just more opaque 
stuff. Mostly it is the proxy and the UAS that care. Others care 
slightly, if trying to recover the AoR from one of these.

> on a card, it argues for approach 1.

This is kind of attractive. But this is about human factors, and the 
devil is in the details. I think the "user=sub-resource" is a killer 
here. If we could convince ourselves that we could retrofit this without 
such a parameter, then maybe it would fly.

The interaction with tel based AoRs may be a killer here.

This also feels like it is starting down a slippery slope the a rather 
fundamental revision to the semantics of SIP URIs. While intriguing, I 
feel it may a rat hole that would distract us from other more important 
work.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 29 Jan 2005 08:24:58 -0800

I read the whole thread and I think there is a very simple solution....

The problem is that with the addition of GRUU  to SIP we have two
addressable things - ones is a user (and addressed with AOR) and other is
device (addressed with GRUU)

Now, some times a UA wants to send a request to a specific device but you
also want to provide the information of who the user is. In a flash of
brilliance it came to me. We can put the device (or GRU in this case) in the
request URI and we can put the User in the To header.

I think this solves the case and there has been a side thread that points
out when you do a refer to a GRUU, you need to pass the AOR in an embedded
To header if you expect the UA receiving the refer to be able to send an
INVITE with the To set correctly.

Cullen