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 |
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). |
|
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. |
|
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. |
|
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 |
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. |
007 |
General |
General |
Aki Niemi (8th Aug 2006) |
I read GRUU and
outbound, and an old nagging concern of mine resurfaced: what the heck do we need the instance ID for? Seems outbound
uses it to guarantee uniqueness of flows in a registrar, but to me it sounds
weird that the task of acquiring unique IDs within the registrar's internal
state is left to the UA -- after all, browsers don't generally generate
cookies themselves but store whatever the website gives them. To me, a much
better approach would be to have the registrar generate and allocate a unique
ID (perhaps the 'opaque' used in GRUU?) for the first REGISTER, and whenever
a client registers with that ID again, it is deemed the same UA. A REGISTER
without an ID would be another UA instance. Even DHCP
clients' leases seem to survive reboots without some weird URN generation, so
I don't think that it's unreasonable to require UAs
to store their outbound IDs either. I mean, they already have to store the reg-id, no? (Not to mention web cookies...) And worst case
is you need to garbage-collect some stale flows, in case a UA happens to
forget its ID, but that you need to be doing in any case. We chose a
similar approach over instance ID in PUBLISH, which uses etags
generated by the server to identify uniqueness of publisher instances. With
PUBLISH, UAs are also instructed to remember their etags, even across reboots. |
Dean Willis,
Dale Worley, Paul Kyzivat, Jonathan Rosenberg,
Cullen Jennings, Jesus Javier Arauz, John Elwell, Rohan Mahy participated in subsequent email discussion. |
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. |
|
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. |
|
010 |
General |
General |
Eric Rescorla (14th August 2006) |
Why is it
necessary to have GRUUs which are (1) identifiable as GRUUs to peers but (2) can't be translated back to the
AOR by the peer? |
Paul Kyzivat, Dean Willis participated in subsequent email
discussion |
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 |
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 |
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. |
|
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). |
|
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" |
|
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. |
|
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 |
|
018 |
Section 1, last
paragraph |
Editorial |
Vijay Gurbani (22nd Aug 2006) |
s/the GRUU
properties/the GRUU properties (defined in Section 3) |
|
019 |
Section 2 |
Editorial |
Jeroen van Bemmel
(18th Aug 2006 |
- "contact:
... bound to an AOR or GRUU" => "... bound to an AOR and
GRUU" |
|
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" |
|
021 |
Section 2 |
Editorial |
Jeroen van Bemmel
(18th Aug 2006 |
- "remote
target: ... updated by target refresh requests" => add "or
responses" |
|
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? |
|
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? |
|
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. |
|
025 |
Section 3 |
Editorial |
Jeroen van Bemmel
(18th Aug 2006 |
"The AOR
property: ... REGISTER request." => "REGISTER requests"
(add 's') |
|
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?) |
|
027 |
Section 3 |
Editorial |
Jeroen van Bemmel
(18th Aug 2006 |
"anonymous property": perhaps better called the
"anonymity property"? |
|
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 |
|
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. |
|
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 |
|
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. |
|
032 |
Section 4 |
|
Xavier Marjou (10th August
2006) |
One major
comment is the following: when I read the uses-cases of section 4, I derive
the requirement that there must be a way to cause "initial"
requests only to be sent to a specific UA instance. However, REQ 1 of section
11 implicitly requires it for both "initial" and
"subsequent" requests? Why "subsequent" requests must
also be sent to a specific UA instance? If not needed, this would remove some
sections on Record-Routing (8.2.2) and the processing of subsequent requests
(8.2.3). Subsequently: I agree that
in-dialog requests are already "sent to a specific UA by virtue of
Contact". However, my understanding is that Record-Route headers are
"only" required for the GRUU draft because GRUU are advertised in
the Contact header fields, and not because of a use-case related requirement. The point is
that additional processing is needed by the current draft in home proxies. To
remove this (not-needed?) burden, one could imagine other ways to advertise
the GRUU (e.g. a Contact-Gruu header field) instead
of advertising it in the Contact header field (e.g. in a 200 of INVITE). The
remote user-agent would use this other way for initial requests (e.g. if it
wants to send a SUBSCRIBE), without impacting the routing of mid-dialog
requests in home proxies. I'm sorry to
bring this discussion so late, I just realize this lately. |
Paul Kyzivat, Dale Worley participated in subsequent email
discussion |
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 |
|
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. |
|
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. |
|
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 |
|
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) |
|
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" |
|
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 |
|
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" |
|
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. |
|
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. |
|
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? |
|
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. |
|
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 |
|
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" |
|
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". |
|
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 |
|
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? |
|
050 |
Section 6 |
Technical |
Eric Rescorla (14th August 2006) |
However, forwarding services, such as call
forwarding, SHOULD NOT be provided for
requests sent to a GRUU. The intent of
the GRUU is to target a specific UA instance, and this is
incompatible with forwarding
operations. This seems to me
to get into policy. Are you saying that I can't have my cell
phone forward calls to some other phone just cause people call my cell number rather than my
generic "EKR" AOR? |
Paul Kyzivat, Brian Stucker, Dean
Willis participated in subsequent email discussion |
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" |
|
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". |
|
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? |
|
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. |
|
055 |
section 6, p. 11 |
|
Xavier Marjou (10th August
2006) |
p11: in the
properties that a GRUU must exhibit, add that the host part of the URI must
be equal to the host of the registrar that owns the GRUU. Subsequently: Ok, agreed.
However, maybe just rephrase my first proposal by indicating that the host
part of the GRUU must be under the responsability
of the domain that creates the GRUU. |
Paul Kyzivat participated in subsequent email discussion |
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" |
|
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 |
|
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. |
|
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 |
|
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? |
|
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. |
|
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 |
|
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. |
|
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. |
|
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? |
|
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? |
|
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 ) |
|
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 |
|
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) |
|
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:") |
|
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. |
|
072 |
Section 7.1.1.2
first paragraph |
Editorial |
Robert Sparks
(22nd Aug 2006) |
Comment: Its not
clear what "extract the contacts" means here |
|
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. |
|
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" |
|
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. |
|
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. |
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. |
|
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. |
|
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. |
|
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:. |
|
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. |
|
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". |
|
083 |
Section 7.1.2.1
last paragraph |
minor technical |
Robert Sparks
(22nd Aug 2006) |
This looks like
normative requirements (MUST NOTs?) in disguise. |
|
084 |
Section 7.1.2.1
third paragraph page 16 |
Minor technical |
Robert Sparks
(22nd Aug 2006) |
Comment: Why
does the registrar put the instance id in the contact header field if the
request didn't contain Supported: gruu? A registrar
that doesn't know gruu isn't going to do this. A UA
that doesn't know GRUU or outbound isn't going to use it? This looks like a
setup for a subtle interop problem later. |
Additional
discussion by Paul Kyzivat |
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/ |
|
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 |
|
087 |
Section 7.2 4th
paragraph last sentence |
editorial /
technical |
Robert Sparks
(22nd Aug 2006) |
Comment: This
requirement is very undermotivated. Why must I
include the gruu parameter here.
Who's going to care and do anything different with it? Normally it would be
the thing resolving the GRUU, but in this case, THAT'S ME, not some other
proxy. Why are we trying to put requirements on how I talk to myself? |
Additional
discussion by Paul Kyzivat |
088 |
Section 8
(generally) |
Editorial |
Robert Sparks
(22nd Aug 2006) |
Comment: (from
the beginning) "home proxy" starts to creep in here |
|
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. |
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> |
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. |
|
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. |
|
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. |
|
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" |
|
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? |
|
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? |
|
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." |
|
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" |
|
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. |
|
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. |
|
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. |
|
100 |
Section 8.1.2 |
Minor Technical |
Paul Kyzivat (22nd Aug 2006) |
Comment:
According to 3261, contacts should always be gruus.
But common practice has evolved that they are not. So common practice has
also evolved to implement features on the assumption that contacts received
from others are not gruus. It does no good to start
migrating to a world where contacts may be gruus if
you can't tell which are and which are not. That is the purpose of the gruu uri parameter - so that
others will believe that this contact is a gruu,
and implement their features with that in mind. What is lacking
is an explanation of that and a recommendation to implement features assuming
the URI is globally routable if it contains a "gruu"
parameter. I had been thinking this was already there until I had occasion to
go looking for it. Suggested fix:
Replace the first paragraph as follows: OLD: There is no new behavior
associated with sending a request to a GRUU. A GRUU is a URI like any other. When a UA receives a request or response, it knows that the remote target
is a GRUU by the presence of the "gruu" URI parameter.
The UA can take the GRUU, send a request to it, and then be sure that the
request is delivered to the UA instance which sent the request or
response. NEW: A GRUU is a URI like any other. When a UA receives a request or response, it knows that the remote target
is a GRUU by the presence of the "gruu" URI parameter.
The UA can take the GRUU, send a request to it, and then be sure that the
request is delivered to the UA instance which sent the request or
response. For UACs that
have been assuming the URIs in contact headers in messages from others are globally
routable there is no new behavior associated with
sending a request to that URI when it is a GRUU. However some UACs
have been assuming that URIs in received contact headers are not globally routable, and
using ad hoc techniques when targetting
requests to them. (E.g. Using the To or From-URI instead of the contact URI, or sending a new
request in-dialog when an out-of-dialog
request would otherwise be preferred.) A GRUU-aware UAC SHOULD treat a URI containing a
"gruu" URI-parameter as globally routable, and condition its actions
accordingly, if it would otherwise
consider that URI to not be globally routable. |
Additional
discussion by Dean Willis |
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" |
|
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 |
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? |
|
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) |
|
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. |
|
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? |
|
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. |
|
107 |
Section 8.2.1 |
Editorial |
Vijay Gurbani (22nd Aug 2006) |
s/This produces
zero or one contacts/This produces zero or one contact |
|
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" |
|
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 |
|
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. |
|
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. |
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> |
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 |
|
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. |
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. |
|
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. |
|
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. |
|
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. |
|
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. |
|
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? |
|
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. ---------------------------------------------------------------------- |
|
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... |
|
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? |
|
122 |
section 12, p.
29 |
|
Xavier Marjou (10th August
2006) |
p29:
Record-Route is missing in 200 of INVITE |
|
123 |
section 12, p.
30 |
|
Xavier Marjou (10th August
2006) |
p31: idem for
200 of SUBSCRIBE |
|
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... |
|
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. |
|
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. |
|