Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

From: Adam Roach <[email-masked]>
Date: Fri, 06 Nov 2009 09:42:59 +0900

On 8/6/09 7:28 PM, [email-masked] wrote:
> Hi Christer and Francois,
> I have added a sentence under section Overall Applicability:
>
>
> The appearance of the Reason header is applicable to final responses 4xx, 5xx and 6xx and in addition for 199 Responses.
>
> Is this proper enough? Or do you have more in mind?
>    

Given that RFC 3398 specifies the generation of a 301 in response to a 
cause code of 22 under certain circumstances, it seems pretty 
appropriate to allow the inclusion of a Q.850 cause code in 300-class 
responses also. Or, at least, as appropriate as it would be to include 
them in 4xx, 5xx, and 6xx responses.

/a

---

From: <[email-masked]>
Date: Sun, 8 Nov 2009 09:16:59 +0100

Hi Adam,
Thank you for your mail. So I propose the following text then:

The appearance of the Reason header is applicable to final responses
      3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within
      ietf-sipcore-199.txt. Also the Reason header is
      applicable to provisional responses18x which are generated by an
      interworking gateway from ISUP to SIP.</t>

Best Beagards

Roland 

-----Ursprüngliche Nachricht-----
Von: Adam Roach [mailto:[email-masked]] 
Gesendet: Freitag, 6. November 2009 01:43
An: Jesske, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 08 Nov 2009 22:58:03 -0500

>       interworking gateway from ISUP to SIP.</t>

I think this is ok *except* if you are going to allow one kind of UAS to 
use Reason in a 18x response, then it should be allowed for *any* UAS to 
do so.

For instance, suppose the gateway is replaced by a B2BUA to another sip 
environment, and the request eventually arrives as a gateway. Then a 18x 
response with a Reason header may arrive at the B2BUA and need to be 
replicated on the other side.

	Thanks,
	Paul

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 00:57:43 +0100

Hello Paul,
Thanks for that hint. I will change this too. 
Like:

 The appearance of the Reason header is applicable to final responses
       3xx, 4xx, 5xx and 6xx and in addition for 199 Responses as defined within
       ietf-sipcore-199.txt. Also the Reason header is
       applicable to provisional responses18x.

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: Paul Kyzivat [mailto:[email-masked]] 
Gesendet: Montag, 9. November 2009 12:58
An: Jesske, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Nov 2009 19:06:11 -0500

Roland,

Thanks! That addresses my concern.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 10 Nov 2009 01:11:56 +0100

Hi,

A small editorial change proposal:

"The appearance of the Reason header is applicable to 3xx, 4xx, 5xx and 6xx final responses
and 18x and 199 <reference> provisional responsess."

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 10. marraskuuta 2009 3:06
To: [email-masked]
Cc: [email-masked]; [email-masked]; Gonzalo Camarillo
Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Roland,

	Thanks,
	Paul

[email-masked] wrote:
> I think this is ok *except* if you are going to allow one kind of UAS 
> to use Reason in a 18x response, then it should be allowed for *any* 
> UAS to do so.
> 
> For instance, suppose the gateway is replaced by a B2BUA to another 
> sip environment, and the request eventually arrives as a gateway. Then 
> a 18x response with a Reason header may arrive at the B2BUA and need 
> to be replicated on the other side.
> 
> 	Thanks,
> 	Paul
> 
>> Best Beagards
>>
>> Roland
>>
>> Cc: [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]
>> Given that RFC 3398 specifies the generation of a 301 in response to 
>> a cause code of 22 under certain circumstances, it seems pretty 
>> responses also. Or, at least, as appropriate as it would be to 
>> include them in 4xx, 5xx, and 6xx responses.
>>
>> /a

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Nov 2009 11:04:00 +0900

To clarify the point I was trying to make in the meeting today -- if 
we've decided to go down this path, I'll save you the trouble of 
creating the new ABNF for the new INVITE header fields. Here's what they 
look like:

