Subject: [Sip] Comment on draft-roach-sipcore-rfc3265bis-00

From: "Elwell, John" <[email-masked]>
Date: Sun, 22 Mar 2009 15:41:16 +0000

Adam,

Thanks for producing this draft, which should set a good example for
revisions of the other SIPCORE RFCs.

I found little to comment on, apart from the following:

In 4.5.1:
"Notifiers MUST implement the GRUU extension defined in
   [I-D.ietf-sip-gruu], and MUST use a GRUU as their local target."

1. Is this just for a SUBSCRIBE-initiated dialog or for any dialog?

2. Should this be package-dependent? For example, there may be some
event packages for which there is no need for subscribing to a resource
on the same device.

3. What if the registrar doesn't support GRUU, and therefore the
notifier is unable to obtain a GRUU?

And by the way, in appendix C I didn't see a mention of changes relating
to the use of GRUU.

John

---

From: Adam Roach <[email-masked]>
Date: Sun, 22 Mar 2009 16:24:05 -0700

> 1. Is this just for a SUBSCRIBE-initiated dialog or for any dialog?

The intention is that any UA capable of sending a NOTIFY message in any 
context will use a GRUU for all dialogs. This mechanism is to be used 
instead of dialog re-use. The most common case of dialog re-use right 
now is sending a SUBSCRIBE down an existing dialog that was initially 
established by an INVITE. So, for current use cases, using GRUU in 
INVITE dialogs is the most important thing. For future-proofing, we need 
to require GRUU for all dialogs.

> event packages for which there is no need for subscribing to a resource

I think it's likely to be too difficult to guess, ahead of time, which 
packages will never need to target the same device as another dialog. 
It's far too easy to envision a circumstance in which we say, "I can't 
think of any reason someone would need to target a specific device for 
package foo," only to discover a really clever usage several years later 
that we have accidentally precluded.

> notifier is unable to obtain a GRUU?

Note, first of all, that this constraint is placed on notifiers, and not 
on subscribers. For the vast majority of notifiers, a self-made GRUU 
(which requires no registrar support) is appropriate.

However, your point is taken, and we should discuss circumstances in 
which registering clients that send NOTIFY messages request a GRUU from 
their registrar, yet receive none. Because of the true interoperability 
nightmare that has resulted from dialog sharing, my suggestion would be 
to disable notifier functionality on those endpoints under such 
circumstances (perhaps with an implementation option to fall back to 
3265 behavior for the truly masochistic).

> And by the way, in appendix C I didn't see a mention of changes relating

Sorry about that. My intention was to include that as part of C.1.21, 
but I left it out.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Mar 2009 09:55:52 -0400

Adam Roach wrote:

> Because of the true interoperability 

Can you say more about the "true interoperability nightmare that has 
resulted from dialog sharing"?

I understand that there undoubtedly are interop issues due to some UAs 
not supporting dialog sharing. There are also interop issues due to the 
UAs not supporting an event package, or not supporting GRUU, or 
whatever. Is one more of a nightmare than another?

Dialog sharing has been a legal possibility since 3261 was published. So 
it shouldn't be a surprise to anybody. If somebody didn't implement 
support, well, what can you say?

It was used primarily because contacts in dialogs often don't have the 
gruu property, and GRUU hasn't been widely implemented. Has that 
situation changed? Will 3265bis somehow result in widespread 
implementation of GRUU by registrars?

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 23 Mar 2009 15:44:54 -0700

Paul Kyzivat wrote:
>
>
> Adam Roach wrote:
>
>> Because of the true interoperability nightmare that has resulted from 
>> dialog sharing, my suggestion would be to disable notifier 
>> functionality on those endpoints under such circumstances (perhaps 
>> with an implementation option to fall back to 3265 behavior for the 
>> truly masochistic).
>
> not supporting dialog sharing. There are also interop issues due to 
> the UAs not supporting an event package, or not supporting GRUU, or 

It's not lack of support that worries me -- it's mismatched views of 
dialog and usage state between two endpoints who both think they've 
implemented dialog sharing. The problem is not that things negotiate 
down to a lesser set of capabilities -- it's that things act broken in a 
way that exposes this mixed-up view of whether a dialog (and its 
associated session/subscription) is active.

