Subject: [Sip] WGLC for draft-ietf-sip-outbound

From: Dean Willis <[email-masked]>
Date: Mon, 09 Jul 2007 14:41:19 -0500

I'd like to start a long working group last call for:

http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt

This WGLC period will run through IETF and hopefully close August 6, 2007.

Please read the draft and send any comments both to the list and direct
to the authors.

We'll also have a few minutes on the agenda in Chicago to discuss the
issues if any pop up.

--
Dean Willis
co-chair, SIP

_______________________________________________
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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 10 Jul 2007 11:13:51 +0200

A reminder:

When making comments, please clearly identify:

-	the section being commented upon, and therefore impacted by any resolution (extracted text is also useful)
-	the level of the comment (NIT, minor technical, major technical)
-	the comment itself
-	any suggested resolution

We will tabulate any reviews according to the above.

Regards

Keith

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 8:41 PM
> To: [email-masked]
> Cc: Cullen Jennings; DRAGE, Keith (Keith); [email-masked]
> Subject: WGLC for draft-ietf-sip-outbound
> 
> Please read the draft and send any comments both to the list 
> and direct to the authors.
> 
> We'll also have a few minutes on the agenda in Chicago to 
> discuss the issues if any pop up.
> 
> --
> Dean Willis
> co-chair, SIP
>

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 10 Jul 2007 17:20:13 +0800

Hi

Which is the appropriate 4xx message that can be used to inform user of
an existing subscription? 

Consider the following use case: User A sends a subscribe message with a
particular event and gets subscribed to the service. Now at a later
point of time the user is not sure if he has subscribed for a particular
service or not. So he might send subscribe again. So is there a way to
inform the user that the subscription for that service for the user
already exists?

Thanks 

Regards
Ranjit

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jul 2007 08:31:29 -0400

There is no error response for this, because it isn't an error. It is 
quite legal to establish multiple subscriptions for the same event. 
While in some cases this might be redundant and silly, it is difficult 
or impossible for the notifier to distinguish the useful cases from the 
silly ones.

	Paul

---

From: [email-masked]
Date: Thu, 12 Jul 2007 13:51:38 -0400

From: "Avasarala Ranjit-A20990" <[email-masked]>

As others have said, it's not an error, so there is no error response.

That isn't quite the way to look at it.  Given that NOTIFYs are always
sent within a dialog, if the UA has truly forgotten about any possible
subscription, it will have also forgotten the Call-Id of the dialog,
and will have no context to recognize that an incoming NOTIFY is
relevent to its subscription.  So the old subscription must perforce
be abandoned (and it will eventually time out), and the UA must create
a new subscription.

On the other hand, if the UA knows the Call-Id of a past subscription
but doesn't know if the subscription is still valid, it can send a
re-SUBSCRIBE, and the notifier will respond 200 (if it is still valid)
or 481 (if not).

Dale

---

From: Dean Willis <[email-masked]>
Date: Thu, 12 Jul 2007 13:13:38 -0500

> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-09.txt

My error. This should have referred to draft-ietf-sip-outbound-10, not
-09. It was busy working its way through the posting system and I
grabbed a pointer to the wrong one.

Sorry about that, folks.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Jul 2007 18:15:48 -0500

With the move to CRLF for keepalive in outbound, the language discussing 
STUN handling with SigComp in TCP is also gone. This makes sense, since 
TCP no longer uses STUN.

However, there was no equivalent language added for how to handle the 
CRLF keepalives in conjunction with SigComp.

As with the earlier STUN mechanism, you can't just send the CRLF stuff 
down the TCP connection -- it needs to be wrapped in SigComp. Of course, 
we could employ the same mechanism originally proposed for STUN (the 
well-known shim), which would be the 13-byte SigComp shim, plus 2 bytes 
(CRLF) or 4 bytes (double CRLF).

Alternately, we can shave this down a _little_ bit by using bytecodes 
specifically designed to output just the CRLFs we need; for a 
double-CRLF, it would look like:

    at (128)
    OUTPUT (crlf, 4)
    JUMP(end)

    :crlf byte(13,10,13,10)

    :end
    END-MESSAGE (0,0,0,0,0,0,0)

