Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt

From: John-Luc Bakker <[email-masked]>
Date: Tue, 4 Sep 2012 15:30:00 +0000

Dear all,

I have submitted a new version of the previous "draft-bakker-sipping-3gpp-ims-xml-body-handling", taking into account the various comments received. The most notable change is to submit the draft to DISPATCH (instead of SIPPING) and to submit the draft for standards track consideration.

I welcome your comments.

Kind regards,

	John-Luc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2012 10:26 AM
To: John-Luc Bakker
Subject: New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt

A new version of I-D, draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt
has been successfully submitted by John-Luc Bakker and posted to the IETF repository.

Filename:	 draft-bakker-dispatch-3gpp-ims-xml-body-handling
Revision:	 00
Title:		 Specification of 3GPP IM CN Subsystem XML body handling
Creation date:	 2012-09-04
WG ID:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt
Status:          http://datatracker.ietf.org/doc/draft-bakker-dispatch-3gpp-ims-xml-body-handling
Htmlized:        http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00

Abstract:
   This document registers new disposition-types for the Content-
   Disposition header field that apply to the application/3gpp-ims+xml
   body (part) used by 3GPP [5].  The applicability of these content-
   disposition values are limited to 3GPP IMS [5].  The application/
   3gpp-ims+xml body (part) has the following three distinct uses: (1)
   for redirecting the emergency session to use a different domain (e.g.
   using a Circuit Switched call), (2) for delivering user profile
   specific information from the SIP registrar to an Application Server,
   and (3) for causing a UAC to attempt to re-register with the IMS.

The IETF Secretariat

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Sep 2012 13:20:26 -0400

To make it easier for other readers, here is a link that does the diff 
of this version to the prior one:

http://tools.ietf.org/rfcdiff?url1=draft-bakker-sipping-3gpp-ims-xml-body-handling-08.txt;url2=draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt

	Regards,
	Paul

On 9/4/12 11:30 AM, John-Luc Bakker wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Atle Monrad <[email-masked]>
Date: Mon, 17 Sep 2012 13:56:07 +0200

All

3GPP has been waiting for long time on completion of this draft. I hope that the new version provided by John-Luc is acceptable and can be progressed.

As the new version has limited changes compated to the previous version, I hope that this draft does not need too long time for considerations before it can be progressed & completed.

>From 3GPP, this draft is supported.

/atle

________________________________ 

Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 4. september 2012 19:20
To: [email-masked]
Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt

To make it easier for other readers, here is a link that does the diff of this version to the prior one:

	Regards,
	Paul

On 9/4/12 11:30 AM, John-Luc Bakker wrote:
> Subject: New Version Notification for 
> draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt
>
>
> A new version of I-D, 
> draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Sep 2012 12:25:50 -0400

I have said all I have to say, repeatedly. The fundamental issues I 
raised, *years* ago now, still remain. It is difficult for me not to 
believe that the goal all along was to bring in a draft to be "rubber 
stamped". Suggestions to clean it up were stonewalled, followed by 
claims that while it could have been better it cannot now be changed 
because it has been deployed in the current form.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Sep 2012 22:57:46 -0500

Be advised, there appears to be extant IPR covering this approach. I've
filed a 3rd party disclosure for the IETF process with respect to
publication *US20090119382.

*

On Tue, Sep 4, 2012 at 10:30 AM, John-Luc Bakker <[email-masked]> wrote:

> Dear all,
>
> I have submitted a new version of the previous
> "draft-bakker-sipping-3gpp-ims-xml-body-handling", taking into account the
> various comments received. The most notable change is to submit the draft
> to DISPATCH (instead of SIPPING) and to submit the draft for standards
> track consideration.
>
> I welcome your comments.
>
> Kind regards,
>
>         John-Luc
>
> URL:
> http://www.ietf.org/internet-drafts/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-bakker-dispatch-3gpp-ims-xml-body-handling
> Htmlized:
> http://tools.ietf.org/html/draft-bakker-dispatch-3gpp-ims-xml-body-handling-00
>
>
> Abstract:
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Sep 2012 23:03:00 -0500