Nature-Of-Connection-Indicators          = "Nature-Of-Connection-Indicators"
                                            HCOLON quoted-string

Forward-Call-Indicators                  = "Forward-Call-Indicators"
                                            HCOLON quoted-string

Calling-Party's-Category                 = "Calling-Party's-Category"
                                            HCOLON quoted-string

Transmission-Medium-Requirement          = "Transmission-Medium-Requirement"
                                            HCOLON quoted-string

Called-Party-Number                      = "Called-Party-Number"
                                            HCOLON quoted-string

Transit-Network-Selection                = "Transit-Network-Selection"
                                            HCOLON quoted-string

Call-Reference                           = "Call-Reference"
                                            HCOLON quoted-string

Calling-Party-Number                     = "Calling-Party-Number"
                                            HCOLON quoted-string

Optional-Forward-Call-Indicators         = 
"Optional-Forward-Call-Indicators"
                                            HCOLON quoted-string

Redirecting-Number                       = "Redirecting-Number"
                                            HCOLON quoted-string

Redirection-Information                  = "Redirection-Information"
                                            HCOLON quoted-string

Closed-User-Group-Interlock-Code         = 
"Closed-User-Group-Interlock-Code"
                                            HCOLON quoted-string

Connection-Request                       = "Connection-Request"
                                            HCOLON quoted-string

Original-Called-Number                   = "Original-Called-Number"
                                            HCOLON quoted-string

User-to-user-Information                 = "User-to-user-Information"
                                            HCOLON quoted-string

Access-Transport                         = "Access-Transport"
                                            HCOLON quoted-string

User-Service-Information                 = "User-Service-Information"
                                            HCOLON quoted-string

User-to-user-Indicators                  = "User-to-user-Indicators"
                                            HCOLON quoted-string

Generic-Number                           = "Generic-Number"
                                            HCOLON quoted-string

Propagation-Delay-Counter                = "Propagation-Delay-Counter"
                                            HCOLON quoted-string

User-Service-Information-Prime           = "User-Service-Information-Prime"
                                            HCOLON quoted-string

Network-Specific-Facility                = "Network-Specific-Facility"
                                            HCOLON quoted-string

Generic-Digits                           = "Generic-Digits"
                                            HCOLON quoted-string

Origination-ISC-Point-Code               = "Origination-ISC-Point-Code"
                                            HCOLON quoted-string

User-Teleservice-Information             = "User-Teleservice-Information"
                                            HCOLON quoted-string

Remote-Operations                        = "Remote-Operations"
                                            HCOLON quoted-string

Parameter-Compatibility-Information      = 
"Parameter-Compatibility-Information"
                                            HCOLON quoted-string

Generic-Notification-Indicator           = "Generic-Notification-Indicator"
                                            HCOLON quoted-string

Service-Activation                       = "Service-Activation"
                                            HCOLON quoted-string

Generic-Reference                        = "Generic-Reference"
                                            HCOLON quoted-string

MLPP-Precedence                          = "MLPP-Precedence"
                                            HCOLON quoted-string

Transmission-Medium-Requirement-Prime    = 
"Transmission-Medium-Requirement-Prime"
                                            HCOLON quoted-string

Location-Number                          = "Location-Number"
                                            HCOLON quoted-string

Forward-GVNS                             = "Forward-GVNS"
                                            HCOLON quoted-string

CCSS                                     = "CCSS"
                                            HCOLON quoted-string

Network-Management-Controls              = "Network-Management-Controls"
                                            HCOLON quoted-string

Circuit-Assignment-Map                   = "Circuit-Assignment-Map"
                                            HCOLON quoted-string

Correlation-Id                           = "Correlation-Id"
                                            HCOLON quoted-string

Call-Diversion-Treatment-Indicators      = 
"Call-Diversion-Treatment-Indicators"
                                            HCOLON quoted-string

Called-IN-Number                         = "Called-IN-Number"
                                            HCOLON quoted-string

Call-Offering-Treatment-Indicators       = 
"Call-Offering-Treatment-Indicators"
                                            HCOLON quoted-string

