Subject: [Ecrit] MSD ASN.1 encoding (was: ECRIT Interim meeting - June)

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Jun 2016 12:07:46 +0000

Hi,

...

>Further, 3GPP indicated they want the MSD to be encoded in ASN.1
>rather than XML (both encodings are specified by CEN in EN 15722).
>When this was previously discussed within the IETF, participants
>expressed concern over using ASN.1, but in light of 3GPP's
>preference, and because SIP can use binary content-transfer-encoding
>for body parts, I will make this change unless the group objects.

Could you describe example what you intend to change?

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Sat, 4 Jun 2016 09:58:06 -0700

>  Could you describe example what you intend to change?

Hi Christer,

I intend to change the reference to the MSD from the XML encoding to 
the ASN.1 encoding (from Annex C to Annex A in EN 15722) and the MIME 
registration will delete the "+xml" suffix (so, 
'application/emergencyCallData.eCall.MSD' instead of 
'application/emergencyCallData.eCall.MSD+xml'), with corresponding 
edits to the registration template.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
There's always one more bug.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 4 Jun 2016 21:41:37 +0000

Hi Randall,

>>>expressed concern over using ASN.1, but in light of 3GPP's preference, 
>>>and because SIP can use binary content-transfer-encoding for body 
>>>parts, I will make this change unless the group objects.
>>
> I intend to change the reference to the MSD from the XML encoding to the ASN.1 encoding (from Annex C to Annex A in EN 15722) and 
> the MIME registration will delete the "+xml" suffix (so, 'application/emergencyCallData.eCall.MSD' instead of 'application/emergencyCallData.eCall.MSD+xml'), 
> with corresponding edits to the registration template.

As I said in another e-mail, ASN.1 as such is not an encoding - ASN.1 defines multiple codings, and the CEN spec defines usage of two of those for MSD. I assume we'll only use one of them, the UPER, which needs to be specified.

Also, I assume we have to specify whether the encoded output is going to be transported in binary format, or e.g. in base64 format.

These things need to be defined in the MIME definition.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Sat, 4 Jun 2016 15:18:14 -0700

Hi Christer,

At 9:41 PM +0000 6/4/16, Christer Holmberg wrote:

>>  I intend to change the reference to the MSD from the XML encoding 
>> to the ASN.1 encoding (from Annex C to Annex A in EN 15722) and
>>  the MIME registration will delete the "+xml" suffix (so, 
>> 'application/emergencyCallData.eCall.MSD+xml'),
>  As I said in another e-mail, ASN.1 as such is not an encoding - 
> ASN.1 defines multiple codings, and the CEN spec defines usage of 
> two of those for MSD. I assume we'll only use one of them, the 
> UPER, which needs to be specified.

Thanks for pointing that out, I appreciate it.

>  Also, I assume we have to specify whether the encoded output is 
> going to be transported in binary format, or e.g. in base64 format.

I mentioned before that it would be carried in binary, since SIP 
supports binary content-transfer-encoding, and there is no benefit to 
using base64.

>  These things need to be defined in the MIME definition.

Yes, of course.

-------------- Randomly selected tag: ---------------
Democracy is a form of government that substitutes election by the
incompetent many for appointment by the corrupt few.
                                                      --G. B. Shaw