Subject: [Sip] bis-08 is born

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Feb 2002 12:29:31 -0500

Folks,

I'm pleased to announce that I've just submitted bis-08 to the archives.
Until it appears, you can pick up a copy in the usual places:

http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-08.txt
http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-08.ps
http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-08.pdf

or:

http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-08.txt
http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-08.ps
http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-08.pdf

Changebars represent diffs from -07, NOT -07.9. 

This completes the first "bundle" of drafts which are now off to IESG
last call for consideration as proposed:

draft-ietf-sip-rfc2543bis
draft-ietf-sip-100rel
draft-ietf-sip-srv
draft-ietf-mmusic-sdp-offer-answer
draft-ietf-sip-events

These drafts are right on time based on the scheduling worked out to
meet 3gpp timelines.

There will almost certainly be a bis-09 which incorporates further iesg
and reviewer comment; however, it is our expectation that the changes
from -08 to -09 will be small, primarily nits/grammar and improved
wordings on some of the newer stuff, like sips. 

I would like to once again thank the bis editors team for the tremendous
amount of effort that went into this document. The editors have been
working weekends and into the wee hours of the night to make sure we
meet our deadlines. Last night was the biggest stretch of all, with
several of us, including myself, pulling all nighters (I have not slept
in about 30 hours). To make things more interesting, the Columbia
fileserver where our text converter lives crashed in the middle of the
final build of bis-08 this morning! Very scary.

I'd like to thank the working group as a whole for the tremendous
efforts that went into reviewing the document. The hundreds of comments
we received from many of you are a big part of bringing the spec to the
level of quality it is at today.

I'd also like to thank Jean Mahoney, a technical writer from dynamicsoft
who has volunteered her time to improve the quality of the text. Many
(if not most) of the reviewer comments that were grammatical and
stylistic in nature were handled by her.

However, there is no time to rest on our laurels. We have the next
bundle of deliverables coming up for 3gpp - update, manyfolks, privacy,
call-auth and (possibly) path. I would encourage the group to provide
the same focus on those drafts that was given to the drafts in the first
bundle.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.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: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Feb 2002 20:30:56 -0500

Jon,

Still behind in my reading - this is a question about a change that must
have first appeared in bis-06 or -07. But I will refer to -08 here:

In lines 1709-1710 (section 10.3 item 6) is a rule that a REGISTER
containing Contact:* must not contain any other contact lines. Why has
this restriction been added? I don't see any great benefit to imposing
this restriction, and it could be inconvenient. 

If there might be a prior registration, and the intent is for a new
registration to supercede that, life becomes difficult. Either this
requires two REGISTERs, one with Contact:* and then another with the
desired new values, or else the exact set of prior contact headers must
be known, and the new REGISTER must repeat all the old contact
addresses, with expires=0. 

Why not simply state that if a Contact:* is present it must be processed
before the other Contact entries?

-

I also have another register related issue that should have been raised
sooner. It is presumably too late to deal with now, but I raise it in
hopes that there will be an opportunity to consider it at some future
time:

In lines 1733-1739 (section 10.3 item 7) the rules are specified for
matching and replacement of individual bindings. As worded, I believe
this would result in aborting any REGISTER that contains multiple
Contact entries with the same address. Back in bis-05 and before the
handling of this case was ambiguous. It is still slightly ambiguous
because it isn't entirely clear if items that have been tentatively
added are to be searched.

Of course it is silly to have two Contact entries with the same address
if there is nothing else to be different about them. But the built in
extension mechanisms permit the construction of different contact
headers with the same address but different parameters, and the
callerprefs draft does so. With that draft is is indeed useful to be
able to do so.

A minor change to the wording in this section would permit multiple
contact entries with the same address to be delivered in a single
REGISTER:

"For each address, the registrar then searches the list of current
bindings using the URI comparison rules, excluding those tentatively
added while processing this request. If no matching binding exists, one
is tentatively added. If one or more matching bindings do exist, the
registrar checks the Call-ID value of each. If the Call-ID value in a
matching binding differs from the Call-ID value in the request, the
binding MUST be removed if the expiration time is zero and updated
otherwise. If they are the same, the registrar compares the CSeq value.
If the value is higher than that of the existing binding, it MUST update
or remove the binding as above. If not, the update MUST be aborted and
the request fails."

(There may be clearer wordings, but this is a minimal change.)

In the earlier discussion Jon and others suggested hacks to work around
this, such as using addresses distinguished by a URL parameter. But
those are hacks, while this is not.

	Sorry to stir the pot now,
	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Feb 2002 04:10:08 -0500

> this restriction, and it could be inconvenient.

I had always assumed that if there was a *, it was only *; the change
was to merely clarify what I (at least) thought was always the case. 

> addresses, with expires=0.

Right. From a particular UA, that will generally be both feasible and
the right thing to do. It only ceases to work when you want to cancel a
contact from another UA, different from the one which created the
contact. This is not likely to be a common case. A UA would not normally
delete ALL registrations unless the user explicitly instructed it to.
Otherwise, you would never be able to have multiple devices associated
with a single AOR. For example, if I log in at work, and then go home,
my home PC is not going to normally unregister every other contact. It
will merely register and manage its own. Its only if I say "oops! forgot
to log out of work, let me delete that registration" that I might select
a specific option to delete all registrations. That deletion is quite
separate from the registration on that phone itself. So, I have no
problem with sending two REGISTER in this case.

> before the other Contact entries?

Another reason - the text says you can only use Contact:* when Expires:0
is there, which further validates my claim that this has always meant to
be used alone.

> added are to be searched.

Yes, it is ambigous. I had not considered this case. 

> callerprefs draft does so. With that draft is is indeed useful to be

