This document constitutes an IETF contribution in in the context of IETF BCP 79.

 

Comments on: draft-ietf-sip-gruu-10

 

Detailed review comments received from at least

Andrew Allen,

Jeroen van Bemmel,

Vijay Gurbani,

Paul Kyzivat,

Xavier Marjo,

Eric Rescorla,

Robert Sparks,

Dale Worley,

Various others have part reviewed the document.

 

No.

Location

Comment type

Commentor

Comment

Resolution

001

General

Technical

Xavier Marjou (25th Aug 2006)

I'm still not 100% convinced that extending the scope of the remote target

(ie: Contact header field) to carry a gruu URI is necessary.

 

What about the following alternative mechanism:

 

- UA X obtains a GRUU AOR (eg: sip:ua-x;gruu=xyz) either by a response to a REGISTER request or by an external means.

 

- UA X must register his GRUU AOR before using it (as it recognize a gruu aor, the registrar only accepts one address-of-contact, so that forking towards multiple contacts is not possible)

 

- UA X can then use its GRUU AOR in its From header when sending an "initial" request, or substitute his AOR with its GRUU AOR in the To header when receiving an "initial" request.

 

In this case, mid-dialog requests are not impacted. Moreover the anonymous property of the GRUU AOR may be left out of the GRUU spec, as it comes back to the general usage in From and To headers.

Additional discussion from Paul Kyzivat, Mike Hammer, Dean Willis

Jonathan Rosenberg 11th September:

Firstly, as a bit of history, the main reason we place the GRUU in the Contact was that it allowed for interoperability as long as only one side - the agent which obtained the GRUU - supported it. As Dale pointed out, many implementations today take the contact header field learned from a peer, and use it as a target for new requests for features such as transfer. This is because the Contact, as defined by RFC 3261, is supposed to point to a specific UA instance and indeed is supposed to be globally routable too.

The problem we're having is, in reality, it has proven very hard for a UA to populate the Contact header field with a URI that is globally routable and which points to that specific instance. So, the GRUU spec provides a way for a URI to get a URI which meets the properties that RFC 3261 requires.

I understand your proposal, Xavier, and its not unreasonable. However, the problem is that it will not work with the existing implementations which are already assuming the Contact header field as the place to go for new requests for features like transfer. Thus, putting the GRUU anywhere else, whether its an updated To header field or a new header field, won't work.

Indeed, the essence of your proposal is to redefine the To, From and Contact semantics such that:

* Contact is a non-global URI for reaching an instance for mid-dialog requests only

* To and From are AOR for the initial requests in a dialog, and for mid-dialog requests, are modified to have both the identity and GRUU properties

This is a not-unreasonable proposal, its just going to not interoperate with anything which has assumed these header fields have the properties defined in 3261.

001A

General

Technical

Jonathan Rosenberg based on conference call discussion

11th September 2006

See also comment 124A.

 

Several folks got together to discuss the review comments on the GRUU spec. Much of the time was spent discussing the issue of anonymity.

 

Today, GRUU doesn't provide any anonymity functions at all. Indeed, the recommendations for construction of gruus are such that they would contain the users AOR. So, if a user wants to make an anonymous call, what would they do? The GRUU spec says nothing about this, and unfortunately the answer is that they cannot use the GRUU specification at all.

 

The point was raised that there were many places, such as Europe, where anonymous calls are the norm. This is because privacy laws require that caller ID be given out as an opt-in feature, and the default is privacy.

This results in a very large percentage of calls being anonymous. In these kinds of situations, GRUU would never get used, and the problems it solves (like making transfer work) won't be applicable.

 