Conference-Treatment-Indicators          = "Conference-Treatment-Indicators"
                                            HCOLON quoted-string

SCF-Id                                   = "SCF-Id"
                                            HCOLON quoted-string

UID-Capability-Indicators                = "UID-Capability-Indicators"
                                            HCOLON quoted-string

Echo-Control-Information                 = "Echo-Control-Information"
                                            HCOLON quoted-string

Hop-Counter                              = "Hop-Counter"
                                            HCOLON quoted-string

Collect-Call-Request                     = "Collect-Call-Request"
                                            HCOLON quoted-string

Application-Transport-Parameter          = "Application-Transport-Parameter"
                                            HCOLON quoted-string

Pivot-Capability                         = "Pivot-Capability"
                                            HCOLON quoted-string

Called-Directory-Number                  = "Called-Directory-Number"
                                            HCOLON quoted-string

Original-Called-IN-Number                = "Original-Called-IN-Number"
                                            HCOLON quoted-string

Calling-Geodetic-Location                = "Calling-Geodetic-Location"
                                            HCOLON quoted-string

Network-Routing-Number                   = "Network-Routing-Number"
                                            HCOLON quoted-string

QoR-Capability                           = "QoR-Capability"
                                            HCOLON quoted-string

Pivot-Counter                            = "Pivot-Counter"
                                            HCOLON quoted-string

Pivot-Routing-Forward-Information        = 
"Pivot-Routing-Forward-Information"
                                            HCOLON quoted-string

Redirect-Capability                      = "Redirect-Capability"
                                            HCOLON quoted-string

Redirect-Counter                         = "Redirect-Counter"
                                            HCOLON quoted-string

Redirect-Status                          = "Redirect-Status"
                                            HCOLON quoted-string

Redirect-Forward-Information             = "Redirect-Forward-Information"
                                            HCOLON quoted-string

Number-Portability-Forward-Information   =
                                        
"Number-Portability-Forward-Information"
                                            HCOLON quoted-string

Perhaps we can refine some the the quoted strings with tokens, but I 
think this is a good start.

/a

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 06:01:41 +0100

These are my issues with SIP-T:

1) ISUP messages end up at end users. This violates regulatory requirements in countries where ISUP must only be sent to licensed carriers. For example, called parties will see the calling party numbers, even if the calling party required privacy. Apart from the MIME issues, this prevents us from using encapsulation. 

2) Encrypting SIP-T message bodies would solve 1), but looking at SIPit results, S/MIME for SIP is a dead technology.

3) Will application servers acting as B2BUAs deal properly with SIP-T multipart MIME bodies? People seem to be worried that they are not even able to forward a Reason header..

4) Many client don't implement Multipart MIME, as it can get quite complex (what to do with multiple SDP bodies, alternative SDP bodies etc). I'd have to ask my vendors to add complexity to the software without real benefit ("You'll have to implement multipart MIME, so we can send binary blobs to you the device has to throw away"). In the year 2009 some SIP clients don't even get simple SDP offer/answer right, how could we expect them to handle Multipart MIME in a sensible manner? 

5) User agents might have to switch TCP, just to receive oversized SIP messages with SIP-T bodies that will by thrown away. 

Wolfgang

Deutsche Telekom Netzproduktion GmbH 
Zentrum Technik Einführung 
Wolfgang Beck 
TE 122-14 
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt 
+49 6151 6282832 (Tel.) 
E-Mail: [email-masked] 
http://www.telekom.com 

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH 
Aufsichtsrat: Timotheus Höttges (Vorsitzender) 
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren 
Handelsregister: Amtsgericht Bonn HRB 14190 
Sitz der Gesellschaft: Bonn 
USt-IdNr.: DE 814645262

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Adam Roach
Gesendet: Dienstag, 10. November 2009 03:04
An: Christer Holmberg
Cc: [email-masked]; [email-masked]; Jesske, Roland; Gonzalo Camarillo
Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