I don't think it would help if the tentative ones are included, since
subsequent ones would overwrite. If you exclude tentative ones, then you
need to define what it means to tentatively add the same binding twice.
Also, the result would be that putting two identical contacts, but with
different contact params, in the same register, would be different than
if you put the same two in different registers. That seems wrong.

Also, how would replacement work? That is, if I register two contacts
that are identical URI:

COntact: sip:A;param1=val1
Contact: sip:A;param2=val2

What would it mean to later receive a REGISTER like:

Contact: sip:A;param3=val3

does this replace one of the two previous, or both? I think that it is
easier to have the contacts be different through differing URI
parameters or user parts. That gives you the flexibility to effectively
register multiple "equivalent" URI to the same binding, but requires no
changes to the spec. Furthermore, it allows the UA to know which of its
contacts was chosen, which is probably useful.

> or remove the binding as above. If not, the update MUST be aborted and

That text would not be sufficient; see above. A lot more would need to
be specified. Since there is an alternative that requires no changes but
allows you to meet your requirements, I would prefer that route.

> those are hacks, while this is not.

I don't think its a hack at all. You need to think of the user part, or
that URI parameter as a "cookie" which allows you to register a set of
contacts, and then know which one was selected based on the cookie
present in the incoming r-uri. With the new loose route stuff, the
record-route header has gone in this direction exactly.

Thanks,
Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Feb 2002 10:06:37 -0500

Jonathan - see below.

	Paul

> is there, which further validates my claim that this has always meant to

To deal with the last first - this language always seemed odd/unreasonable to me. What seems important is that the Contact:* must not have a non-zero effective expiration
time, because the behavior before it expired would be undefined. The Expires: header in general provides a default value for the expires= parameter in the Contact header,
and can be overridden. That language about Contact:* fails to exclude the semantically invalid case of:

	REGISTER ...
	...
	Expires: 0
	Contact:*;expires=3600

And yet it does exclude the semantically valid case:

	REGISTER ...
	...
	Expires: 3600
	Contact:*;expires=0

Even so, what I was suggesting was legal syntax before:

	REGISTER ...
	...
	Expires: 0
	Contact: *
	Contact: <sip:[email-masked]>;expires=3600

Regarding the other comments above:

I agree that a UA requesting to remove all prior registrations must know what it is doing. But when it does know this, like when it wants to be the exclusive target, then
combining a global deletion with a new registration would be useful. 

If it is important to prevent unknowing deletions, then the Contact:* construction should be removed entirely. (A UA intent on doing so at any cost could always request the
old contacts and then construct a new registration that sent expired forms of each back.) But I think the Contact:* form is indeed appropriate, and shouldn't have special
restrictions on its applicability.

> need to define what it means to tentatively add the same binding twice.

It isn't the same binding if it has different params.
 
It would be stupid to put one in twice that had identical params, but even then the treatment seems clear - just go ahead and add it. The rules for handling contacts later
should deal with it just fine. 

> if you put the same two in different registers. That seems wrong.

The reason I responded about that now is that your new language about processing Contacts in REGISTER gives a well defined way to deal with this. It isn't so terribly wrong
- a given contact *address* must be defined in a single REGISTER message, whether it takes one Contact header or several to describe it.

> does this replace one of the two previous, or both?

Both. The wording changes I suggested clarify this.

> I think that it is

Consider the following:

1)	REGISTER ...
	...
	Contact: sip:A;class=business
	Contact: sip:A;class=personal;priority=urgent

I might set my work phone to register this way during meetings.
When not in a meeting, I might want it to simply register as:

2)	REGISTER ...
	...
	Contact: sip:A

But if I must make the contact addresses unique, then the best I can do is probably:

1a)	REGISTER ...
	...
	Contact: <sip:A;slot=1>;class=business
	Contact: <sip:A;slot=2>;class=personal;priority=urgent

2a)	REGISTER ...
	...
	Contact: <sip:A;slot=1>
	Contact: <sip:A;slot=2>;expires=0

and I must remember how many "slots" I used last time.

The Contact:* discussion has some relevance here as well.
If Contact:* can be combined with other contacts, then the above
could be done as:

1b)	REGISTER ...
	...
	Contact: *;expires=0
	Contact: <sip:A;slot=1>;class=business
	Contact: <sip:A;slot=2>;class=personal;priority=urgent

2b)	REGISTER ...
	...
	Contact: *;expires=0
	Contact: sip:A

(Of course I could only do this if I knew there were no other UAs registering my address of record.)

> allows you to meet your requirements, I would prefer that route.

I don't think much (if anything) more needs specification, though more
text might help clarify subtleties.

	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 27 Feb 2002 10:40:10 -0500

On Wednesday, February 27 2002, "Paul Kyzivat" wrote to "Jonathan Rosenberg, [email-masked]" saying:

> That language about Contact:* fails to exclude the semantically invalid
> case of: 
> 
> 	REGISTER ...
> 	...
> 	Expires: 0
> 	Contact:*;expires=3600

This is forbidden by the Contact BNF.  If you read it closely, you'll see
that "Contact: *" can't have any parameters at all.

I don't know if this is necessarily a good idea, but it's what the spec
says, and it resolves the issue.

-- 
Jonathan Lennox
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Feb 2002 13:05:57 -0500

> that "Contact: *" can't have any parameters at all.

Yeah, you are right. I should have checked before writing.

Even so, the following was (I think) technically legal before,
though exactly what it meant might not have been clear:

        REGISTER ...
        ...
        Expires: 0
        Contact: *

> says, and it resolves the issue.

*If* we were to permit Contact:* to be mixed with other Contact headers,
then I think it would be better to permit the expires= parameter on it,
and simply require that the effective expiration time be zero.

	Paul