> Dialog sharing has been a legal possibility since 3261 was published. 
> So it shouldn't be a surprise to anybody. If somebody didn't implement 

As one of the key perpetrators of that particular aspect of 3261, I'm 
comfortable in saying that we added it in a slapdash fashion at the 11th 
hour, without sufficient analysis (and I mean this in a self-deprecating 
way, without intending to cast aspersions on any of 3261's editors). 
Interactions between usages in a dialog were ridiculously 
underspecified. Robert spent a long time trying to rationalize this 
behavior after the fact, with the result being RFC 5057. And RFC 5057 
really helps a lot for the minority of implementors who actually know it 
exists. However, the issue is complicated enough that it takes 26 pages 
to untangle it, and the rules are a tangle of exceptions. Go read 5057 
again, and tell me that people are more likely to get that right than 
they are to get confused.

> implementation of GRUU by registrars? 

3265bis is less mature than GRUU (in that one is a -00 individual draft, 
and the other is in the RFC editor queue). I think it's reasonable to 
rely on predecessor technologies.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Mar 2009 19:25:27 -0400

Adam,

Don't get me wrong. I think this is a problem any way you turn.

I was pretty heavily involved in gruu. It certainly intended to solve a 
problem, but it too ended up much more complex than anybody hoped it 
would - to the point that I suspect there is a lot of reluctance to 
implement it, and a fair amount of potential to implement it wrong. On 
top of that, I suspect many feel they haven't needed it so far, and can 
get away without it, because the magic of SBCs eliminates the need.

Also, I know of significant deployed uses of dialog sharing, that 
probably won't go away any time soon even after deprecation.

If we had it to do over, I would not include dialog sharing in 3261. But 
despite the potential problems with it, I think that horse is out of the 
barn and will not be put back in, especially since that barn is on fire.

IMO the more likely thing is to encourage everyone who can to put a ;gr 
on their contacts, and to make a best practice of using out-of-dialog 
subscriptions/refers, etc. whenever the target address has ;gr. But if 
it doesn't, then I think one should go ahead and use dialog sharing. Of 
course one is free to refrain from carrying out some feature rather than 
initiating it via dialog sharing, but if you are on the receiving end, 
then I think support is still expected.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 23 Mar 2009 16:42:52 -0700

On 3/23/09 4:25 PM, "Paul Kyzivat" <[email-masked]> wrote:

> implement it, and a fair amount of potential to implement it wrong.

It definitely spent a lot of its life being quite complicated. But I just
recently re-read the version actually in the queue, and it seems much
simpler and much more implementable than many of the drafts that preceded
it.

/a

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 23 Mar 2009 19:50:53 -0400

It seems that with a few adjustments we get to the point that the -bis-
is quite reasonable and straightforward regarding "subscribe dialog
re-use" issues.

Clearly, we have to moderate 4.5.1 to "Notifiers MUST implement GRUU and
SHOULD use a GRUU as their contact URI for all dialogs (including
non-subscription dialogs)."  The reason for the SHOULD is that it means
what we must say, "use a GRUU unless there is a very good reason that
you can't", by which we mean, "unless you can't get a GRUU" -- there
being no other reason that a notifier can't use a GRUU fairly easily.

4.5.1 already requires a subscriber to use a separate dialog if the
destination of the subscription is a GRUU.  Actually, that sentence
doesn't contain MUST, so it should be rephrased "If so, the subscriber
MUST create the subscription on a new dialog, using the GRUU as the
request URI for the new SUBSCRIBE."  (Leaving unspecified the
possibility that the subscriber could add Route headers to cope with
mandatory outbound proxies and other odd circumstances.)

In 4.5.2, it seems to me to be unwise to allow the notifier to respond
403 to subscriptions within existing dialogs, as that is a significant
constriction of the current requirements.  In the future, when -bis- has
been implemented and subscribers can reasonably depend on all notifiers
to implement it, then we can safely allow notifiers to be more
particular.  At least, we need to narrow the statement so that notifiers
can only reject shared-dialog SUBSCRIBEs with 403 if the notifier always
uses a GRUU as its contact URI.