CCSS                                     = "CCSS"
                                            HCOLON quoted-string

SCF-Id                                   = "SCF-Id"
                                            HCOLON quoted-string

                                        

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Nov 2009 14:41:53 +0900

> 2) Encrypting SIP-T message bodies would solve 1), but looking at SIPit results, S/MIME for SIP is a dead technology.

S/MIME for a general purpose network suffers from the classical key 
distribution problem. It's not used for the same reason encrypted email 
is not used (except among the geek community).

But you're not talking about general purpose networks.

You're talking about tightly constrained networks with PSTN gateways 
that are either all within a single administrative domain, or that 
communicate with each other through bilateral agreements. In these 
circumstances, key distribution is no more difficult a problem than IP 
address assignment. It's a simple matter of configuration.

> 3) Will application servers acting as B2BUAs deal properly with SIP-T multipart MIME bodies? People seem to be worried that they are not even able to forward a Reason header..

B2BUAs will break whatever they break. Until someone sits down and 
documents their behavior, we can't really do too much to work around 
their behavior. It's the same problem we're having all over the place 
(identity, MSRP ACM, etc). There's no point in talking about something 
as nebulous as B2BUA behavior.

> 4) Many client don't implement Multipart MIME, as it can get quite complex (what to do with multiple SDP bodies, alternative SDP bodies etc). I'd have to ask my vendors to add complexity to the sof…

While many UAs won't be able to ignore the multitype body (aside: this 
is sad -- email clients all can), you'd be hard pressed to find one that 
can't understand multipart that also won't respond to a multipart body 
in a request with a 415. This ends up looking just like SIP 
authentication, since the UAC will detect the failure to support 
multipart and re-attempt with a single body:

  UAC           UAS
   |---INVITE--->|
   |<----415-----|
   |---INVITE--->|
   |<----180-----|
         ...
   |<----200-----|
   |-----ACK---->|

> 5) User agents might have to switch TCP, just to receive oversized SIP messages with SIP-T bodies that will by thrown away.

At one point, you said "IMS." I don't think you'll find an IMS client 
that has any hope of receiving a UDP SIP message -- show me an INVITE on 
the terminating side of an IMS network that is somehow smaller than 1500 
bytes, and I'll be shocked into silence. TCP is a foregone conclusion.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 10 Nov 2009 14:51:02 +0900

It was pointed out to me that this email was somewhat nonsensical to 
people who were not in attendance at the face-to-face meeting.

My point is that increasing the amount of ISUP information that we 
include in SIP message headers is going down a slippery slope, the 
ultimate conclusion of which is including SIP header fields for every 
ISUP parameter.

We have a means for sending ISUP fields transparently through a SIP 
network (RFC 3398). I think it's folly to revisit that set of decisions 
simply because someone wants a less-general point solution.

/a

On 11/10/09 11:04 AM, Adam Roach wrote:
> creating the new ABNF for the new INVITE header fields. Here's what 
> they look like:
>

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 09:38:46 +0100

> ultimate conclusion of which is including SIP header fields for every 
This is a valid point, but the proposed alternative has severe problems.
If the reason header is the only piece of ISUP information we need,
carrying the whole ISUP message is not really elegant. SIP application
servers (AS) would have to implement ISUP parsing just to check a simple
value. The content of a Reason header could be checked and used by any
plain AS. Do we really want to perpetuate ISUP code in SIP networks?

> simply because someone wants a less-general point solution.
We were talking about scenarios where the PSTN gateway does not know
whether a call will be terminated by a different PSTN gateway, or by a
SIP user agent. So the originating gateway would have to encapsulate
ISUP in SIP, and SIP user agents would receive it. This would violate
regulatory requirements in various countries. As S/MIME is not feasible,
we would have to introduce yet another B2BUA just to filter ISUP from
SIP messages for end user devices.

Wolfgang

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 10 Nov 2009 09:50:12 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 10 November 2009 08:39
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
[JRE] SIP UAs would receive the Reason header field too, unless the last proxy/B2BUA strips it out. The only difference is that a body part can only be stripped by a B2BUA, not by a proxy. Do you need a solution that will work with proxies?