Which translates to the following 14 bytes: f8 00 b1 22 a0 86 04 16 06 
0d 0a 0d 0a 23

(Yes, I realize this is 14 bytes instead of the 17 bytes you get with 
the shim, so it might not be worth using custom code).

For a single CRLF, such code would end up looking like this:

    at (64)
    :crlf pad(2)

    at (128)
    LOAD (crlf, 3338)
    OUTPUT (crlf, 2)
    END-MESSAGE (0,0,0,0,0,0,0)

Which translates to the following 11 bytes: f8 00 81 0e 86 ad 0a 22 86 
02 23.

In practice, we're probably best off just normatively saying that the 
CRLF characters are sent inside SigComp, and that the mechanism for 
representing them is a matter to be handled by the SigComp compressor at 
the sending end. We can point out the shim, and we can include the 
foregoing purpose-built SigComp messages, but there may be architectural 
complications to using either of them, so the ultimate requirement is 
simply to send something that produces "CRLF" as its output when it is sent.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Jul 2007 19:05:04 -0500

At the risk of further bloodying the corpse of this poor horse, I still 
think the usage of feature tags in outbound is way, way off in terms of 
the semantics described in 3261.

Reviewing the way this is defined to work in SIP:

3261:8.1.1.9:
>    If the UAC supports extensions to SIP that can be applied by the
>    server to the response, the UAC SHOULD include a Supported header
>    field in the request listing the option tags (Section 19.2) for those
>    extensions.

3261:8.2.4:

>    A UAS that wishes to apply some extension when generating the
>    response MUST NOT do so unless support for that extension is
>    indicated in the Supported header field in the request.  If the
>    desired extension is not supported, the server SHOULD rely only on
>    baseline SIP and any other extensions supported by the client.
> ...
>    Any extensions applied to a non-421 response MUST be listed in a
>    Require header field included in the response.  Of course, the server
>    MUST NOT apply extensions not listed in the Supported header field in
>    the request.  As a result of this, the Require header field in a
>    response will only ever contain option tags defined in standards-
>    track RFCs.

There are five normative statements in the text I quote above. The 
mechanism described in the outbound draft actually manages to violate 
_all_ _five_ of them.

The registrar infers *both* support for outbound *and* a request to 
apply the outbound extension by the presence of the "reg-id" Contact 
header field parameter. In particular, the client is apparently NOT 
supposed to send a "Supported: outbound" header field. This appears to 
contravene the normative statement in 8.1.1.9 cited above.

The registrar indicates that outbound procedures are being applied by 
including a "Supported" header field in the REGISTER response. (In 3261, 
"Supported" in a _response_ indicates that an extension _can_ _be_ 
supported in a future request, NOT that it is being applied to the 
current one -- sections 11 and 13.3.1.4 both talk about Supported usage 
in responses.)

In other words, the registrar (acting as a UAS) is applying an extension 
when generating a response without that extension being indicated in the 
"Supported" header field in the request. Again, this directly 
contravenes two normative statements from section 8.2.4 (cited above).

The registrar is further applying an extension to a non-421 response 
that is not listed in a "Require" header field, in violation of the 
remaining normative statement in the portion of section 8.2.4 cited above.

Why are we doing this so very, very wrong? It's almost as if we've gone 
out of our way to violate both the spirit AND the law of feature tag 
handling in as many ways as possible. Most annoyingly, we get exactly 
the desired behavior if we just do things the way they're described in 
3261. To wit:

    * If a client supports outbound, it includes "Supported: outbound"
      in all REGISTER requests, regardless of whether the specific
      request makes use of that extension.

    * The client adds a "reg-id" header field parameter to any Contacts
      to which outbound processing is to apply.

    * The registrar includes "Require: outbound" in any REGISTER
      requests to which outbound behavior is being applied.

    * The registrar is free to include "Supported: outbound" in any
      responses it generates -- and it means exactly what 3261 intends
      it to mean: that outbound is *supported*, but is not being applied
      to the response in question.

/a

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 20 Jul 2007 02:15:10 +0200

Good points, some nits inline

Regards,
Jeroen