A similar problem arises in network deployments which utilize network signaled privacy (in other words, the phone doesn't know the call is anonymous, but the network does). To support these kinds of deployments, the UA has to act as if every call was anonymous. This is how 3gpp is currently spec'd out, and it would make it very difficult to apply GRUU into 3gpp.

 

Thus, the concern was raised that a GRUU specification that didn't address anonymity at all was undeployable in many locales and unusable by many potential SDO customers. The question, then, is can it be addressed in this spec, and at what cost?

 

Unfortunately, anonymity is a big, thorny and hard problem. Indeed, there are many different types of anonymity. Consequently, I think its worth looking at a few different properties and seeing what the cost would be to add them to the GRUU spec.

 

Pseudonymity

------------

 

One feature that can be provided is pseudonymity. The idea is that the registrar, when it first creates a GRUU for an AOR/insteance-ID pair, actually would create two. One is the 'normal' one (generally constructed by adding an opaque parameter to the AOR), and another is a pseudonym for the GRUU:

 

sip:jdrosen@cisco.com;gruu;opaque=9asd8bvghasd8

sip:9ujjkasd--998@cisco.com;gruu

 

Both the pseudonym and the regular GRUU would be returned in the REGISTER response. The pseudonym would have the same temporal lifetime as the regular GRUU. The pseudonym can easily be constructed by encrypting the AOR and instance ID, or it can be computed and stored statefully.

 

The pseudonym would have the property that one could not, by inspection, determine the AOR. However, the pseudonym persists indefinitely, and consequently, two subsequent calls from the same UA instance would be known as coming from the same UA instance. Also, a recipient of the pseudonym could call the user back, at that instance, at any time in the future.

 

Adding this pseudonymity feature to GRUU is relatively low cost, in terms of complexity and time delay. I believe it would require the addition of one feature from:

 

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-coexistence-00.txt

 

namely, the user=anonymous URI parameter, so that a recipient knows to not try to render sip:9ujjkasd--998@cisco.com.

 

 

Temporal Privacy

----------------

 

There is probably a better name for this feature, but for now I'll call

it temporal privacy.

 

The idea is that the Contact header field contains a pseudonym. The UA

at the other end of the call can use that pseudonym for a certain

duration. After that duration expires, the pseudonym is invalid. Being

invalid means that any entity which makes a call to that URI, will not

cause the phone to ring and the call will not succeed.

 

The most useful temporal scope is for the lifetime of the dialog. This

is particularly useful for transfer and KPML, where that is exactly the

desired temporal scope. However, other scopes could be possible. Indeed,

another application of GRUU is in a call center, where you could call

back the specific help desk person who you just talked to, without

knowing their identity. This would work best with a temporal validity

that is something like an hour or so, and possibly even longer.

 

This is most easily implemented in the UA. Consider temporal privacy

with a scope equal to the lifetime of a dialog. The UA would obtain a

psedononymous GRUU as above, and then add a unique grid parameter for

each distinct dialog. When the UA receives a request that was targeted

towards that GRUU, it will know the grid that was used. If the

corresponding dialog is still in progress, the request is accepted. If

not, the request is rejected with a 403.

 

Pushing the validity checking into the network is harder, since it would

require proxies to retain dialog statefulness, store the correlation

between grid and dialog, and know that the desired temporal scope of the

anonymity is indeed for a dialog. No doubt some folks who like B2BUAs

would be more than happy to do this.

 

Adding this feature to the UA is relatively low cost (in terms of

specification work).

 

Note that, even though the grid would rotate on each call, the rest of

the pseudononymous GRUU would not. This makes it easily to correlate.

Thus, if Bob makes a call to Carol one day, and again to Carol the next

day, Carol will know that this was the same person that called on the

day previous.

 

Serial Pseudonymity

-------------------

 

With serial pseudonymity, the UA would be able to get multiple

pseudonyms, and use a different one for each dialog. The pseudonyms

could not be correlated together, except that they come from the same

domain. Serial pseudonymity is orthogonal to temporal privacy. Each of

the pseudonyms can have any temporal lifetime that is desired. The most

obvious lifetime is to bind the validity to that of the dialog the

pseudonym is used in. This would allow a UA to have a different GRUU

for each call, and for that GRUU only to be usable during the duration

of the call.

 

Serial pseudonymity is harder to address. The TRUU draft:

http://www.ietf.org/internet-drafts/draft-jbemmel-sip-truu-02.txt

takes a stab at this. Any solution to this problem needs to deal with

the question of how the UA instance gets a new pseudonym (the TRUU spec

proposes a REGISTER with a new Contact URI) and what its validity is

(the TRUU spec says that the clients explicitly invalidate them at the

end of the dialog). Its possible to separate the validity issue out. In

particular, if the network treats them as valid for the duration of the

registration, and they are rejected by the UA, there is no need for the

client to explicitly de-allocate them. Without de-allocation, the

pseodonym can be considered valid for the duration that the contact URI

itself is registered to that AOR with that instance ID. Doing that is

relatively easy to add to GRUU, I believe.

 

However, obtaining them is something that is requried in any solution.

Generating a register refresh is easy, however it has the drawback of

incurring an additional delay and bandwidth utilization at the time of

call setup. This may be a non-issue for enterprises or broadband access

providers, but may be a huge issue for wireless (think 3gpp).

Consequently, if folks believe that wireless providers will require

serial pseudonymity, I suspect a query-based mechanism (like a REGISTER

refresh) won't work. Any alternatives to that are much more complicated.

The two I can think of are to try and coordinate a generator function

between UA and proxy, or more likely, to make use of a network privacy

server ala RFC 3323 to request serial pseudonymity. Both would probably

require specification beyond the scope of the current GRUU spec.

 

True Anonymity

--------------

 

In true anonymity, each request is truly without identity. Nothing -

absolutely nothing - in the request tells you anything about who is

making it. This feature is nearly impossible to provide, GRUU or not. IP

addresses alone will provide a ton of information. So, I think this is

clearly out of scope. That is why I've focused on grades of

pseudonymity, since that is what we are talking about here.

 

 

 

So, the question to the group is - do folks believe that some kind of

anonymity needs to be addressed in the baseline GRUU draft for it to be

useful? If so, what degree? Is is one of the ones above or something

else entirely?

 

I believe it would be not too hard to add pseudonymity, temporal

privacy, and limited serial pseudonymity (requriing a REGISTER refresh

to get a new pseudonym) to the specification. Anything beyond that I

think is far too complex. However, no doubt there are still issues

lurking here and these will require time to ferret out.

Thoughts?

Additional discussion from Andrew Allen, Juha Heinanen, Jeroen van Bemmel, Paul Kyzivat, Jesus Javier Arauz, Dale Worley, Francois Audet, Dean Willis, Jonathan Rosenberg, Michael Hammer, Klaus Nieminen, Christer Holmberg, Cullen Jennings, Keith Drage

 

Conclusion in -11 is that serial pseudonymity is provided. A user is given lots of anonymous GRUU, allowing it to use a different one for each call. Each remain valid the entire duration of the registration.

002

General

Technical

Vijay Gurbani (22nd Aug 2006)

A major question around the design of the grid parameter I have is this: to indicate to the UAS that the request was sent to a GRUU, the the proxy is required to put a (possibly

empty) "grid" parameter when it sends a request to a UAS (cf. towards the end of Section 5 and top of page 20, Section 8.2.1).  The proxy is required to remove the "gruu" parameter from this incoming GRUU R-URI before sending it to the UAS, and putting a "grid" parameter.

Why not just maintain the "gruu" parameter?  Why overload the meaning of "grid" in this manner?  It makes it more complex, IMHO (unless there is a reason that I cannot forsee).

Grid has been removed from the GRUU spec. UA loose routing is proposed as the generalized solution to this problem.

002A

General

Technical

Eric Recorla (18th September 2006)

I recently made another pass through gruu-10 and I started wondering about the use of the "grid" parameter. ISTM that it serves two

purposes:

 

1. To let a UA hang a context variable/indicator off of a URI.

2. To let a UA know it was referenced via a GRUU.

 

So, the grid is sort of doing double duty in two not terribly related contexts. That's not always bad, but I fear it is in this case.

 

First, wouldn't it be nice to be able to hang a context variable/indicator off any URI, not just a GRUU?  I've seen this issue come up in the context of e-mail spam, where users would like to be able to mint new e-mail addresses (sort-of capabilities) for each use to enable easy filtering.  It's obviously really nice to be able to do this without the help of your service provider. If you could use grids (probably renamed) with AORs or something like them, that would work for this, right?

 

Second, just from an evocative perspective, having a "grid" parameter which can get into the To: one of two ways and which means "I was referenced via a GRUU" feels overloaded. Why not invent a different parameter for "I was referenced via a GRUU".

Further discussion by Paul Kyzivat, Jeroen van Bemmel, Paul Kyzivat, Dale Worley

 

This comment led to the removal of the grid mechanism from GRUU-11. UA loose routing is proposed instead as the solution. It has the properties EKR has asked for, including applicability to AOR and GRUU.

003

General

Technical

Vijay Gurbani (22nd Aug 2006)

A couple of places in the text it is maintained that an out-of-dialog request would be indicated by the absence of Route headers.  This is not entirely true if there is a pre- loaded Route set, is it?  Would the lack of a To-tag not be a better indication of an out-of-dialog request?  Once a dialog has been established, To header will have a tag, which will be used in subsequent re-INVs and SUBS.

The rules in the current text are now based merely on whether additional route headers are present or not, and not whether the request is mid-dialog or initial. The only place where the text makes rules about mid-dialog requests is in the discussion of call services. The text no longer recommends a procedure for distinguishing mid-dialog from initial requests.

004

General

General

Robert Sparks (22nd Aug 2006)

I have, since this whole idea got traction, felt discomfort with what this extension will do to the architecture of future systems if it is not applied with reason. The simple lazy "well, lets just always use a GRUU because then it will always work" approach leads to a world where there is _NEVER_ a SIP transaction that doesn't involve a "service provider" (I really had to fight with myself to not write gatekeeper just then). This consequence is lightly explored on page

19 - I would like it to see it under a much brighter spotlight, and I would like to see some guidance that would prevent unnecessary GRUU proliferation. Don't take this as a desire to not have GRUUs - I do agree that we need them for UAs that can't otherwise be reached. I just don't want to put out the firemen while putting out the fire.

 

There is a lot of text that reduces to "If you implement that extension over there, do what that extension tells you what to do". 

It was important during development of the text to make sure we worked in the context of those extensions, but having completed that exercise, I think we can safely elide the text (or reduce it to one standalone section). (outbound was bugging us at the time, so there's a bunch of outbound text here that doesn't really belong - we don't have, for instance, discussion of 183 using 100rel everywhere it might make sense)

 

There are some concepts that this document seems to create, but doesn't formally define or  borrow some other formal definition. The one that bugs me the most is "home proxy".

 

I got really lost during a linear read-through on what the requirements around including opaque, and instance ID were, especially when it came to being able to remove them and infer things from the result. After digging at it, I think the document is internally consistent (but don't feel 100% confident there). It would be very good to condense these into one authoritative set of statements.

 

I have not attempted to be comprehensive with grammar nits in the comments below - I captured things as I spotted them, but I hope we'll be doing a nit review of a revision and saved that level of effort for that time.

Those I captured, I'll send to Jonathan directly.

 

-11 now has guidelines on when its OK to have “self-made” GRUU as they are now called.

 

I have tried to remove most of the superflouous, “go implement that spec” text per your suggestion.

 

Home proxy should now be defined in sip-outbound and the draft references it for the definition.

 

Opaque has been removed to simplify.

004A

General

Technical

Eric Rescorla (19th September 2006)

The GRUU generation method specified in gruu-10 S. 9 involves an "opaque" parameter. ISTM that this name is a mistake, for two reasons:

 

1. Why does this parameter get named "opaque" where others

   don't? Isn't the "grid" just as opaque?

2. The fact that "opaque" is a term we use a lot in

   technical discussion means that we're pretty much

   guaranteed to have conversations where people get

   confused about whether they're talking about *an*

   opaque parameter or *the* opaque parameter.

Parameter has been removed completely. Instead, a value is added the gr parameter.

005

General

Minor technical / psycho-logical?

Robert Sparks (21st Aug 2006)

Right now, the mechanism is creating a header parameter and a URI parameter with the same name : "gruu".

 

Thinking about this from the perspective of debugging things in a lab, or worse, over VoIP or an IM, I envision many, many conversations that will take this form:

 

A: I see the problem - it's in the gruu parameter.

B: Ok - I'll change that

(retry)

A: It's still broken - I don't see what you... Oh wait - I didn't mean _that_ gruu parameter, go

      change the other one.

B: Oh crud - was it the header parameter or the URI parameter? (and which one of those is outside

      the <>'s? I can never keep that straight...)

 

For the sake of sanity (at least mine), could we please reconsider giving these things different names?

 

Further discussion from Christer Holmberg, Paul Kyzivat, Cullen Jennings, AB Nataraju, Jeroen van Bemmel, Dale Worley, Vijay Gurbani

Jonathan Rosenberg 11th September 2006:

I think this is reasonable. Note that this would break backwards compatibility of this version of the spec with all previous versions.

Generally IETF does not guarantee backwards compatibility when a document is still in I-D version (and indeed not for revisions of an RFC either...). This spec has been around a while though so I want to make sure people are OK with it. I don't think its been widely implemented yet though, as SBCs have mostly filled this need so far.

I would suggest:

;gr be the URI parameter which signals that the URI is a GRUU, analagous to ;lr.

;gruu be the Contact header field parameter which conveys the gruu assigned to you in the REGISTER response.

So, a REGISTER resposne would look like in part:

SIP/2.0 200 OK

Contact: <sip:10.0.1.1>;gruu="sip:joe@domain.com;gr;opaque=asdasdasd"

 

The GRUU URI parameter is now the “gr” URI parameter. The contact header field parameter(s) are now “pub-gruu” and “temp-gruu”. The option tag is “gruu”. All have different names now.

006

General

General

Dean Willis

(16th Aug 2006)

But why does Charlie need to be able to tell that the URI he has for Bob

  is a GRUU? I've been wondering about this since day one, and nobody could ever tell me, so I just stopped asking hoping it would eventually make sense. Of course, it could just be that I'm being overly dense but I still wonder why we need this property.

 

OTOH "knowing it is a GRUU" precludes some of the security benefits.

I've always thought that  GRUus should just be URIs that can serve as contact-specific aliases, but not be "obviously" aliases.

 

It's like a few years back when the US congress tried to make privately-operated mail delivery boxes have special "PMB" labels, so that everybody would know the destination was a drop box and not a "real" destination. As a consequence, I couldn't get package deliveries, because none of the mail-order computer places would ship to a "PMB"

(even though there was a paid attendant there to sign for things, with better security by far than my rented office-suite in the office-hotel) on the assumption that only criminals would try to hide their "real"

addresses behind a PMB alias.

 

Will applications (or users) discriminate against GRUUs since they are "obviously less traceable than real AORs?" Will people demand an "anonymous REFER-target request rejection service"?

 

Eric Rescorla, Paul Kyzivat, Dean Willis participated in subsequent discussion.

 

Jonathan:

The reason you need to be able to tell that the URI is a gruu, is that if its not a gruu, you may need to try something else to reach that instance. The specific use case that has come up is transfer. So if A is talking to B, and B provided a GRUU to A, then if A wants to transfer C to B, A can send a REFER to C with Refer-To being that GRUU. But if the Contact wasn't a gruu, it may have to play various tricks people have baked up, like using the AOR (possibly the To of the original INVITE from A to B) along with caller preferences.

 

Text does not provide this explanation however.

007

General

General

Aki Niemi

(8th Aug 2006)

I read GRUU and outbound, and an old nagging concern of mine resurfaced:

what the heck do we need the instance ID for?

Seems outbound uses it to guarantee uniqueness of flows in a registrar, but to me it sounds weird that the task of acquiring unique IDs within the registrar's internal state is left to the UA -- after all, browsers don't generally generate cookies themselves but store whatever the website gives them.

To me, a much better approach would be to have the registrar generate and allocate a unique ID (perhaps the 'opaque' used in GRUU?) for the first REGISTER, and whenever a client registers with that ID again, it is deemed the same UA. A REGISTER without an ID would be another UA instance.

Even DHCP clients' leases seem to survive reboots without some weird URN generation, so I don't think that it's unreasonable to require UAs to store their outbound IDs either. I mean, they already have to store the reg-id, no? (Not to mention web cookies...)

And worst case is you need to garbage-collect some stale flows, in case a UA happens to forget its ID, but that you need to be doing in any case.

We chose a similar approach over instance ID in PUBLISH, which uses etags generated by the server to identify uniqueness of publisher instances. With PUBLISH, UAs are also instructed to remember their etags, even across reboots.

Dean Willis, Dale Worley, Paul Kyzivat, Jonathan Rosenberg, Cullen Jennings, Jesus Javier Arauz, John Elwell, Rohan Mahy participated in subsequent email discussion.

 

Consensus not to adopt Aki’s alternate proposal.

008

General

General

Eric Rescorla (14th August 2006)

I found this document very hard to read. At root, the concept is extremely simple, but the document is 40 pages. IMO it could stand to be put on a pretty serious diet. I realize that this is an editorial comment, and I suppose it's not necessarily a showstopper, but I think it presents a pretty substantial obstacle to implementor understanding--at least it would if I were doing the implementation.

In particular, pages 13-23 contain descriptions of the behaviors expected of various elements in the system. It's quite hard to tell from the text which behaviors are new to this specification and which are simply inherited from other specs and being described here for expository reasons. For instance, here's S 8.1.2:

   There is no new behavior associated with sending a request to a GRUU.

   A GRUU is a URI like any other.  When a UA receives a request or

   response, it knows that the remote target is a GRUU by the presence

   of the "gruu" URI parameter.  The UA can take the GRUU, send a

   request to it, and then be sure that the request is delivered to the

   UA instance which sent the request or response.

   If the GRUU contains the "opaque" URI parameter, a UA can obtain the

   AOR for the user by stripping the "opaque" and "gruu" URI parameters.

   The resulting URI is the AOR.  If the GRUU does not have the "opaque"

   URI parameter, there is no mechanism defined for determining the AOR

   from the GRUU.  Extraction of the AOR from the GRUU is useful for

   call logs and other accounting functions where it is desirable to

   know the user to whom the request was directed.

   Because the instance ID is a callee capabilities parameter, a UA

   might be tempted to send a request to the AOR of a user, and include

   an Accept-Contact header field [19] that indicates a preference for

   routing the request to a UA with a specific instance ID.  Although

   this would appear to have the same effect as sending a request to the

   GRUU, it does not.  The caller preferences expressed in the Accept-

   Contact header field are just preferences.  Its efficacy depends on a

   UA constructing an Accept-Contact header field that interacts with

   domain-processing logic for an AOR, to cause a request to route to a

   particular instance.  Given the variability in routing logic in a

   domain (for example, time-based routing to only selected contacts),

   this doesn't work for many domain-routing policies.  However, this

   specification does not forbid a client from attempting such a

   request, as there may be cases where the desired operation truly is a

   preferential routing request.

The only normative text here is the first sentence, which tells us that there's no new behavior. The rest is purely expository. After reading it, I'm not sure that it's necessary at all, but if it is it should be clearly separated from the normative text. I would advise trying to separate the new normative behavior into separate sections.

I would advise intermixing examples with the main text and then having an extended example at the end. Just having a single extended example that people have to refer back to makes it very hard to get the idea of what's going on.

-11 has nearly a complete rewrite. A new overview was added, authored by EKR. Text was simplified, and some of the more complicated features (opaque) were removed. Non-normative text that is explanatory was indented as a note to clarify its role as such. The -11 spec is now 20% leaner than -10.

009

General

General

Eric Rescorla (14th August 2006)

I'm a bit concerned about a lack of generality in this design.

At some level, the idea here is that you have some URI X and

you'd like to be able to create subordinate URIs XY and XZ

such that they both correspond to X in (at least the following

ways):

 

  0. Either XY or XZ can speak for X.

  1. A peer can address X and he will end up speaking to

     XY or XZ.

  2. A peer can directly address XY and XZ and will end up

     at the right place.

 

This specification provides two mechanisms for doing this:

 

  1. opaque=, which is switched at the proxy.

  2. grid=, which is switched at the end-instance.

 

This seems like a not very general design. In particular, it

would be able to use the same mechanism (e.g., name extension).

Second, it seems like there's a real possibility we might want

to be able to perform this same trick in some other context,

in which case won't we need to invent some new demultiplexing

indicator? It may be too late to redesign things to this

extent, but that doesn't mean this isn't a real issue.

The GRID parameter was removed from GRUU in response to this. Instead, loose routing is proposed to provide the ability of ‘end-instance switching’. The gr URI parameter (formerly gruu URI parameter) now takes a value, replacing opaque as the server-side ‘switch’.

010

General

General

Eric Rescorla (14th August 2006)

Why is it necessary to have GRUUs which are (1) identifiable

as GRUUs to peers but (2) can't be translated back to the AOR

by the peer?

Paul Kyzivat, Dean Willis participated in subsequent email discussion

 

This is still possible in the spec. A temporary GRUU is marked as such but not reverse translateable. The reasoning is as described above in response to Deans comments.

011

General and Section 6, last paragraph

Technical

Robert Sparks (21st Aug 2006

gruu-10 has a mixed message about the requirements on the overall system for saving information about the existence of GRUUs.

 

It notes on page 13 that

* "for any particular AOR, there can be a potentially infinite number of GRUUs"

and goes on to say

*"it is RECOMMENDED that a GRUU be created at the time a contact with an instance ID is first registered to an AOR (even if that registration indicates that the registering UA doesn't even support

GRUUs)

 

This section implies that new state is created at the thing that "owns" GRUUs for each new GRUU that gets created, and recognizes that _clients_ can ask that thing to create an infinite number of them. 

Later in that section it talks about the difficulty of maintaining this state across reboots and power-failures.

 

A little later (page 15) it notes again that a UA MUST be prepared to receive a different GRUU for the same instance-id/AoR pair in subsequent registrations because this owning-thing might lose state.

 

But, off in the appendix, in sections describing the creation of GRUUs it talks about building them such that this owning-thing doesn't have to create new state.

 

Is there a real requirement to keep state here or not?

 

I don't think we meant there to be in the end, and that some of the text is legacy and just needs to be elided or adjusted, but I can't tell for sure, so let me ask the question another way:

 

Is it OK for me as a proxy that has the responsibility for retargeting GRUUs to _always_ return a 480 to a GRUU that I recognize as feasibly mine (cryptographically perhaps), maps correctly (whatever that means) to an AoR in good standing, but has no current registered contact associated with it EVEN IF I have no record of dealing with that particular instance-id ever before?

 

I think it is.

 

Furthermore, I suspect would be an error to return, say, a 404 in the circumstance above - if I'm wrong, then we need text that reinforces that a 404 to a GRUU doesn't say a thing about the existence or viability of an AoR that might be derivable from that GRUU. Same with 410.

 

So if the intent is not to require infinite state storage, can we tune that language out?

(If it was the intent, then we've got other text discussing those ramifications that needs to go in).

Further discussion from Paul Kyzivat, Dean Willis, Dale Worley

Jonathan Rosenberg 11th September 2006:

As others have commented, the spec purposefully allows an implementation to go either way and be compliant. Thus there is no requirement for statefulness.

Indeed, I think 8.2.1 is quite explicit on this point:

If the Request-URI is within the domain of the proxy,

    contains a "gruu" URI parameter, and the GRUU is known within the

    domain and refers to a valid AOR within the domain, but the instance

    ID is unknown, the proxy SHOULD generate a 480 (Temporarily

    Unavailable).

Perhaps the confusion is around what it means to be 'known'. What I meant here, is for stateless registrars, it would mean that the AOR is something you recognize and the opaque param is formatted appropriately and could belong to your domain. For stateful, it would mean that the GRUU is in the database itself.

 

This should all be clearer in -11 now. State storage is not required. The requirements talk of creation and validity, and never of storage of GRUUs.

012

General, section 8.2.1, 8.2.2 8.2.3

Editorial / Technical

Robert Sparks (21st Aug 2006)

I forced myself (1) to forget the various conversations we had around last-hop-spiraling and the interaction of GRUU with outbound and tried to read the proxy behavior section from the point-of-view of an implementer who didn't have the list/meeting history in their head. 

With those preconditions 8.2.1 through 8.2.3 get somewhat confusing.

 

First - It's not clear why there's any distinction between in-dialog and out-of-dialog requests in the first place.

That distinction isn't normal for a proxy - what's special that makes it normal here?

 

Next, if it is necessary to distinguish them, the criteria currently in the draft won't work. You can have out-of-dialog requests show up with Route headers fields.

 

The only difference in behavior that I can back out of the current text (did I miss something?) is dealing with the situation where there is more than one contact currently bound to the GRUU. 

8.2.1 says to use the most recent, 8.2.3 says to pick arbitrarily. To the implementer, this is going to appear arcane at best.

 

Do we really _need_ the distinction? Can we not reduce the whole of section 8.2 down to one or two paragraphs by unifying those sections? (3261 asks you to record-route mid-dialog requests anyhow, so we should be able to roll the 8.2.2 in at the same time).

 

(1) Well, I didn't really have to use much force in order to forget 

_that_ stuff.  :O

 

Additional discussion from Paul Kyzivat

Jonathan Rosenberg 11th September 2006:

You are not alone. Others have commented on this too, clearly it is needing some work.

Well... to be frank at this point its an artifact from previous revisions, where there really was quite different behavior. As of -9 or -10 or something they became more aligned, but it was incrementally edited towards that.

So, I would be inclined to unify the two sections. The one thing from 8.2.3 that needs to be folded in is Route header processing. More below.

Correct. As a side note there is a lot more to say on the concept of initial requests with Route headers. I think it has countless applications, but its a whole other discussion.

So, I need to take the Route header field discussion and put it into

8.2.1 and that should work.

Right. I can't think of a reason why it needs to be different.

 

These two sections have been merged in -11.

013

Summary

General

Vijay Gurbani (22nd Aug 2006)

I had followed earlier versions (-00, -01) of the draft, but then other work took over, until now.  -10 has changed much since I last remember GRUUs; so as I read it now, I am doing so with very little context (which may be good ... or bad).

 

Summary: RFC3261 mandates that the Contact URI be global and persist beyond the lifetime of a dialog.  In practice, this requirement has been hard to meet.  This document proposes the notion of a GRUU to mitigate the rfc3261 requirement on the Contact URI.  A GRUU persists beyond the lifetime of a dialog, and in addition it is globally routable, even if the UA itself has a private address.

There is no addressable comment here.

014

Summary

General

Robert Sparks (22nd Aug 2006)

I believe this document to be technically correct, modulo the questions that I brought to the list separately. I also believe it reflects WG discussions to date. However, it appears to me to still be in the "result of lots of arguing about little things" stage from a clarity point of view and would benefit greatly from another strong editorial revision (I think most non-IETF-attending implementors will give up reading before completing the current document).

It was completely rewritten. Hopefully better now.

015

Abstract

Editorial

Eric Rescorla (14th August 2006)

Abstract:

 

   Several applications of the Session Initiation Protocol (SIP) require

   a user agent (UA) to construct and distribute a URI that can be used

   by anyone on the Internet to route a call to that specific UA

   instance.

 

I would add after this "as opposed to the AOR, which may map to

multiple UA instances"

 

New introduction (from EKR) is clear on this point.

016

Section 1

Editorial

Eric Rescorla (14th August 2006)

S 1:

I don't find this section very clear at all. It manages to hide

the key point about wanting to be able to address specific UAs

rather than the AOR sort of implicitly in para 2.

 

I would take one such one of the examples in S 4 and glue

it in here to make clear what the issue is. I would remove

paras 3 and 4 entirely. I think they're not adding much

value.

 

Fixed.

017

Section 1, fourth paragraph

Editorial

Vijay Gurbani (22nd Aug 2006)

s/to which the user is/to which the host identified by the IP

   address is

 

This text is no longer present in the new introduction.

018

Section 1, last paragraph

Editorial

Vijay Gurbani (22nd Aug 2006)

s/the GRUU properties/the GRUU properties (defined in Section 3)

This text is no longer present in the new introduction.

019

Section 2

Editorial

Jeroen van Bemmel (18th Aug 2006

- "contact: ... bound to an AOR or GRUU" => "... bound to an AOR and GRUU"

Fixed.

020

Section 2

Editorial

Jeroen van Bemmel (18th Aug 2006

- "contact: ... the value of the Contact header field" => "a value" or "a Contact header field"

 

Changed to ‘a value of the contact header field’

021

Section 2

Editorial

Jeroen van Bemmel (18th Aug 2006

- "remote target: ... updated by target refresh requests" => add "or responses"

Fixed.

022

Section 2

Editorial

Jeroen van Bemmel (18th Aug 2006

- "Contact header field: ... Depending on the semantics": isn't it simpler to say that in REGISTER requests and responses a Contact contains a contact, and in all other requests and responses it contains a remote target?

 

No because its also redirects.

023

Section 2

Editorial

Eric Rescorla (14th August 2006)

S 2:

Isn't the key point for "contact" that it's bound to a specific

UA?

 

Right. Added a sentence that says that.

024

Section 3

Editorial

Andrew Allen (23rd Aug 2006)

   A URI can have any combination of these properties.  It is the

   responsibility of the domain which mints the URI to determine what

   properties are conferred upon that URI.  This specification imposes

   requirements on a domain that mints a URI with the GRUU property.

 

Have we used the terminology “mints a URI” in SIP drafts before? If not then I think non native English speakers may have some trouble with the term “mints”. Consider using “assigns”, “allocates” or “manufactures” instead.

Term has been removed.

025

Section 3

Editorial

Jeroen van Bemmel (18th Aug 2006

"The AOR property: ... REGISTER request." => "REGISTER requests" (add 's')

Text is no longer present.

026

Section 3

Editorial

Jeroen van Bemmel (18th Aug 2006

"The alias property: ...is identical to another URI" => "is identical to the treatment of another URI" (is "treatment" well defined here?)

Text is no longer present.

027

Section 3

Editorial

Jeroen van Bemmel (18th Aug 2006

"anonymous property": perhaps better called the "anonymity property"?

Text is no longer present.

028

Section 3

Editorial

Jeroen van Bemmel (18th Aug 2006

The flow of this section is somewhat confusing: It first talks about properties a URI might have, then about three more properties that combine to form the GRUU property, and then adds a remark referring to "these properties" (page 5). Suggestion to have 1 list of all properties, then define the new property 'GRUU' which this specification adds

Text is no longer present.

029

Section 3

Editorial

Eric Rescorla (14th August 2006)

S 3:

I'm not sure that this discussion of properties adds a lot of

value. It's not really referred to much later in the spec

and just adds a lot of new concepts people need to absorb.

In particular, I don't think that the first five properties

(AOR through identity) are that relevant here.

 

Text is no longer present.

030

Section 3, towards the end, second to last paragraph

Editorial

Vijay Gurbani (22nd Aug 2006)

s/of the domain which mints/of the domain that mints

Text is no longer present.

031

Section 4

Editorial

Vijay Gurbani (22nd Aug 2006)

Section 4 does a very good job of explaining the use cases that motivate the need for a GRUU.

 

I had a bit of a rough time hunting the information in the document as I had to skip ahed to the examples section when reading sections 5, 7, and 8.  Not sure what can be done to alleviate this non-linear reading, though.

Hopefully the rewrite has made this easier to follow.

032

Section 4

 

Xavier Marjou

(10th August 2006)

One major comment is the following: when I read the uses-cases of section 4, I derive the requirement that there must be a way to cause "initial" requests only to be sent to a specific UA instance. However, REQ 1 of section 11 implicitly requires it for both "initial" and "subsequent" requests? Why "subsequent" requests must also be sent to a specific UA instance? If not needed, this would remove some sections on Record-Routing (8.2.2) and the processing of subsequent requests (8.2.3).

Subsequently:

I agree that in-dialog requests are already "sent to a specific UA by virtue of Contact". However, my understanding is that Record-Route headers are "only" required for the GRUU draft because GRUU are advertised in the Contact header fields, and not because of a use-case related requirement.

The point is that additional processing is needed by the current draft in home proxies. To remove this (not-needed?) burden, one could imagine other ways to advertise the GRUU (e.g. a Contact-Gruu header field) instead of advertising it in the Contact header field (e.g. in a 200 of INVITE). The remote user-agent would use this other way for initial requests (e.g. if it wants to send a SUBSCRIBE), without impacting the routing of mid-dialog requests in home proxies.

I'm sorry to bring this discussion so late, I just realize this lately.

Paul Kyzivat, Dale Worley participated in subsequent email discussion

 

Consensus to stick with the current method due to its backwards compatibility benefits.

033

Section 4.2

Minor technical

Jeroen van Bemmel (18th Aug 2006

"The URI in the Contact header field also has a callee capabilities [8] parameter which indicates that this URI is a conference URI." I assume this is referring to the "sip.isfocus" media feature tag, which "...indicates that the UA is a conference server" [12]. It is not a URI parameter but a header parameter

Text no longer present.

034

Section 5

Editorial

Andrew Allen (23rd Aug 2006)

   A UA can obtain a GRUU by generating a normal REGISTER request, as

   specified in RFC 3261 [1]. 

 

What is a “normal REGISTER request” or what is an abnormal REGISTER request? Certainly a UA obtaining a GRUU using REGISTER will include extensions in the REGISTER request. I think the word “normal” should be deleted as it doesn’t add anything.

Text no longer present.

035

Section 5

Editorial

Andrew Allen (23rd Aug 2006)

   When a proxy in the domain constructs the GRUU, it would set the

   value of the "opaque" URI parameter such that it includes the

   instance ID.  As such, when that proxy receives a request sent to the

   GRUU, it can determine that the request is a GRUU by the presence of

   the "gruu" parameter, and then it can extract the AOR and instance

   ID, both of which are needed to process the request.

 

 

This text doesn’t align well with the normative procedures in section 9. Certainly it is possible that the “opaque” URI parameter could include the instance ID but it isn’t true that in all cases “it would set the value of the "opaque" URI parameter such that it includes the instance ID”. Either change “would” to could or “can” or redraft this text to more correctly indicate that the "opaque" URI parameter is set such that it possible for a proxy in the domain to obtain the instance ID.

Text no longer present.

036

Section 5

Minor technical

Jeroen van Bemmel (18th Aug 2006

"...will contain the "gruu" parameter in each Contact header field" => "will contain the "gruu" parameter in each corresponding Contact header field"

When the user has multiple registered UAs and some of those don't support GRUU, the REGISTER response would contain their Contacts without 'gruu' parameter

Text no longer present.

037

Section 5

Editorial

Jeroen van Bemmel (18th Aug 2006

"RFC 3261 mandates that the Contact header field have the GRUU property, and this specification provides a reliable way for a UA to obtain one." => "...to fulfill that requirement" (UA obtaining a GRUU property makes no sense)

Text no longer present.

038

Section 5

Minor technical

Jeroen van Bemmel (18th Aug 2006

"...for a UA receiving the message to know whether the remote target is a GRUU or not.This can be known to a remote target through the presence of the "gruu" URI parameter." => " ..or not. It can learn this from the presence of the "gruu" URI parameter"

Text no longer present.

039

Section 5

Minor technical

Jeroen van Bemmel (18th Aug 2006

"...when that proxy receives a request sent to the GRUU, it can determine that the request is a GRUU by the presence of the "gruu" parameter" : although this section si not normative, I believe we said that a proxy should not depend only on the 'gruu' flag for this. Suggest to omit "by the presence of the 'gruu' parameter" here

New text on proxy processing addresses this. It does look for gr parameter, but if not present the implications are not a problem and are discussed in security considerations.

040

Section 5

Editorial

Jeroen van Bemmel (18th Aug 2006

"However, when the server maps the GRUU to the contact bound to it, the server will copy ..." => replace "the server"(2x) by "a proxy" and "it"

Global replacement of “server” with proxy or registrar as appropriate.

041

Section 5

Editorial

Dale Worley (20th Aug 2006)

My comment:

 

> Section 5, page 9:  "that results from stripping out the "opaque" URI

> parameter" s.b. "that results from stripping out the "opaque" and

> "gruu" URI parameters".

 

> But that isn't really the statement we want either, since URI

> "equivalence" is not affected by a URI parameter present in one URI

> and not in the other.  See RFC 3261, section 19.1.4.  That is,

>

>    sip:carol@chicago.com

>    sip:carol@chicago.com;opaque="dRfHgbHjGhImBv";gruu

>

> are equivalent already.  But unfortunately so are:

>

>    sip:carol@chicago.com

>    sip:carol@chicago.com;opaque="dRfHgbHjGhImBv";gruu;hop-sip-and-jump

>

> and we want to rule out the latter pair.

 

Author's response:

 

> Interesting. What this means is that, based on URI equivalence, a GRUU

> will in fact equal its AOR. Hmm. Its not obvious to me that this is a

> bug or a feature. It really depends on what is a reasonable basis for

> URI equality. One reasonable definition is that two URI should be

> equivalent only if requests targeted towards them would reach the same

> user, where 'same' refers to the ability to authenticate with a

> specific credential. With that definition, the GRUU should be equal to

> the AOR based on URI equality.

>

> Since I don't see any real issue with the AOR and GRUU being equal, I

> think all we need to do is state that this is the fact. I changed the

> paragraph we're talking about to read:

>

> <t>

> If the GRUU contains an "opaque" URI parameter, the URI that results

> from stripping out the "opaque" and "gruu" URI parameters MUST be

> equivalent to the AOR associated with the GRUU. Indeed, the GRUU

> itself will also be equivalent to the AOR based on URI comparison,

> since the "gruu" and "opaque" parameters will be ignored during

> comparison, being present in one URI (the GRUU) and not the other (the

> AOR).

> </t>

 

- proposed fix

 

I believe that I confused the issue in the exchange above, as the question is not a matter of a useful definition of "equivalence" (it's far too late to change that, anyway), but that in the passage, we probably don't want to use "equivalence" to describe the relationship between the GRUU and the AOR.

 

I suggest:

 

> If the GRUU contains an "opaque" URI parameter, the URI that results

> from stripping out the "opaque" and "gruu" URI parameters MUST be the

> AOR associated with the GRUU.

 

Using "the same as" is probably stricter than we really need (as textual equality would not allow rearranging the order of URI parameters, and other trivial changes), but it ensures that implementations do not construct GRUUs that confuse other implementations.  Whereas the current wording uses "equivalent", which allows gratuitously adding and deleting URI parameters.

“opaque” has been removed entirely from the specification.

042

Section 5

Editorial

Eric Rescorla (14th August 2006)

S 4:

Having this many use cases doesn't add that much. I would

just delete this section after moving one use case (REFER?)

to the introduction.

 

Removed.

043

Section 5

Editorial

Eric Rescorla (14th August 2006)

S 5:

I didn't find this section that helpful. It seems to me that the

key points to get across are:

 

    1. You have one AOR but multiple GRUUs, each of which is tied

       to a specific UA

    2. You can have multiple GRUUs tied to the same UA.

    3. You can be addressed either by GRUU or AOR, with the latter

       going to some UA out of control of the addressor.

    4. You (generally) get your GRUUs from your proxy.

    5. There are two types of GRUUs, those which can be mapped

       back to the AOR (opaque=) and those which can't.

 

Getting these points across, with a picture would, it seems to me,

get the job done better than this text. I didn't find Figure 3

to be that clear, however. Maybe multiple figures?

 

A new figure has been added that explains the relationship between GRUU, AOR and contacts in a clearer way. Overview has been rewritten.

044

Section 5 2nd paragraph

Editorial

Robert Sparks (22nd Aug 2006)

Suggested fix: This extension defines two separate mechanisms. The first provides one way for a UA to obtain a GRUU. The second allows a UA to use a GRUU, regardless of how it obtained it. <t/><t> This extension defines the protocol operations for obtaining GRUUs through registration, and discusses the alternative of obtaining GRUUs through administrative operation.

Text is no longer present.

045

Section 5 3rd paragraph, last sentence

Minor Technical

Robert Sparks (22nd Aug 2006)

Suggested fix:

    OLD:     instance identifier, the server

    NEW:    instance identifier against the same AoR, the server

Text is no longer present

046

Section 5 7th paragraph (first full text paragraph on page 9)

 

Editorial

Robert Sparks (22nd Aug 2006)

Comment: The first sentence (containing "it would set the value") will be taken as normative by the implement-the-examples crowd. This sentence is true only for one of the suggestions for forming opaque.

Suggested fix: change "would set" to "might set"

 

Construction algorithm for public GRUU actually now requires adding the gr parameter with a value to the AOR.

047

Section 5 8th paragraph, last sentence

Editorial

Robert Sparks (22nd Aug 2006)

Comment: For the first time reader, the consequence described in the last sentence is not yet obvious.

Suggested fix: replace the last sentence with "This allows the UA to tell that the request was originally sent to a GRUU with no grid instead of to an AOR".

Grid has been removed.

048

Section 6

Minor technical

Jeroen van Bemmel (18th Aug 2006

"...the GRUU MUST exhibit the following properties:": add " The URI MUST NOT include the "grid" parameter" as a new bullet

Grid has been removed.

049

Section 6

Minor technical

Eric Rescorla (14th August 2006)

S 6:

 

   o  When a GRUU is assigned to an instance ID/AOR pair, both SIP and

      SIPS GRUUs will be assigned.  Only one will be returned, but both

      will exist.  The SIPS URI may not always work, particularly if the

      proxy cannot establish a secure connection to the client.

 

What does it mean to have a URI assigned that doesn't work?

SIPS processing has been removed.

050

Section 6

Technical

Eric Rescorla (14th August 2006)

   However, forwarding services, such as call forwarding, SHOULD NOT be

   provided for requests sent to a GRUU.  The intent of the GRUU is to

   target a specific UA instance, and this is incompatible with

   forwarding operations.

 

This seems to me to get into policy. Are you saying that I can't

have my cell phone forward calls to some other phone just cause

people call my cell number rather than my generic "EKR" AOR?

 

Paul Kyzivat, Brian Stucker, Dean Willis participated in subsequent email discussion

 

This text remains; I think it needs to.

051

Section 6 first paragraph on page 10

Minor technical

Robert Sparks (22nd Aug 2006)

Comment: the instance identifier uniquely identifies the agent amongst all other user agents (full stop).

Suggested fix: delete "associated with an AOR"

Text no longer present.

052

Section 6 second paragraph on page 10

Editorial

Robert Sparks (22nd Aug 2006)

Comment: I think the diagram covers this paragraph sufficiently and suggest either deleting the paragraph or starting it off with something along the lines of "this paragraph describes the figure 3 in text form".

Removed figure and associated arcane text. Newer diagram is hopefully easier to follow.

053

Section 6 second paragrpah (starting "The contacts that are

bound")

Editorial

Robert Sparks (22nd Aug 2006)

Comment: The important message here (the last two sentences) gets lost under the wieght of the first part of the paragraph. That first part loses me completely, so I'm having a hard time suggesting alternative text. Would anything be lost if it were deleted?

New sections hopefully make this clear.

054

Section 6, figure 3 and section 12, figure 5

Editorial

Dale Worley (20th Aug 2006)

The two figures in the I-D are labeled "figure 3" and "figure 5", rather than the expected "figure 1" and "figure 2" (as in -09).

 

- proposed fix

 

Renumber figures as in -09.

 

I have no control over figure numbering; xml2rfc does weird things.

055

section 6, p. 11

 

Xavier Marjou

(10th August 2006)

p11: in the properties that a GRUU must exhibit, add that the host part of the URI must be equal to the host of the registrar that owns the GRUU.

Subsequently:

Ok, agreed. However, maybe just rephrase my first proposal by indicating that the host part of the GRUU must be under the responsability of the domain that creates the GRUU.

Paul Kyzivat participated in subsequent email discussion

 

Text now says it routes to a home proxy for that domain.

056

Section 6, page 11 second bullet

Minor technical

Robert Sparks (22nd Aug 2006)

Comment: As you point out elsewhere, the thing that is responsible for resolving the GRUU may not actually be a proxy.

Suggested fix: delete proxy from the last sentence in this bullet (leaving "route to a server with access"

The rules for GRUU construction for a registrar are separate for the general GRUU properties and hopefully this is clearer now.

057

Section 6, page 12 first paragraph (Starting "Section 8.2")

Editorial

Robert Sparks (22nd Aug 2006)

Comment: This section is about the creation of GRUUs - this sentence doesn't belong here.

Suggested fix: Delete the sentence

Text no longer present.

058

Section 6, page 12, last full paragraph (starting with "Mid- dialog requests), last sentence

Minor(ish) technical

Robert Sparks (22nd Aug 2006)

Comment: You can get URIs into Route headers of initial requests. 

There is the possibility that this URI would be the same as what you might have record-routed with if this were a mid-dialog request. 

Using Route to distinguish initial requests from mid-dialog requests is not safe as specified here. Given that things like "screening services" are not well defined, I am very nervous about putting normative text around their invokation. It's still very unclear to me that you would ever want to do something different with a GRUU at a proxy if you encountered it in or outside a dialog. If there's a feature that relies on this knowledge, that feature should be asking the UA to participate in giving the featuure-server the information it needs to not do the wrong thing.

Suggested fix: Reduce the strength of the text exploring different services to descriptive. Remove the in-vs-out of dialog distinction text.

The rules on how to determine in vs. out of dialog has been removed. However I still think some words are needed here on services and that text remains.

059

Section 6, page 12, paragraphs 2 through 5 (starting with "When a domain constructs")

Editorial

Robert Sparks (22nd Aug 2006)

Comment: The first of these paragraphs is a no-op and can safely go away. The second and third are all about _USING_ GRUUs, not forming them and doesn't belong in this section. Thier content is covered elsewhere.

Recommendation: Delete these three paragraphs

The whole discussion on properties has been removed.

060

Section 7, 1st full paragraph page 14

Technical

Robert Sparks (22nd Aug 2006)

Comment: This RECOMMENDED almost has a "why this isn't must", but it's not quite all there. Why isn't it a MUST? Is it because UAs can do this differentiation in other ways (I'm not sure I see one), or is it that there are some UAs that won't care?

There is now a section on considerations for registering multiple AOR. The text now uses the contact approach as an example; this is because loose routing is coming and provides a better way.

061

Section 7.1.1.1, 2nd full paragraph - page 14 (If a UA instance is trying to register multiple contacts...)

Editorial / Technical

Robert Sparks (22nd Aug 2006)

Comment: Can we scope this paragraph to GRUUs or delete it? This feels like a very odd general requirement. Even scoped to GRUUs this feels like an inappropriate MUST. Advisory text along the lines of "GRUUs are not intended to provide redundancy through the use of multiple contacts. Implementations seeking that functionality should utilize the mechanisms in [11] instead." would be better.

Its an odd requirement but needs to be there IIRC.

062

Section 7.1.1.1, 5th full paragraph page 14 (starting "If a UA wishes to guarantee")

Minor technical

Robert Sparks (22nd Aug 2006)

Suggested fix:

   OLD: guarantee that the request is not processed

   NEW: guarantee that the REGISTER request is not processed

 

Fixed.

063

Section 7.1.1.1, 5th full paragraph page 14 (starting "If a UA wishes to guarantee")

Editorial

Robert Sparks (22nd Aug 2006)

Suggested fix:

   OLD: option tag. This is in addition to the presence of the Supported header field.

   NEW: option tag, in addition to a Supported header field also containing the "gruu" option tag.

Fixed.

064

Section 7.1.1.1, fourth full paragraph page 14.

Editorial

Robert Sparks (22nd Aug 2006)

This doesn't appear to add anything that we don't already say or get from 3261. Suggest striking it.

I wanted to clarify that these are still possible. I’ll turn it into an informative note and remove the normative language.

065

Section 7.1.1.1, third full paragraph page 14.

Editorial / technical

Robert Sparks (22nd Aug 2006)

Comment: For the last two sentences, which are attempting to avoid GRUU loops, it's not clear if this is a place where the contact violates the SHOULD NOT above it with respect to not containing the "gruu" header field (or is it URI) parameter, or if this is a contact that has no instance-id, gruu, or grid parameters but is still

(somehow) a GRUU?

Text now says that a contact cannot be equivalent to the AOR, and you cannot register a contact that is a gruu (with ;gr param) and instance ID.

066

Section 7.1.1.1, top of page 14, first fractional sentence

Editorial

Robert Sparks (22nd Aug 2006)

Comment/Suggested Fix: Can we put a pointer to wherever we have guidance on how to form these instance ID values at the end of this sentence?

The reference to sip-outbound is right there, and it describes this.

067

Section 7.1.1.1

Minor technical

Jeroen van Bemmel (18th Aug 2006

"...it is RECOMMENDED that a UA instance provide a different contact URI for each AOR": Do we need to specify how this should be done? Implementors might be tempted to use the 'grid' URI parameter for this, but that is not going to work. Distinct username parts would seem best?

Actually, on second thought: is this really needed? a UAS can distinguish requests sent to different AORs by the URI in the To header; using that it can determine the right GRUU to use (ie typically it would maintain a mapping AoR domain -> GRUU )

The normative language around this si gone.All that remains is a for example way of doing this, which mentions using a different user part.

068

Section 7.1.1.1

Editorial

Jeroen van Bemmel (18th Aug 2006

"Specifically, if a contact contains an instance ID" -> capitalize "Contact"

"If a client does include a contact which contains a GRUU" -> idem

Text is no longer present.

069

Section 7.1.1.1

Minor technical

Jeroen van Bemmel (18th Aug 2006

- Perhaps should also say that UA MUST NOT use "gruu" as a value in Proxy-Require (for completeness)

I think it’s a SHOULD NOT. Added.

070

Section 7.1.1.1

Minor technical

Jeroen van Bemmel (18th Aug 2006

- can I get a GRUU for non-SIP Contacts? (e.g. "mailto:")

No, since a proxy has to proxy when it gets a gruu, not redirect, and you can’t proxy to a non-sip URI. Added text about this.

071

Section 7.1.1.2 first paragraph

Editorial

Robert Sparks (22nd Aug 2006)

Comment: This whole paragraph is subjugate to the if in the next paragraph. Suggest restructuring it so everythings under one IF clause.

Paragraph removed.

072

Section 7.1.1.2 first paragraph

Editorial

Robert Sparks (22nd Aug 2006)

Comment: Its not clear what "extract the contacts" means here

Text no longer present.

073

Section 7.1.1.2 page 15 first paragraph

Editorial

Robert Sparks (22nd Aug 2006)

Comment Can we pull the SIP/SIPS behaviors out into one paragraph standing on its own in the document? It should be a simple one. As it stands, my head was swimming after the sentence in this paragraph enough that I couldn't track the next idea.

SIPS processing has been removed.

074

Section 7.1.1.2 page 15 first paragraph somewhere near the middle (look for "domain to a contact with" at the start of a line

Minor technical

Robert Sparks (22nd Aug 2006)

Comment/fix: Suggest changing to "domain to the contact with"

Text no longer present.

075

Section 7.1.1.2 page 15, last paragraph before 7.1.2

Technical

Robert Sparks (22nd Aug 2006)

Comment: This paragraph implies that you _can_ remove, delete, or otherwise invalidate a GRUU through some mechanism. What is it?

As far as I can tell, it's ONLY through the administrative removal of the AoR. I think this paragraph may have meant to be talking about the contacts that might be bound to the GRUU, not the GRUU itself.

Suggested fix: Change this paragraph to explicitly talk about the contacts bound to the GRUU. Add a paragraph noting that GRUUs are never deleted through the mechanisms in this document - that they only go away through administrative removal of the AoR they are associated with.

I don’t understand. This contact is saying that if you get a 4xx to your register it doesn’t remove your GRUU. Subsequent text describes the lifecycle for gruu on the server.

076

Section 7.1.2

 

Francois Audet

(4th Aug 2006)

I'm having some problem reconciling parts of gruu-10 with RFC 3261.

 

(This problem is not gruu-specific, it also applies to the sips guidelines draft).

 

In section 7.1.2 of gruu-10:

 

   A registrar MUST create both the SIP and SIPS versions of the GRUU,

   such that if the GRUU exists, both URI exist.

 

...and later in 7.1.2.1 of gruu-10:

 

   If the To

   header field in the REGISTER request contains a SIP URI, the SIP

   version of the GRUU is returned.  If the To header field in the

   REGISTER request contains a SIPS URI, the SIPS version of the GRUU is

   returned.

 

 

However, in RFC 3261/19.14:

 

   Some operations in this specification require determining whether two

   SIP or SIPS URIs are equivalent.  In this specification, registrars

   need to compare bindings in Contact URIs in REGISTER requests (see

   Section 10.3.).  SIP and SIPS URIs are compared for equality

   according to the following rules:

 

      o  A SIP and SIPS URI are never equivalent.

 

 

It's not clear to me what this all means...

 

Are we saying that when we register, it really doesn't matter if the AOR, and Contact (and GRUU) are SIP or SIP because both will end up being "created"?

 

The distinction between the two in registration would therefore be purely mechanical (i.e., if AOR is SIP, Contact/GRUU is SIP, and if AOR is SIPS, Contact/GRUU is SIPs)?

 

So SIPS and SIP are somehow synchronized bingings, but are "not equivalent" (they seem pretty "equivalent" to me...).

 

This is quite confusing...

 

Can you clarify what you think it means?

 

Jonathan:

 

It is true that SIP and SIPS URI are never equivalent based on URI comparison, but they always point to the same resource, and if one of them exists in a domain, so too does the other.

 

GRUU is discussing the mechanical aspect. Its trying to skirt the bigger issue of what it means to register a SIPS AOR in the To, vs. a SIP AOR.

It just says what happens with GRUU processing depending on which you do. Indeed, we could decide later on to disallow a SIPS URI in a To header field of a REGISTER, and the GRUU spec remains valid.

 

I'm really hoping to not have to figure out the whole sips mess to progress GRUU.

 

Dale Worley participated in subsequent discussion.

 

SIPS processing has been removed from GRUU.

077

Section 7.1.2 second paragraph.

Editorial

Robert Sparks (22nd Aug 2006)

Comment: This will be read to say there are THREE URIs, the GRUU and the SIP and SIPS versions of the GRUU.

Suggested fix. Remove all the SIP/SIPS treatment to its own section, avoid this particular sentence construct in that section.

 

SIPS processing has been removed.

078

Section 7.1.2.1

Editorial

Andrew Allen (23rd Aug 2006)

   A REGISTER request might contain a Require header field; this

   indicates that the registration has to understand this extension in

   order to process the request.

 

This doesn’t make sense. I think we need to replace “registration has to understand” with “registrar has to understand”

 

Thus should read:

 

   A REGISTER request might contain a Require header field; this

   indicates that the registrar has to understand this extension in

   order to process the request.

Right, fixed.

079

Section 7.1.2.1 (no specific place)

 

minor technical

Robert Sparks (22nd Aug 2006)

Comment; It would be useful to point out somewhere that this specification SPECIFICALLY doesn't allow a contact to be bound into the system that will be reached when the GRUU is accessed, but not reached when the AOR is accessed.

Added a note about this in the section on creation of GRUU.

080

Section 7.1.2.1 first paragraph

Minor technical

Robert Sparks (22nd Aug 2006)

Comment/fix: add  "containing the 'gruu' feature tag" after "might contain a Require header field:.

Fixed.

081

Section 7.1.2.1 first paragraph, last sentence

Confused

Robert Sparks (22nd Aug 2006)

Comment: This sentence says contacts omitting the instance parameter are not processed by the rules in this specification, but back on page 14, you talk about registering GRUUs as contacts but leaving of the instance id. Is that that resulting thing a GRUU or not? Either this paragraph or the third full paragraph on page 14 needs clarification.

 

Text on registering a gruu without an instance ID is removed.

082

Section 7.1.2.1 fourth paragraph last sentence

 

editorial / minor technical

Robert Sparks (22nd Aug 2006)

Comment/fix: change the end of the last sentence from "a GRUU" to "any GRUU that is bound to that AoR".

Changed to ‘its GRUUs’

083

Section 7.1.2.1 last paragraph

minor technical

Robert Sparks (22nd Aug 2006)

This looks like normative requirements (MUST NOTs?) in disguise.

SHOULD NOT is OK. Fixed.

084

Section 7.1.2.1 third paragraph page 16

Minor technical

Robert Sparks (22nd Aug 2006)

Comment: Why does the registrar put the instance id in the contact header field if the request didn't contain Supported: gruu? A registrar that doesn't know gruu isn't going to do this. A UA that doesn't know GRUU or outbound isn't going to use it? This looks like a setup for a subtle interop problem later.

Additional discussion by Paul Kyzivat

Actually it should since I think a registrar in 3261 is supposed to store and mirror uknonwn contact params

085

Section 7.1.2.1 top paragraph on page 16

technical / editorial

Robert Sparks (22nd Aug 2006)

Comment: This says to create a GRUU according to the procedures of Section 6, but there are no procedures in section 6, only characteristics, a statement that the process of creation is implementation dependent, and pointers to the appendix for how one might go about such creation.

Suggested fix: s/proceedures/requirements/

Fixed to “characteristics”

086

Section 7.1.2.1 top paragraph on page 16

Editorial

Robert Sparks (22nd Aug 2006)

The pronouns in this paragraph are ambiguous. "it MUST be ignored", "they MUST be discarded"

Suggested fix: use the nouns

 

Fixed.

087

Section 7.2 4th paragraph last sentence

editorial / technical

Robert Sparks (22nd Aug 2006)

Comment: This requirement is very undermotivated. Why must I include the gruu parameter here. Who's going to care and do anything different with it? Normally it would be the thing resolving the GRUU, but in this case, THAT'S ME, not some other proxy. Why are we trying to put requirements on how I talk to myself?

Additional discussion by Paul Kyzivat

 

Conclusion was that it is needed.

088

Section 8 (generally)

Editorial

Robert Sparks (22nd Aug 2006)

Comment: (from the beginning) "home proxy" starts to creep in here

First occurrence includes a reference to sip outbound where this is supposed to be defined.

088

Section 8.1.1

Editorial

Dale Worley

(4th Aug 2006 and 20th Aug 2006)

And some wording issues:

 

   When using a service route,

   this requirement (that the GRUU be obtained from a domain that will

   be visited by the request) it is sufficient to use the GRUU learned

   in the same registration that delivered the service route.

 

This doesn't parse.  Possibly it should read "... to satisfy this requirement (...), it is sufficient ...".

 

Subsequent

 

- proposed fix

 

As proposed by the author on the SIP mailing list:

 

    When using a service route, this requirement (that the GRUU be

    obtained from a domain that will be visited by the request) is

    readily met by using the GRUU learned in the same REGISTER

    response that delivered the service route.

 

Jonathan:

My bad. How about:

 

When using a service

                      route, this requirement (that the GRUU be obtained from

                      a domain that will be visited by the request) is readily

                      met by using the GRUU learned in the same REGISTER

                      response that delivered the service route.

 

There is now a network design considerations section which I think captures this.

 

089

Section 8.1.1

 

Dale Worley

(4th Aug 2006)

   Note that this specification does not require the use of an outbound

   proxy; it merely introduces the previous requirements in cases where

   one is used.

 

I think that "previous" won't be read as intended, as I interpreted it to mean "backward in time (to RFC 3261)", not "the previous paragraph in this document".  How about "...; but in cases where one is used, it adds the above requirements."?

 

 

Jonathan:

Changed to:

 

                      <t>Note that this specification does not require the use

                      of an outbound proxy; the behaviors defined in the

                      previous paragraph only apply in cases where one is

                      used. </t>

 

See new section on network design considerations.

090

Section 8.1.1

Technical

Erkki Koivusalo (28th Aug 2006)

I have not been following up the GRUU related discussions or read the older GRUU draft. Last week I however studied draft-ietf-sip-gruu-10 and met with a paragraph which I was not unfortunately able to

understand:

 

   In addition, if the UA is making use of an outbound proxy, the GRUU

   that is used by the UA MUST be one obtained from a domain that will

   be visited by the request prior to being routed towards the target in

   the Request-URI.  A request can visit multiple domains if, in

   addition to an outbound proxy, a UA asks that a request visit

   additional proxies, identified by additional Route header fields in

   the request.  This can happen when a UA has learned a service route

   using the mechanisms in RFC 3608 [27].  When using a service route,

   this requirement (that the GRUU be obtained from a domain that will

   be visited by the request) it is sufficient to use the GRUU learned

   in the same registration that delivered the service route.  If there

   is no service route, and the request will visit only the single

   specified outbound proxy, the UA needs to make sure that the GRUU it

   used was obtained from the same domain as the outbound proxy.

 

It was especially the last statement which I did not understand at all, and would kindly ask it to be rephrashed:

 

   Barring dynamic mechanisms to discover an outbound proxy, such a

   relationship needs to be configured into the UA.

 

But anyway what is the rationale behind this whole paragraph:

 

- Would routing towards such a GRUU for some reason fail if the request

  did not visit the domain from which the GRUU was obtained ? If yes,

  why ?

 

- Or is it just an optimization to avoid the dialog to be routed at

  first to the outbound proxy which finally resolves the GRUU, just

  to find out that the request must for its final delivery be forwarded

  to the domain from which the GRUU was obtained ?

 

I found that the paragraph has been added into the latest version 10 of gruu draft:

 

>* noted that, in the outbound direction, if the home proxy is not on

>the original request path, another proxy in that domain needs to put in

>a record-route that points to it. Provide links to some mechanism which

>allows a home proxy to get on the outbound request path

> 

>* clarified that, if an outbound proxy is used, the request has to

>   visit the domain from which the gruu was obtained before being

>   forwarded to the party in the r-uri. There are two ways documented

>   to know this:

> 

>    a. using a service route obtained from the same proxy that sent you

>    a gruu

> 

>    b. using an outbound proxy; configuration tells you what domain its

>    from

 

However I was not able to find the related discussions or any rationale or examples to justify it. Please provide clarifications to me, if you can. A link to the corresponding discussion on the mailing list would also do.

See new section on network design considerations.

091

Section 8.1.1

Minor technical

Andrew Allen (23rd Aug 2006)

   If the UA instance has obtained multiple GRUUs for different AORs as

   a result of a registration, it SHOULD use one corresponding to the

   AOR used to send or receive the request.  For sending a request, this

   means that the GRUU corresponds to the AOR present in the From header

   field. 

 

And

 

   The GRUU placed into the Contact header field of the response SHOULD

   correspond to the AOR to which the request was targeted by the peer.

 

 

An issue that I think should be discussed is what happens when a UA uses a TEL URI to send a request. What GRUU should be used in this case? draft-ietf-sipping-gruu-reg-event provides a mechanism that could be used by the domain to provide the UA with a GRUU for TEL URIs however currently draft-ietf-sip-gruu doesn’t mention use with TEL URIs at all or provide any guidance on the allocation of GRUUs for use with TEL URIs. Since a GRUU cannot be a TEL URI the property of being able to obtain the identity used from the GRUU doesn’t exist.

You need to think of a tel URI as a name, and before it is used by a proxy it is translated to an address, whichi s always a sip uri. So, you would use the one associated with that SIP URI. This is an esoteric issue and I think more apropos for another draft.

092

Section 8.1.1

Editorial

Vijay Gurbani (22nd Aug 2006)

you may want to consider moving the paragraph

   "When using a GRUU ... at the "grid" parameter" towards the

   end; i.e., make it the last paragraph.  The reason is that

   as it is situated right now, it breaks the flow of thinking

   between the paragraphs bounding it.  These talk about GRUUs

   requiring a visit through intermediaries, whereas the

   paragraph I point out talks mostly about the "grid" parameter.

 

Section has been reworked.

093

Section 8.1.1

Minor technical

Jeroen van Bemmel (18th Aug 2006

- list of dialog-forming and target refresh requests and responses is incomplete. Should add "1xx responses to dialog-forming requests having a to-tag, UPDATE request + 2xx response"

Fixed.

094

Section 8.1.1

Minor technical

Jeroen van Bemmel (18th Aug 2006

- when a UA uses a GRUU e.g. in a PIDF document, can it convert 'sip' to 'sips' to have the other side use TLS until the proxy?

SIPS and PIDF text has been removed.

095

Section 8.1.1

Technical

Eric Rescorla (14th August 2006)

S 8.1.1:

 

   If the UA instance has obtained multiple GRUUs for different AORs as

   a result of a registration, it SHOULD use one corresponding to the

   AOR used to send or receive the request.

 

Isn't it a security condition for the peer that these match?

 

Indeed and this is now added to security considerations and normative behaviour.

096

Section 8.1.1 first paragraph

Editorial

Robert Sparks (22nd Aug 2006)

Comment: as written, there will be some implementer that won't let you use a third-party gruu (one obtained through a REFER for example) because you don't have an active registration for it.

Suggested fix: Put a paragraph break after the first sentence. 

Replace the second sentence  with "A UA MUST NOT use a GRUU it obtained through registration unless that registration is still active."

There is a difference between sending a request to a GRUU and using ones own gruu. This is clearer now I hope.

097

Section 8.1.1 last paragraph page 19

Editorial

Robert Sparks (22nd Aug 2006)

Comment/fix: change "in requests it generates" to "in all requests it generates"

Now its “all dialog forming requests and responses”

098

Section 8.1.1 second paragraph

Editorial

Robert Sparks (22nd Aug 2006)

Comment: When would an implementation consider violating this SHOULD? 

We should document this (see my architectural concern at the

beginning) or make this a MUST and be done with it.

Privacy considerations. I added a reference to that section.

098A

Section 8.1.1, 4th paragraph

Editorial

Cullen Jennings (9th Sept 2006)

Section 8.1.1. para 4. I really can't figure out what this says - I suspect that I know what is trying to say but when I try to parse the paragraph, my stack overflows. Sorry for such a useless comment - I'm not exactly sure how to improve it.

No one understood it. Hopefully this is all clearer now.

098B

Section 8.1.1, 4th paragraph and section 8.2.2

Technical

Erkki Koivusalo (11th Sept 2006)

See comment 112A

All this was added to gruu-10, but I was unable to find the rationale from the draft or the mailing list. I assumed that the GRUU itself would contain a hostname referring to the domain which has created the GRUU. Thus all the requests targetted to the GRUU would after all be routed to that domain, whether or not that domain is otherwise included to the Route (via Record-Route). But is this a false assumption ?

So what is the rationale behind the processing described in Section

8.1.1 paragraph 4 and Section 8.2.2 ?

- Would routing towards such a GRUU for some reason fail if the request

  did not visit the domain from which the GRUU was obtained ? If yes,

  why ?

- Or is it just an optimization to avoid the dialog to be routed at

  first to the outbound proxy which finally resolves the GRUU, just

  to find out that the request must for its final delivery be forwarded

  to the domain from which the GRUU was obtained ?

- Or something else ?

If this processing is needed, the draft has at least to provide a rationale for it, so that the story becomes understandable.

Offending text all removed. Hopefully clearer now.

099

Section 8.1.1. last paragraph page 18 (first on page 19)

Editorial

Robert Sparks (22nd Aug 2006)

Comment: I can't parse much of this - the sentence on using service route in particular eludes me.

Suggested fix: I don't have one yet - will keep trying to make this make sense.

Removed.

100

Section 8.1.2

Minor Technical

Paul Kyzivat (22nd Aug 2006)

Comment: According to 3261, contacts should always be gruus. But common practice has evolved that they are not. So common practice has also evolved to implement features on the assumption that contacts received from others are not gruus. It does no good to start migrating to a world where contacts may be gruus if you can't tell which are and which are not. That is the purpose of the gruu uri parameter - so that others will believe that this contact is a gruu, and implement their features with that in mind.

 

What is lacking is an explanation of that and a recommendation to implement features assuming the URI is globally routable if it contains a "gruu" parameter. I had been thinking this was already there until I had occasion to go looking for it.

 

Suggested fix: Replace the first paragraph as follows:

 

OLD:

    There is no new behavior associated with sending a request to a GRUU.

    A GRUU is a URI like any other.  When a UA receives a request or

    response, it knows that the remote target is a GRUU by the presence

    of the "gruu" URI parameter.  The UA can take the GRUU, send a

    request to it, and then be sure that the request is delivered to the

    UA instance which sent the request or response.

 

NEW:

    A GRUU is a URI like any other.  When a UA receives a request or

    response, it knows that the remote target is a GRUU by the presence

    of the "gruu" URI parameter.  The UA can take the GRUU, send a

    request to it, and then be sure that the request is delivered to the

    UA instance which sent the request or response.

 

    For UACs that have been assuming the URIs in contact headers in

    messages from others are globally routable there is no new behavior

    associated with sending a request to that URI when it is a GRUU.

 

    However some UACs have been assuming that URIs in received contact

    headers are not globally routable, and using ad hoc techniques when

    targetting requests to them. (E.g. Using the To or From-URI instead

    of the contact URI, or sending a new request in-dialog when an

    out-of-dialog request would otherwise be preferred.) A GRUU-aware

    UAC SHOULD treat a URI containing a "gruu" URI-parameter as globally

    routable, and condition its actions accordingly, if it would

    otherwise consider that URI to not be globally routable.

 

Additional discussion by Dean Willis, Jonathan Rosenberg

 

I seem to recall we decided not to do anything here but I could be wrong.

101

Section 8.1.2 2nd and third paragraphs

Editorial

Robert Sparks (22nd Aug 2006)

Comment: What does any of this have to do with Sending a message to a GRUU (the section title) Suggested fix: Create a new section for these two paragraphs "Sending a request to an AOR derived from a GRUU"

I moved the rendering text to a separate section. The 3rd paragraph is now a note in the dereferencing section.

102

section 8.1.2, p. 19

 

Xavier Marjou

(10th August 2006)

p19: replace "retain" by "copy" (I first understood by "retain" that the proxy would "screen" the grid and its value)

KED comment, not able to accurately locate the error

 

Text no longer present.

103

Section 8.1.3

Technical

Vijay Gurbani (22nd Aug 2006)

Section 8.1.3 says that "If the user agent had previously handed out its GRUU with a "grid" parameter, the incoming Request-URI may contain that parameter."

^^^^ I thought that somewhere it said that the "grid" parameter MUST be reflected in the GRUU by the UAC.  If the UAC drops the "grid" parameter, why bother with it at all?

GRID removed.

104

Section 8.1.3

 

Jeroen van Bemmel (18th Aug 2006

For out-of-dialog requests sent to a GRUU, the To header will contain the GRUU, including the 'grid' parameter (except for broken UACs that strip it).

It seems that for GRUU purposes we could do without proxy copying of 'grid' and just rely on To? (though a URI parameter that survives rewriting can be useful for other applications, of course, for example between proxies)

GRID removed.

105

Section 8.2.1

Editorial

Andrew Allen (23rd Aug 2006)

   Otherwise, handling of the GRUU proceeds as specified in RFC 3261

   Section 16.  For GRUUs, the abstract location service described in

   Section 16.5 is utilized, producing a set of zero or more contacts,

   each of which is associated with the same instance ID.

 

Second sentence should contain RFC 3261 for the Section 16.5 reference to avoid confusion whether this reference is within the present document.

Fixed.

106

Section 8.2.1

Technical

Vijay Gurbani (22nd Aug 2006)

I had trouble following the proxy handling section 8.2.1.

The second paragraph lays out what a proxy should do if the R-URI is a GRUU.  However, what if the R-URI is not a GRUU?  The third paragraph simply assumes that the R-URI is a GRUU ("Otherwise, handling of the GRUU...").  Did you mean "handling of the R-URI instead?

 

If its not a GRUU its not defined by this spec.

106A

Section 8.2.1

Minor technical

Cullen Jennings (9th Sept 2006)

Section 8.1.1. para 4. I really can't figure out what this says - I suspect that I know what is trying to say but when I try to parse the paragraph, my stack overflows. Sorry for such a useless comment - I'm not exactly sure how to improve it.

Worlds worst text. Removed.

107

Section 8.2.1

Editorial

Vijay Gurbani (22nd Aug 2006)

s/This produces zero or one contacts/This produces zero or

   one contact

Text no longer present.

108

Section 8.2.1

Minor technical

Jeroen van Bemmel (18th Aug 2006

"These requests are identified by their lack of a Route header field when received by the proxy": out-of-dialog requests could contain a Route header. It should say something like "request does not contain a Route header that the proxy recognises as one it inserted into a Record-Route header"

Identifiecation of mid-dialog requests by presence of Route is removed.

109

Section 8.2.1

Minor technical

Jeroen van Bemmel (18th Aug 2006

section 9 at the end: elements also need to strip any 'grid' URI parameter, if present, to obtain the AOR

GRID removed from spec.

110

Section 8.2.1, section 12

Technical

Vijay Gurbani (22nd Aug 2006)

I also tried to correlate this section with the example in Section 12 and ran into problems.  I will try to list these -- please see if they make sense.  WRT Figure 5, an INVITE arrives at the proxy in (3).  Since the UAC had no idea that the UAS is reachable using GRUU, it would probably have inserted a R-URI as follows:

 

   INVITE sip:callee@example.com SIP/2.0

 

Now, given this R-URI, I attempted to follow Section 8.2.1 since the request is an out-of-dialog request.  The R-URI does not contain a "gruu" parameter, so none of the text in the second paragraph of Section 8.2.1 applies.  So I go to the next paragraph.  Disregarding the fact that the text uses the word GRUU for the URI (sip:callee@example.com) which is most definately not a GRUU, the proxy does a location server lookup on the URI.

 

What is the expected behavior now?  I can see two outcomes:

 

   1) The proxy rejects the request with a 480; or

   2) What really happens during the REGISTER processing is

   that the AoR gets bound to *three* contacts:

 

   sip:callee@example.com ----is bound to--->

      1/ sip:callee@192.0.2.1

      2/ sip:callee@192.0.2.1;gruu;

          opaque="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

          +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"

      3/ sips:callee@192.0.2.1;gruu;

          opaque="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"

          +sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"

 

   So, now if the proxy gets a R-URI of "sip:callee@example.com",

   it will be mapped to "sip:callee@192.0.2.1" and if the

   proxy gets a GRUU R-URI of

   sip:callee@example.com;gruu;

     opaque="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",

   then this will be mapped to:

   sip:callee@192.0.2.1;grid

 

I suspect that (2) is the right outcome.  Yes?  Reading between the lines in Section 7.1.2.1 appears to point in that direction as well; especially the fourth paragraph: "...If, after that processing, that contact is bound to the AOR, it also becomes bound to the GRU associated with that instance ID/AOR pair."

 

Is this correct?  If so, I would strongly urge that this be highlighted when you talk about the 200 OK response to the REGISTER in the Examples section.  Maybe this is obvious to the people who have been involved in GRUU for a long time, but it certainly was not to me.

 

 

I cannot understand your concern.

111

Section 8.2.2

Editorial

Dale Worley

(4th Aug 2006)

   The

   rules in Section 8.1.1 ensure that at least one proxy in the same

   domain of the home proxy will be visited.

 

"the same domain of" s.b. "the domain of".

 

Jonathan:

Fixed.

 

See network design considerations.

112

Section 8.2.2

Editorial

Dale Worley

(4th Aug 2006)

Also, this entire paragraph is written in reverse logical sequence.

IMHO, it's better to give causes before effects, even if that delays stating the requirement itself:

 

   Firstly:  The rules in Section 8.1.1 ensure that at least one proxy

   in the same domain of the home proxy will be visited.  A home proxy

   can use mechanisms such as Service-Route [27] or UA configuration

   to ensure that it, or a proxy in the same domain, is on the

   outgoing request path.  If such a proxy receives a dialog forming

   request from a UA in its own domain (an originating request) whose

   Contact header field contains a GRUU (indicated by the presence of

   the "gruu" URI parameter) that is also in that domain, the proxy

   MUST generate a record-route which will route to the home proxy.

  

Of course, this is dependent on resolving the content issue above.

Jonathan:

OK. I reworded thusly:

 

                      <t>

                                There are two distinct requirements for record-routing

                                - in the originating domain and in the terminating

                                domain.

                      </t>

 

                      <t>

                                This specification does not require that a UA use an

                                outbound proxy, in which case a dialog forming request

                                may not visit any proxies in the originating

                                domain. However, if the UA is using an outbound proxy,

                                the rules in <xref target="sec-sendto"/> require that

                                at least one proxy in the domain of the home proxy be

                                visited. A home proxy can use mechanisms such as

                                Service-Route <xref target="RFC3608"/> or UA

                                configuration to ensure that it, or a proxy in the

                                same domain, is on the outgoing request path. If such

                                a proxy receives a dialog forming request from a UA in

                                its own domain (an originating request) whose Contact

                                header field contains a GRUU (indicated by the

                                presence of the "gruu" URI parameter) that is also in

                                that domain, the proxy MUST generate a record-route

                                which will route to the home proxy.

                      </t>

 

Section rewritten.

112A

Section 8.2.2

Technical

Cullen Jennings (9th Sept 2006)

I think I am likely confused here. I basically don't see why a simple classic sip trapezoid deployment would ever need to Record Route. The fact that the GRUU refereed to the "home" domain would cause it work get back here. As a side note, I find the terms "home", "edge" etc very undefined outside the IMS context. Anyways, I believe this section might be all right but I am failing to understand what needs to be done and why. If I was a non IMS proxy implementer, I suspect I would just ignore this whole section.

Additional discussion from Erkki Koivusalo. Paul Kyzivat, Jonathan Rosenberg

 

Text now has it such that a normal trapezoid will not require record-routing.

 

113

Section 8.2.2

Editorial

Dale Worley

(4th Aug 2006 and 20th Aug 2006)

I read section 8 of the -10 draft to see if certain passages I'd been having trouble understanding had been resolved, and I ran into the following difficulties:

 

In 8.2.2, I see "The rules in Section 8.1.1 ensure that at least one proxy in the same domain of the home proxy will be visited."  In the context, it appears that this is stating that 8.1.1 ensures that a UA in a domain that issues GRUUs will always have its UAs use an outbound proxy.  And yet I can't see how 8.1.1 forces that, especially in light of the statement "Note that this specification does not require the use of an outbound proxy".

 

Subsequent

Have the author correct the wording, as there seems to be no disagreement on the substance of the passage, in that I now agree that it is a bug in as Jonathan described it.

 

Jonathan:

This is a bug. It should say that, if an outbound proxy is used at all, then the request will visit a proxy in the home domain. But, its valid to use gruu without any outbound proxies.

 

Hopefully fixed. See network design considerations.

 

 

114

section 8.2.2, p. 22

Minor technical

Xavier Marjou

(10th August 2006)

p22: add the motivation for mandating Record-Routing at the originating home proxy.

Record-routing section states that purpose of RR rules are to avoid spirals.

115

section 8.2.3, p. 23

Minor technical

Xavier Marjou

(10th August 2006)

p23: "if there were no additional Route header field values ... any PATH values that were registered MUST be used". Why is this needed? On an initial request, an edge Proxy reached thanks to the Path header field had the opportunity to perform a Record-Route in order to be in the Route set in subsequent requests. As the previous sentence indicates that the remaining Route header for subsequent requests must no be touched, the Path does not have to be taken into account for subsequent requests.

The section on mid-dialog and out-of-dialog targeting have been merged and this makes more sense now.

115A

section 8.2.3

Minor technical?

Cullen Jennings (9th Sept 2006)

Section 8.2.3 - This is probably just my missing something in reading this but I did not see how the procession of mid dialog requests was different that than 8.2.1. Can we delete this section.

Sections merged.

116

Section 10

Minor technical

Dale Worley (20th Aug 2006)

My original comment:

 

> Section 10, page 23:  ""gruu" EQUAL LDQUOT (SIP-URI / SIPS-URI)

> RDQUOT" is not what we want, I think.  I think the semantics we are

> looking for is ""gruu" EQUAL quoted-string, where the value

> represented by the quoted-string is a SIP-URI or SIPS-URI".  (That

> latter could be represented in BNF, but that would make it less

> clear.)

 

> Due to the details of the grammar, the new formulation differs from

> the original only in some unusual cases, such as allowing:

>

>      Contact: <...>;gruu="sip:gruu\~123456789@example.com;gruu"

>

> (The GRUU is <sip:gruu~123456789@example.com;gruu>.)

>

> But it seems to me that it is non-orthogonal (and inviting trouble) to

> have the grammar for c-p-gruu forbid backslash-escapes of characters

> that do not require them, when the grammar for generic-param allows

> them.

 

Author's response:

 

> Egads. I disagree here. The SIP URI itself cannot contain a quote, so

> there is no need to ever use backslash escaping. I think folks might

> get confused by backslash escaping here. If you just put the unescaped

> URI in, you'll never have a problem. Why allow escaping?

 

My response:

 

I see it as a dangerous thing to introduce differing rules as to what escaping is allowed and forbidden in different parameters.  As a matter of layering, it should be possible to write a parser that can correctly parse the values of all parameters, and conversely, a composer that can correctly represent any set of values for any parmeters, and neither should require special knowledge of any particular parameters.  (Note that the grammar of RFC 3261 adhered to this principle.)

 

Since in the general case, RFC 3261 allows, e.g., a parameter value of "a~b" to be represented

 

>      Contact: <...>;unknown-parameter="a\~b"

 

Then it should be acceptable to escape any occurrence of "~" in any header-parameter using "\", as in the case in my original comment.

Otherwise, the parser and composer for name-addr's will need continual tweaking to accomodate the special restrictions of each newly standardized header-parameter.  In this case, the composer needs to know that while the generic grammar allows any character that can appear in a value to be escaped with "\" (and for a few, it is mandatory), that in the gruu parameter, escaping is forbidden.

 

(Although unfortunately, this principle is already violated in regard to string-value's in feature-param's (RFC 3840), where the header-parameter value must contain an unescaped "<", followed by the string value itself, and then an unescaped ">", but any occurrences of "<" and ">" in the string value must be escaped "\".  And those rules provide no practical benefit, as a general URI parser must already be able to handle both escaped and un-escaped "<" and ">" in all positions within quoted header-parameter values.)

 

- proposed fix

 

Substitute:

 

    c-p-gruu        =  "gruu" EQUAL quoted-string

 

This would imply that c-p-gruu is to be intrpreted as any other quoted-string that is the value of a header-parameter.  That the value represented by the quoted-string is a sip or sips URI is not enforced by this grammar, but is stated elsewhere in the document.

 

 

Fixed per your suggestion.

117

Section 12

Editorial

Vijay Gurbani (22nd Aug 2006)

Also in Section 12, I think it will be very helpful to fill in the missing details of the following messages: (4), (7), and (8).  Clearly, the proxy R-Rs, following text of Section 8.2.2, and that is why the ACK goes to it.  But since the example does not fill in the missing pieces, it is very hard to understand what is going on.

 

I’ll pass on this.

118

Section 12

Technical

Vijay Gurbani (22nd Aug 2006)

In Section 12, you demonstrate the UAC crashing and rebooting.

Upon reboot, it gets the same GRUU.  Upon getting the 200 OK, the newly rebooted UAC knows that it has a pending, and now stale, registration.  Should it not send a REGISTER expiring the GRUU corresponding to the contact sip:callee@192.0.2.1?

NO! It is not needed. That’s the whole point of the rules in sip-outbound. I have stated that in the examples section.

119

Section 12

Editorial

Dale Worley (20th Aug 2006)

Example messages are indented by different amounts.

 

Continuation line of header is missing its initial whitespace (or an <allOneLine> construction was omitted) in the example at the bottom of page 30:

 

    Contact: <sip:callee@192.0.2.2>

    ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>"

 

- proposed fix

 

Indent the example messages consistently.

 

Correct the presentation of the split Contact header.

----------------------------------------------------------------------

Fixed.

120

Section 12

 

Eric Rescorla (14th August 2006)

S 12:

Is there any way you can notate the "changed" headers so it's

easier to see what this specification affects?

 

Please show the INVITE in message 3 for completeness.

 

In the subscribe on page 30, you have:

 

   location lookup on the Request-URI.  It is translated into the

   contact for that instance, and then proxied to that contact.  Note

   how the "grid" parameter is maintained, and the "gruu" parameter is

   no longer present.

 

This only applies to the URI in the request line, not to the "To"

line.

 

   The registrar notices that a different contact, sip:callee@192.0.2.1,

   is already associated with the same instance ID.  It registers the

   new one too and returns both in the REGISTER response.  Both have the

   same GRUU.  However, only this new contact (the most recently

   registered one) will be used by the proxy for population in the

   target set.  The registrar then generates the following response:

 

Why is it a good idea to register both instead of replacing the

old one? I appreciate this is in Outbound, but I don't much like

it there either...

 

Its not easy for me to show whats changed. I’ll pass on adding more messages. Your other point needs to be addressed to the list as part of a discussion on sip outbound.

121

Section 12

E

Francois Audet

9th August 2006

   In section 12, I would like to see the content of messages 3 and 4.

In particular,

    I'd like to see what the Request-URI for those two messages would look like. For

    example, I'm assuming that Message 4's Request-URI would be as Message 9's

    Request-URI?

So send text.

122

section 12, p. 29

 

Xavier Marjou

(10th August 2006)

p29: Record-Route is missing in 200 of INVITE

No longer needed, so the message is OK actually.

123

section 12, p. 30

 

Xavier Marjou

(10th August 2006)

p31: idem for 200 of SUBSCRIBE

As above.

124

section 13, Security considerations

minor technical

Robert Sparks (22nd Aug 2006)

Comment: We talk about how there is no privacy coming from a GRUU and how we can guess instance-ids or repeated instance-ids with against a given AoR, but I don't think we talk about hotelling. If you know the last person that used a particular device (because you knew they were in a cube or a hotel room) and you watched the instance-id they used, then if you know the next person using that device, you can guess a gruu for them. Does that do you any good? Imagine you were traveling and were letting your assistant (we all have those, right) answer your calls, but you'd grab them if it rang more than twice...

Don’t follow. Anyway we have temporary gruu now.

124A

section 13

Technical

Cullen Jennings (09th Sept 2006)

Would you agree to put in the security section that any UA that is sending a request where it has set the From header field value to Anonymous MUST not use a GRUU that does not have the anonymous property? I suspect the answer to this will be yes - I'm still trying to think about the implications of this and trade offs.

New extensive privacy section.

125

Section A.2

Technical

Eric Rescorla (14th August 2006)

S A.2:

The algorithm described here treats encryption as a black-box

in a way that is potentially severely cryptographically weak.

In particular, you have:

 

   In many cases, it will be desirable to construct the GRUU in such a

   way that it will not be possible, based on inspection of the URI, to

   determine the Contact URI that the GRUU translates to.  It may also

   be desirable to construct it so that it will not be possible to

   determine the instance ID/AOR pair associated with the GRUU.  Whether

   a GRUU should be constructed with this property is a local policy

   decision.

 

   With these rules, it is possible to construct a GRUU without

   requiring the maintenance of any additional state.  To do that, the

   URI would be constructed in the following fashion:

 

      user-part = "GRUU" | BASE64(E(K, (salt | " " | AOR | " " |

      instance ID)))

 

   Where E(K,X) represents a suitable encryption function (such as AES

   with 128-bit keys) with key K applied to data block X, and the "|"

   operator signifies concatenation.  The single space (" ") between

   components is used as a delimiter, so that the components can easily

   be extracted after decryption.  Salt represents a random string that

   prevents a client from obtaining pairs of known plaintext and

   ciphertext.  A good choice would be at least 128 bits of randomness

   in the salt.

 

You're assuming that you have a cipher that propagates differences,

but not all ciphers do. For instance, block ciphers in ECB mode

and stream ciphers (or CTR mode ciphers) do not. It's nowhere

near specific enough to say "a suitable encryption function such

as AES with 128-bit keys" As a second note, it's not safe to

use stream cipher with the same key repeatedly, which is what's

implied by this text.

 

The correct procedure here isn't to use a *salt* but rather an

IV. Yes, in the case of a block cipher this gets prepended to the

data (at least notionally) but in the case of a CTR-mode cipher

it's used as part of the counter block.

 

   Encryption is needed to prevent attacks whereby

   the server is sent requests with fake GRUUs, causing the server to

   direct requests to any named URI.  Even with encryption, the proxy

   should validate the user part after decryption.  In particular, the

   AOR should be managed by the proxy in that domain.

 

Encryption doesn't provide this service. If, for instance, you

used a stream cipher or a block cipher in CTR mode, an attacker

could still forge new GRUUs with chosen properties based on

a known initial URI/GRUU pair. This is potentially even possible

in CBC mode depending on how things are laid out. What you need

here is an integrity check.

 

Rather than trying to invent this token format, I would suggest

you borrow one from an existing document, such as that in RFC 4507.

Here's some text based on that:

 

   With these rules, it is possible to construct a GRUU without

   requiring the maintenance of any additional state. The

   proxy needs to store two randomly chosen secret keys:

 

   K_e -- used for encryption

   K_m -- used for integrity

 

 

   For each new GRUU, the proxy generates a fresh initialization

   vector (IV) I. It then computes:

 

   EA = E(K_e, AOR || " " || instance_ID)

 

   using initialization vector I where || indicates concatenation.

 

   The encryption algorithm SHOULD be chosen so that it is not

   feasible for an attacker two distinguish identical plaintexts when

   they are encrypted with distinct IVs. The encryption algorithm

   SHOULD be chosen to provide at least 80 bits of security, Suitable

   algorithms would include AES in cipher-block-chaining (CBC) mode

   [1] or counter (CTR) modes [2]. Note that if CTR mode is used,

   extreme care MUST be taken to ensure that not only are distinct

   IVs chosen but that the same section of keystream is never

   reused.

 

   Once EA has been computed, the proxy computes:

 

   HM = MAC(K_m, EA)

 

   Where HM is a suitable MAC function, such as HMAC-SHA1 [3].

  

   The GRUU is then constructed as:

 

   user-part = "GRUU" || BASE64(EA || HM)

 

   This mechanism uses the user-part of the SIP URI to convey the

   encrypted AOR and instance ID.  The user-part is used instead of the

   "opaque" URI parameter because it has the desired anonymity

   properties.

 

   The benefit of this mechanism is that a server need not store

   additional information on mapping a GRUU to its corresponding

   contact.  The user-part of the GRUU contains the instance ID and

   AOR.  Assuming that the domain stores registrations in a database

   indexed by the AOR, the proxy processing the GRUU would look up the

   AOR, extract the currently registered contacts, and find the one

   that matches the instance ID encoded in the Request-URI.  The

   contact whose instance ID is that instance ID is then used as the

   translated version of the GRUU.  Message integrity is needed to

   prevent attacks whereby the server is sent requests with fake

   GRUUs, causing the server to direct requests to any named URI.

 

   While this approach has many benefits, it has the drawback of

   producing somewhat longer GRUUs because of expansion due to

   the padding and base64 encoding.

 

 

 

[1] National Institute of Standards and Technology,

    Specification for the Advanced Encryption Standard (AES)"

    FIPS 197.  November 26, 2001.

 

 

[2] Housley, R., "Using Advanced Encryption Standard (AES) Counter

    Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686,

    January 2004.

 

[3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:  Keyed-

    Hashing for Message Authentication", RFC 2104, February

    1997.

 

Replaced text with Ekrs suggested text.