John

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 09:54:12 +0100

My intension  is to avoid your shown ABNF for new INVITE header fields.
Instead we want to use the ABNF defined within RFC3326 as follows:

 Reason            =  "Reason" HCOLON reason-value *(COMMA reason-value)
 reason-value      =  protocol *(SEMI reason-params)
 protocol          =  "SIP" / "Q.850" / token
 reason-params     =  protocol-cause / reason-text
                      / reason-extension
 protocol-cause    =  "cause" EQUAL cause
 cause             =  1*DIGIT
 reason-text       =  "text" EQUAL quoted-string
 reason-extension  =  generic-param

The only one missing is to allow this header within Responses.

-----Ursprüngliche Nachricht-----
Von: Adam Roach [mailto:[email-masked]] 
Gesendet: Dienstag, 10. November 2009 03:04
An: Christer Holmberg
Cc: Paul Kyzivat; Jesske, Roland; [email-masked]; [email-masked]; Gonzalo Camarillo
Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

CCSS                                     = "CCSS"
                                            HCOLON quoted-string

SCF-Id                                   = "SCF-Id"
                                            HCOLON quoted-string

                                        

/a

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 10 Nov 2009 13:14:26 +0100

I am bit surprised that the principle of the reason haeder in general and reason headers in requests are discussed. I thought this has been agreeed in RFC 3326.
In my understnding the intention of the draft is to allow reason headers in responses.

Thomas B

---------------------------------- 
Dr. Thomas Belling 
3GPP Standardisation
Nokia Siemens Networks 

-----Ursprüngliche Nachricht-----
Von: Adam Roach [mailto:[email-masked]]
Gesendet: Dienstag, 10. November 2009 03:04
An: Christer Holmberg
Cc: Paul Kyzivat; Jesske, Roland; [email-masked]; [email-masked]; Gonzalo Camarillo
Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

To clarify the point I was trying to make in the meeting today -- if we've decided to go down this path, I'll save you the trouble of creating the new ABNF for the new INVITE header fields. Here's what they look like:

CCSS                                     = "CCSS"
                                            HCOLON quoted-string

SCF-Id                                   = "SCF-Id"
                                            HCOLON quoted-string

                                        

Perhaps we can refine some the the quoted strings with tokens, but I think this is a good start.

/a

---

From: <[email-masked]>
Date: Wed, 11 Nov 2009 02:05:15 +0100

> address assignment. It's a simple matter of configuration.
In theory, S/MIME should be doable in an administrative domain. It's the
lack of implementations that troubles me. 

> as nebulous as B2BUA behavior.
Sure. I was referring to an argument made (not by Adam) in the meeting. 

> in a request with a 415.
Right, but connection setup times are already a concern now, without the
extra transaction to reject multipart content.

> bytes, and I'll be shocked into silence. TCP is a foregone conclusion.
The universal deployment of IMS may take some time. Until that glorious
day, we may have networks that would profit from the Reason header and
don't have big SIP messages. 

Wolfgang

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 11 Nov 2009 08:50:36 +0100

Dear Roland,

we discussed the interworking of ISUP ACM and CPG causes to SIP reasons headers in provisional responses in 3GPP CT3 yesterday.
The conclusion was that we will only insert a reason header in a 183 provisional response.

May I therefor suggest the following wording:

        The Reason header is applicable to 3xx, 4xx, 5xx and 6xx final responses
        and 183 and 199 <reference> provisional responses.

Further, it would be very helpfull for 3GPP if you could make the updated draft available very quickly as we have several dependent CRs in the 3GPP CTx meeting which is ongoing this week.

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Christer Holmberg
Sent: Tuesday, November 10, 2009 8:12 AM
To: Paul Kyzivat; [email-masked]
Cc: [email-masked]; [email-masked]; Gonzalo Camarillo
Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Hi,