Well, that was silly of me. There was already one out there.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 26 Sep 2012 14:16:12 +0300

Hi John Luc,

I have a quick question about this draft.

The Abstract identifies three uses for 3gpp-ims+xml bodies:

>  (1)

Later, the draft defines two disposition types:

>       o 3gpp-alternative-service: the body (part) contains 3GPP IM CN
>       subsystem XML with the 'alternative-service' XML element as
>       described in Section 4.2; and
> 
>       o 3gpp-service-info: the body (part) contains 3GPP IM CN subsystem
>       XML with the 'service-info' XML element as described in Section
>       4.3.

I assume "3gpp-alternative-service" covers uses (1) and (3) and
"3gpp-service-info" covers use (2). Is this assumption correct? (In any
case, the draft could be clearer on that point.)

After reading the draft, it seems to me that "3gpp-ims+xml" bodies with
disposition type "3gpp-alternative-service" will always be carried in
SIP responses while "3gpp-ims+xml" bodies with disposition type
"3gpp-service-info" will always be carried in SIP requests. Is my
understanding correct?

Thanks,

Gonzalo

---

From: John-Luc Bakker <[email-masked]>
Date: Wed, 26 Sep 2012 21:22:52 +0000

Hi Gonzalo,

> I assume "3gpp-alternative-service" covers uses (1) and (3) and "3gpp-service-info" covers use 
> (2). Is this assumption correct? (In any case, the draft could be clearer on that point.)

That is correct. 
I am happy to further clarify that point in the draft.

> After reading the draft, it seems to me that "3gpp-ims+xml" bodies with disposition type 
> "3gpp-alternative-service" will always be carried in SIP responses while "3gpp-ims+xml" 
> bodies with disposition type "3gpp-service-info" will always be carried in SIP requests. 
> Is my understanding correct?

Today, indeed, "3gpp-ims+xml" bodies with disposition type "3gpp-alternative-service" are carried in SIP responses while "3gpp-ims+xml" bodies with disposition type "3gpp-service-info" are carried in SIP requests.
I don't know if that "will always" be the case.

Kind regards,

	John-Luc

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Wednesday, September 26, 2012 6:16 AM
To: John-Luc Bakker
Cc: [email-masked]
Subject: Re: [dispatch] New Version Notification for draft-bakker-dispatch-3gpp-ims-xml-body-handling-00.txt

Hi John Luc,

>       XML with the 'service-info' XML element as described in Section

I assume "3gpp-alternative-service" covers uses (1) and (3) and "3gpp-service-info" covers use (2). Is this assumption correct? (In any case, the draft could be clearer on that point.)

After reading the draft, it seems to me that "3gpp-ims+xml" bodies with disposition type "3gpp-alternative-service" will always be carried in SIP responses while "3gpp-ims+xml" bodies with disposition type "3gpp-service-info" will always be carried in SIP requests. Is my understanding correct?

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 27 Sep 2012 10:37:21 +0300

Hi John Luc,

> I don't know if that "will always" be the case.

right, everybody I have asked about this also tells me what you say
above. You can distinguish between those two cases by just checking
whether it is a request or a response. The 3GPP specs seem to confirm
that is the case as well. Therefore, what you are saying is that based
on the *current* requirements and use cases that have been discussed so
far, this draft is not needed.

With respect to potential future cases where you would carry one of the
disposition types in both requests and responses, nobody has given any
example of those, at least yet.

In any case, one of the main objections we have seen from the dispatch
community is that this has been presented as an already-made solution
that is already implemented and, thus, could not really be changed much
even if the IETF decided to work on it. But given your answer above, it
seems we do not need this solution for the *current* requirements and
use cases. So, the backward compatibility problem goes away because if
there were *new* requirements or use cases at some point , we could work
on a solution from scratch.

Am I missing something here?

Cheers,

Gonzalo