Adam Roach wrote:
> At the risk of further bloodying the corpse of this poor horse, I
> still think the usage of feature tags in outbound is way, way off in
> terms of the semantics described in 3261.
>
>>    field in the request listing the option tags (Section 19.2) for
>>    those extensions.
>
> 3261:8.2.4:
>
>>    Require header field included in the response.  Of course, the
>>    server MUST NOT apply extensions not listed in the Supported
>>    header field in the request.  As a result of this, the Require
>>    header field in a response will only ever contain option tags
>>    defined in standards- track RFCs.
>
> including a "Supported" header field in the REGISTER response. (In
> 3261, "Supported" in a _response_ indicates that an extension _can_
> _be_ supported in a future request, NOT that it is being applied to
> the current one -- sections 11 and 13.3.1.4 both talk about Supported
> usage in responses.)
>
> In other words, the registrar (acting as a UAS) is applying an
> extension when generating a response without that extension being
> indicated in the "Supported" header field in the request. Again, this
> directly contravenes two normative statements from section 8.2.4 (cited 
> above).
>
> Why are we doing this so very, very wrong? It's almost as if we've
> gone out of our way to violate both the spirit AND the law of feature
> tag handling in as many ways as possible. Most annoyingly, we get
> exactly the desired behavior if we just do things the way they're 
> described in
> 3261. To wit:
>

[jvb] this would probably be a MUST, right?

>      requests to which outbound behavior is being applied.

[jvb] you mean responses

>      it to mean: that outbound is *supported*, but is not being
>      applied to the response in question.

[jvb] is not _necessarily_ being applied, it depends on presence of Require: 
outbound (only). Guess this is a MAY, right?

---

From: [email-masked]
Date: Thu, 19 Jul 2007 20:35:50 -0400

From: Adam Roach <[email-masked]>
   Date: Thu, 19 Jul 2007 19:05:04 -0500
   Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	   mechanism)
   X-Scan-Signature: 00e94c813bef7832af255170dca19e36
   Cc: [email-masked], Cullen Jennings <[email-masked]>

   /a

---

From: [email-masked]
Date: Thu, 19 Jul 2007 20:40:17 -0400

You're completely right, of course.

   Why are we doing this so very, very wrong? It's almost as if we've gone 
   out of our way to violate both the spirit AND the law of feature tag 
   handling in as many ways as possible.

And outbound is not the only place this has happened.  It took a long
time to purge this sort of error from gruu as well.  IMHO, I think the
reason is that people intuitively want "Supported" to mean "this
message is invoking the feature in question" (which is ambiguous as to
whether it means that the message contains use of the feature, or that
the message requests the far end to apply the feature).  People seem
to have a hard time grasping that its purpose is to communicate a
property of the UA, namely that the UA supports the feature in
question.  But many people in the world of software don't grasp
talking about "properties that things possess", they can only talk
about "actions happening right now".

Dale

---

From: Adam Roach <[email-masked]>
Date: Fri, 20 Jul 2007 10:53:42 -0500

> Good points, some nits inline

Good nits. Some responses inline.

> [jvb] this would probably be a MUST, right?

Well, we're not strengthening 3261 -- so I believe it's a SHOULD in all 
requests, and a MUST in REGISTERs that make use of the extension.

>>      requests to which outbound behavior is being applied.

Right.

> [jvb] is not _necessarily_ being applied, it depends on presence of 
> Require: outbound (only). Guess this is a MAY, right?

I believe you are correct on both counts.

/a

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 20 Jul 2007 09:06:23 -0700

Hi Adam,

What can I say but "You're right".  Unless there is some fundamental  
objection, I will make this change pronto to my working copy.

I believe this also means I can remove the 'ob' parameter from the  
UAC's Contact header.
thanks,
-rohan