In regard to the long list following "To implement dialog sharing", is
any of this material new?  As far as I can tell, it is a summary of
3265/5057.  If so, it should be explicitly labeled as such, and refer
the reader to those RFCs as the normative text.  If not, the
relationship of this list with those RFCs needs to be made explicit.

Dale

---

From: Adam Roach <[email-masked]>
Date: Mon, 23 Mar 2009 17:32:05 -0700

> being no other reason that a notifier can't use a GRUU fairly easily.

That seems a reasonable approach, with the caveat that I'd call out the 
circumstances surrounding the SHOULD explicitly. That is, I would phrase 
it like "...MUST use GRUU as their contact URI for all dialogs unless 
they cannot obtain a GRUU. Note that the only circumstances in which a 
notifier cannot obtain a GRUU is when they don't meet the criteria for 
creating self-made GRUUs and their registrar does not support GRUU."

> mandatory outbound proxies and other odd circumstances.)

I'm happy to rephrase this to be use RFC 2119 language.

> constriction of the current requirements.

In what way? Implementors are still allowed to accept such incoming 
connections, but one of the key changes I think is necessary in this 
revision is to free implementors from the morass of coding for dialog 
sharing -- because MOST PEOPLE GET IT WRONG. I see little value with 
maintaining backwards "compatibility" with a feature that, by and large, 
wasn't compatible between multiple implementations in the first place.

> relationship of this list with those RFCs needs to be made explicit.

The list you refer to is copied from various parts of the original text 
(i.e., 3265). The intention is for this document to obsolete 3265, so 
referring to 3265 for procedures would make no sense.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Mar 2009 21:10:15 -0400

> wasn't compatible between multiple implementations in the first place.

I'd be interested in hearing in what ways "most people" get it wrong.
Getting the common cases of dialog sharing right isn't so difficult.
I expect that "most people" get corner cases wrong in lots of things.

This only frees implementors if:
- they are capable of creating their own gruus without registration
- or they ONLY work with registrars that support GRUU.
- and they only interact with other UAs that support 3265bis.

Notably, any phone that *might* be attached to a registrar that doesn't 
support GRUU will need to support dialog sharing. And any UA that might 
establish a dialog with somebody that doesn't implement 3265bis should 
be prepared to have the other end initiate dialog sharing.

I guess the question is whether the bis should indicate what should be 
done to maintain backward compatibility with 3265, or if that should 
simply be left for implementors to figure out for themselves. I can see 
the merit in leaving the old cruft out so that it *eventually* goes away.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 23 Mar 2009 21:36:35 -0400

On Mon, 2009-03-23 at 17:32 -0700, Adam Roach wrote:
> self-made GRUUs

What is a "self-made GRUU"?

> wasn't compatible between multiple implementations in the first place.

That's a good point, although I fear that the real effect will be to
free implementors from *fixing their implementations* if something is
incorrect.

At the least, I think that you *must* limit the ability to send 403 to
devices that *are* using GRUUs as their contact.  I can *easily* see an
implementor implementing the "403" part of -bis- and deciding to omit
the "GRUU contact" part.

> referring to 3265 for procedures would make no sense.

So you're saying that this list is *complete*?

Dale

---

From: Adam Roach <[email-masked]>
Date: Mon, 23 Mar 2009 18:45:24 -0700

> What is a "self-made GRUU"?

See http://tools.ietf.org/html/draft-ietf-sip-gruu-15#section-4.3

> implementor implementing the "403" part of -bis- and deciding to omit

Sounds reasonable. Of course, you can send a 403 to any request at any time
according to local policy, but I see the potential need to warn people away
from sending it for this particular reason under these particular
circumstances.
 
> So you're saying that this list is *complete*?

What I'm claiming right now is that it is a complete list of every sentence
and clause in 3265 relating to the topic. A *complete* list would include
the stuff in 5057 -- but I'm hesitant to suck in 20+ pages of information
that is already specified elsewhere.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Mar 2009 09:35:30 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
> Roach
> Sent: Sunday, March 22, 2009 7:24 PM
> 
 
