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 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, 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 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 (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. |
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? |
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. |
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? |
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. |
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 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 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 |
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 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 |
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 |
I think I am likely confused
here. I basically don't see why a simple classic sip trapezoid deployment
would ever need to |
Additional
discussion from Erkki Koivusalo. 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 |
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 |
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. |