"The appearance of the Reason header is applicable to 3xx, 4xx, 5xx and 6xx final responses and 18x and 199 <reference> provisional responsess."

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 10. marraskuuta 2009 3:06
To: [email-masked]
Cc: [email-masked]; [email-masked]; Gonzalo Camarillo
Subject: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

Roland,

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Nov 2009 08:57:51 -0500

I hate to see *anything* restricted to 183, rather than being applicable 
to all 1xx (or at least 18x) responses.

Restricting to 183 implies that there is something *special* about 183.
I have seen that erroneous assumption in the wild too - and it is 
distressing. Anything you can do with 183 should also work with 180.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Wed, 11 Nov 2009 15:25:33 +0100

Hello Paul,
Thank you for your comment. I have the sam opinion. Due to the fact that 1xx is not done end to end  I have put the following sentence into the draft.

The appearance of the Reason header is applicable to final responses
   3xx, 4xx, 5xx and 6xx and 18x and 199 provisional responses
   [I-D.ietf-sipcore-199].

I hope that fits. 

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Paul Kyzivat
Gesendet: Mittwoch, 11. November 2009 22:58
An: Belling, Thomas (NSN - DE/Munich)
Cc: Paul While; [email-masked]; Jesske, Roland; ext Calme,James A (Jim)
Betreff: Re: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Nov 2009 09:59:28 -0500

[email-masked] wrote:
> Hello Paul,
> Thank you for your comment. I have the sam opinion. Due to the fact that 1xx is not done end to end

1xx means 101-199, excluding 100. Only 100 is hop by hop. All the 1xx 
are end to end.

> I have put the following sentence into the draft.
> 

I'd prefer to see it just say 1xx.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 11 Nov 2009 07:07:56 -0800

Although some people/documents might use 1xx when they really mean "101-199", rfc3261 section 7.2 indicates that 100 is included within 1xx.

"For this reason, any response with a status code between 100 and 199 is referred to as a "1xx response","

> Sent: Wednesday, November 11, 2009 9:59 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> >> we discussed the interworking of ISUP ACM and CPG causes to SIP
> reasons headers in provisional responses in 3GPP CT3 yesterday.
> >> Further, it would be very helpfull for 3GPP if you could make the
> updated draft available very quickly as we have several dependent CRs
> in the 3GPP CTx meeting which is ongoing this week.
> >>
> >> Thomas
> >>
> >>
> >> "The appearance of the Reason header is applicable to 3xx, 4xx, 5xx
> and 6xx final responses and 18x and 199 <reference> provisional
> responsess."
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>>>> The appearance of the Reason header is applicable to final
> responses 4xx, 5xx and 6xx and in addition for 199 Responses.
> >>>>>

---

From: <[email-masked]>
Date: Wed, 11 Nov 2009 16:10:45 +0100

Hi Paul,
Sorry. I was to fast with my writing an sending. 
What I meant to write was the 100. But I dont know any other 1xx beyond 18x and 199 that would fit. Or did I forgot one.

Or is it more the general avalibility for 1xx for future.

Best Regards

Roland 

-----Ursprüngliche Nachricht-----
Von: Paul Kyzivat [mailto:[email-masked]] 
Gesendet: Mittwoch, 11. November 2009 23:59
An: Jesske, Roland
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: AW: [dispatch] draft-jesske-sipping-etsi-ngn-reason-04

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Nov 2009 10:36:33 -0500

> "For this reason, any response with a status code between 100 and 199 is referred to as a "1xx response","

Damn! Sorry.

Ok. Then lets go for 101-199.

	Thanks,
	Paul

>> responses
>> responses

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Nov 2009 10:40:09 -0500

> Or is it more the general avalibility for 1xx for future.

Enumerating which ones are meaningful isn't future proof.
Maybe this is a special case since there is a requirement to explicitly 
document which responses this header may appear in (why?),
but IMO it would be better not to second guess, and just allow them all.

My fallback from that would be all 18x and 199.

	Thanks,
	Paul