If the most common use-case for dialog-reuse of SUB/NOT is within INVITE dialogs, then what you're really saying is all INVITE-receiving or INVITE-creating UA's which also support receiving SUBSCRIBE must use GRUU's for the *INVITE* dialog to begin with.  That way the SUBSCRIBE can be sent to the same far-end UA, right?

Do you really think it's realistic to make such a requirement, to require changes in INVITE-dialogs, for an update to rfc3265 Sub/Not that ostensibly is to fix found issues and provide better interop?  

GRUU is not what one would call a wildly successful mechanism, yet, and we don't yet know what all of its deployment issues will be using it in INVITEs.  And the most popular implementation we've seen using gruu doesn't even use the right param name (it uses an older gruu draft's param name).

-hadriel

---

From: Bob Penfield <[email-masked]>
Date: Tue, 24 Mar 2009 12:45:40 -0400

>GRUU is not what one would call a wildly successful mechanism, yet, and we don't yet
>know what all of its deployment issues will be using it in INVITEs.  And the most
>popular implementation we've seen using gruu doesn't even use the right param name
>(it uses an older gruu draft's param name).

I think its way too early to make any judgment on the success of GRUU since it is not even an RFC yet. Many vendors have made the smart decision to not implement things in their core products until there is an RFC. When folks start implementing it, INVITE will likely be the first place they do. Mainly for call transfer use cases as well as subscriptions related to the INVITE usage.

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 24 Mar 2009 09:52:40 -0700

> If the most common use-case for dialog-reuse of SUB/NOT is within INVITE dialogs, then what you're really saying is all INVITE-receiving or INVITE-creating UA's which also support receiving SUBSCRI…

That's the important part, yes.

> Do you really think it's realistic to make such a requirement, to require changes in INVITE-dialogs, for an update to rfc3265 Sub/Not that ostensibly is to fix found issues and provide better inter…

Yep. We knew, when we put dialog sharing in, that it was a horrible 
hack. I can probably even dig up the fossil record where we explicitly 
agreed (prior to 3265's publication) to go forward with what we 
acknowledged it to be a horrible hack, and further agreed to try to come 
up with a better way to do this in the future. I concede that consensus 
reached eight years ago can be overturned if we have new technical 
information, but this really *has* been the plan all along.

In fact, getting GRUU in the editor's queue was one of the key triggers 
that led me to believe that we finally have the tools necessary to issue 
a bis, since dialog sharing was a known (and necessary) flaw at the time 
of publication.

> GRUU is not what one would call a wildly successful mechanism, yet

Of course it's not. It's not an RFC yet. After the whole multi-year TURN 
whipsaw experience, I'm stunned anyone bothers to implement anything 
before it has an RFC number assigned any more. But, suprisingly, they 
do: more than one in every eight implementations at SIPit 22 implemented 
GRUU.

And, while I'm flattered that you think that the publication and/or the 
implementation of 3265bis will somehow outrun a document that's 
effectively at the finish line already, I think you are being somewhat 
over-optimistic in your evaluation. By the time 3265bis is an RFC, 
implementations will be further along.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 24 Mar 2009 13:54:41 -0400

> From: Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, March 24, 2009 12:53 PM
> To: Hadriel Kaplan
>

My concern was more that it has nothing to do with implementations - it has to do with use.  I find many new drafts getting early implementation at Sipit's yet not finding them in actual use or even GA code.  Just because we publish an RFC does not mean a heck of a lot as to whether the market will use it.  :(

-hadriel

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 24 Mar 2009 19:53:52 -0400

> that is already specified elsewhere.

It wasn't clear to me that it included all the relevant parts of 3265,
but since this document is intended to obsolete 3265, its text can't
assert its own relationship to 3265.  Of course, you can refer to 5057,
because it won't be obsoleted.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 24 Mar 2009 19:57:01 -0400

> do: more than one in every eight implementations at SIPit 22 implemented 

I'm not so concerned about getting GRUU implemented.  It's known that
GRUU is necessary to get many call-control mechanisms to work, so
everyone assumes they'll have to implement it eventually.

Dale