On Jul 19, 2007, at 5:05 PM, Adam Roach wrote:
> still think the usage of feature tags in outbound is way, way off  
> in terms of the semantics described in 3261.
>
>> those
>> server
> mechanism described in the outbound draft actually manages to  
> violate _all_ _five_ of them.
>
> apply the outbound extension by the presence of the "reg-id"  
> Contact header field parameter. In particular, the client is  
> apparently NOT supposed to send a "Supported: outbound" header  
> field. This appears to contravene the normative statement in  
> 8.1.1.9 cited above.
>
> The registrar indicates that outbound procedures are being applied  
> by including a "Supported" header field in the REGISTER response.  
> (In 3261, "Supported" in a _response_ indicates that an extension  
> _can_ _be_ supported in a future request, NOT that it is being  
> applied to the current one -- sections 11 and 13.3.1.4 both talk  
> about Supported usage in responses.)
>
> indicated in the "Supported" header field in the request. Again,  
> this directly contravenes two normative statements from section  
> 8.2.4 (cited above).
>
> The registrar is further applying an extension to a non-421  
> response that is not listed in a "Require" header field, in  
> violation of the remaining normative statement in the portion of  
> section 8.2.4 cited above.
>
> gone out of our way to violate both the spirit AND the law of  
> feature tag handling in as many ways as possible. Most annoyingly,  
> we get exactly the desired behavior if we just do things the way  
> they're described in 3261. To wit:
>

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 20 Jul 2007 09:26:44 -0700

On Jul 20, 2007, at 9:06 AM, Rohan Mahy wrote:

> Hi Adam,
>
> What can I say but "You're right".  Unless there is some  
> fundamental objection, I will make this change pronto to my working  
> copy.
>

On further thought, I realized that the 'ob' parameter is still  
needed, since it reflects whether the UAC is sending over a flow for  
which out bound processing is being applied, as opposed to merely  
indicating the UAC is capable of requesting outbound.

thanks,
-rohan

>> The registrar infers *both* support for outbound *and* a request  
>> to apply the outbound extension by the presence of the "reg-id"

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 20 Jul 2007 20:45:44 +0200

Rohan,

The flag is needed, but you could make it a header parameter rather than a 
URI parameter (both for Contact and for Path).

There is no need for it to appear in the request URI of mid-dialog requests. 
The EP can use its own convention to encode the flag, due to things like 
GRUU it cannot rely on the 'ob' parameter being in the request URI anyway.

Regards,
Jeroen

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 24 Jul 2007 06:23:26 +0200

A reminder of the ongoing WGLC on the above document

This WGLC period runs through IETF and hopefully close August 6, 2007.

That gives you about a week after the end of IETF - please schedule some time for doing this.

Regards

Keith

> Sent: Thursday, July 12, 2007 7:14 PM
> To: Dean Willis
> Cc: [email-masked]; Cullen Jennings; DRAGE, Keith (Keith)
> Subject: Correction: WGLC for draft-ietf-sip-outbound
> 
> Dean Willis wrote:
> My error. This should have referred to 
> draft-ietf-sip-outbound-10, not -09. It was busy working its 
> way through the posting system and I grabbed a pointer to the 
> wrong one.
> 
> Sorry about that, folks.
> 
> --
> Dean
> 
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Jul 2007 08:16:37 -0500

Keith/Rohan -

There's a moderate list of changes we already know are going to be  
made to the document.

Everyone who wasn't in Chicago's Monday SIP meeting should look at
http://www3.ietf.org/proceedings/07jul/slides/sip-3.pdf for the  
bigger ones.
Rohan has indicated a few smaller ones on list.

Would it be possible to get a list of the known expected changes in  
one place?

RjS

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 25 Jul 2007 09:07:50 +0200

Just to indicate that what I don't think we want during the middle of
the WGLC is a -11 version. I think we need all comments made during this
last call to be made against -10.

What I would like is a compilation of all the comments made like we did
for GRUU - they are still up on softarmor. I would consider that we
could start plugging the proposed resolution into such a document.

I don't know what Dean's availability is in this respect, but I haven't
got time to devote to this until late next week. 

Regards

Keith

> From: Robert Sparks [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 2:17 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; Cullen Jennings; Rohan Mahy
> Subject: Re: [Sip] RE: Correction: WGLC for draft-ietf-sip-outbound
> 
> Keith/Rohan -
> 
> There's a moderate list of changes we already know are going 
> to be made to the document.
> 
> http://www3.ietf.org/proceedings/07jul/slides/sip-3.pdf for 
> the bigger ones.
> Would it be possible to get a list of the known expected 
> changes in one place?
> 
> RjS
> 
> >> My error. This should have referred to draft-ietf-sip-outbound-10, 
> >> not -09. It was busy working its way through the posting 
> system and I 
> > 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: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Wed, 25 Jul 2007 09:07:50 +0200

Regards

Keith