Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 4 Jul 2012 12:59:57 +0300

Folks,

this thread has died without a clear conclusion. Interestingly, one of
the comments was about the unresponsiveness of the editors of the draft
when addressing comments. If there is not enough energy around this
piece of work, it will be impossible to make any type of progress.

Cheers,

Gonzalo

---

From: John-Luc Bakker <[email-masked]>
Date: Thu, 5 Jul 2012 14:21:36 +0000

Hi,

I will be vacationing the next 2 weeks. 
I am planning to collect all open issues and report back.

Ki d regards,

	JL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: Wednesday, July 04, 2012 5:00 AM
To: [email-masked]
Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07

Folks,

this thread has died without a clear conclusion. Interestingly, one of the comments was about the unresponsiveness of the editors of the draft when addressing comments. If there is not enough energy around this piece of work, it will be impossible to make any type of progress.

Cheers,

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

---------------------------------------------------------------------
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: John-Luc Bakker <[email-masked]>
Date: Thu, 26 Jul 2012 21:35:32 +0000

Hi all,

First of all, some editorial improvements have been identified. However, I consider the editorials not the issue that are holding up progress.

I start with a summary of the problem the draft attempts to address.

A content-disposition value is used to select a content handler.

A UA is not expected to inspect the content when deciding on invoking a content handler.

3GPP have specified handling of the MIME media type tag 3gpp-ims+xml body at the Application Server (AS) (a network element in the role of UAS) and at the User Equipment (UE) (in the role of UAC). This handling at the AS (let's say that the handling is performed by a content handler, and let's call this content handler "content handler A") is very different from the handling at the UE (by content handler B).

Note also the following: http://www.iana.org/assignments/media-types/application/3gpp-ims+xml, i.e. the tag itself had been registered with IANA. The registration information explicitly includes:

  Applications which use this media:
  Applications that use the 3GPP IM CN Subsystem as defined by 3GPP.

The problem is: how to select between the different content handlers when this media is received at the UE or at the AS.

This is how I understand the options:

A) choosing between content handler A and content handler B can be done in an implementation specific way: for example, content handler A is selected when a body part with MIME media type tag 3gpp-ims+xml body is received by an AS in the role of UAS. Content handler B is selected when a body part with MIME media type tag 3gpp-ims+xml body is received by a UE in the role of UAC.

B) choosing between a content handler for the MIME media type tag is done based on the Content-Disposition header field value. The advantage is that less customization is needed and software that is more "off-the-shelf" can be obtained.

An option that is not available to 3GPP is to have unique  MIME media type tags, each associated with a content handler. Having unique  MIME media type tags at this stage would raise backwards compatibility concerns.

3GPP have chosen not to preclude option B) above. 3GPP has chosen two content disposition values, one applicable at the AS and one applicable at the UE. Here is an excerpt of the draft:

  6.  IANA Considerations

     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 and are to be registered in the IANA
     registry for Mail Content Disposition Values and Parameters:

        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.

It shows that each disposition-type is associated with a unique content handler.

Open issues

New disposition-types for the Content-Disposition header field can only be registered via drafts on the Experimental track or on the Standards track. We chose to use the Experimental track for registering the two values. People have questioned the use of the Experimental track for this. However, it should be noted that an experimental RFC may be promoted to standards track if it becomes popular.

Another issue is the following:
<copy>
  Using this common content-type with the two different dispositions means 
  that you have new error cases:

  - the C-T is 3gpp-alternative-service and the body contains:

        <ims-3gpp version="1">
           <service-info>
              ...
           </service-info>
        </ims-3gpp>

  - the C-T is 3gpp-service-info and the body contains:

        <ims-3gpp version="1">
           <alternative-service>
              ...
           </alternative-service>
        </ims-3gpp>
<end copy>
It is correct that these error conditions can occur. But this would only occur if the network is misconfigured. Such a misconfiguration is unlikely. I do not consider this an issue but including a note in the draft may be prudent.

Conclusion

In this e-mail, I have not gone into the details of what content handler A or content handler B are actually doing when receiving one of these body parts. Since this media is intended to be used by 3GPP. I believe it is sufficient to understand that the content handler A and the content handler B are very different.

Multiple MIME types have been considered but 3GPP participants could not agree that approach. Therefore, alternative solutions have been considered by the stake holders, but were not found applicable. It may be useful to document the alternative solution in the draft for information.

People have expressed concern that the draft is on experimental track. If sipping also wishes not to preclude option B) above, then apart from agreeing and adding notes as suggested above, fixing the editorials, I believe the selection of the track to be the main issue.

Kind regards,

	John-Luc

-----Original Message-----
From: John-Luc Bakker 
Sent: Thursday, July 05, 2012 9:22 AM
To: 'Gonzalo Camarillo'; [email-masked]
Subject: RE: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07

Hi,

Ki d regards,

	JL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: Wednesday, July 04, 2012 5:00 AM
To: [email-masked]
Subject: Re: [dispatch] draft-bakker-sipping-3gpp-ims-xml-body-handling-07

Folks,

Cheers,

Gonzalo