Re: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-26.txt

[Paul Kyzivat <[e-mail]>]

On 2/12/17 2:54 PM, Christer Holmberg wrote:
> Hi,
>
>>> One small comment.
>>>
>>> Section 6 says:
>>>
>>>    "An MSD or a metadata/control block is always enclosed in a multipart
>>>    (normally multipart/mixed) body part (even if it would otherwise be
>>>    the only body part in the SIP message), since as of the date of this
>>>    document, the use of Content-ID as a SIP header field is not defined
>>>    (while it is defined for use as a MIME header field)."
>>>
>>> draft-ietf-sipcore-content-id, which defines Content-ID as a SIP header field, has now been adopted by SIPCORE.
>>>
>>> So, I wonder whether we could simply remove the second part of this paragraph? I don't think we need to change
>>> anything else, because I think we still want to always enclose the stuff in a multipart.
>>
>> Question: is there intent to remove the requirement to wrap the MSD in a multipart body once the the work in
>> sipcore completes? Is it your goal to future proof this text so it need not be changed to accomplish that?
>
> Before I answer your question, I mixed up things a little. In INFO requests we will always place the stuff in a multipart. But, the main reason for that was so the SIP level Content-Disposition value is always 'info-package' (within the MIME we then always use C-D 'by-refernce').
>
> Regarding your question, my initial suggestion was not to remove the requirement to wrap, only to remove the sentence saying that the Content-ID is not defined as a SIP header field. But, when thinking about it, there really is no need to require wrap in non-INFO requests, so maybe we should consider removing it - unless someone comes up with a reason why we should mandate it? In reality I think INVITE requests will at least carry SDP too, so one will anyway have to use a multipart.

Do you want to make this draft wait for that work in sipcore? (And for 
implementations to support it.)

It would be cleaner to remove the requirement for wrapping. But if you 
are in a rush it might be better not to be dependent on that further 
work being completed.

	Thanks,
	Paul

> Regards,
>
> Christer
>
>
>> -----Original Message-----
>> From: Ecrit [mailto:[e-mail]] On Behalf Of Alissa Cooper
>> Sent: 11 February 2017 13:23
>> To: Randall Gellens <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-26.txt
>>
>> Unless there are objections to this by Feb 15, we’ll move forward with the document approval.
>>
>> Thanks,
>> Alissa
>>
>>> On Feb 10, 2017, at 2:33 PM, Randall Gellens <[e-mail]> wrote:
>>>
>>> The only change in this update of the eCall draft is to remove the "+per" suffix.  This was necessary because the designated expert for MIME content type structured content suffix pointed out that ASN.1 PER encoding can't be understood independently of the content (unlike XML, which can be parsed without understanding the content).  As a result, the MIME content type has changed from application/emergencyCallData.eCall.MSD+per to application/emergencyCallData.eCall.MSD.
>>>
>>> --
>>> Randall Gellens
>>> Opinions are personal;    facts are suspect;    I speak for myself only
>>> -------------- Randomly selected tag: ---------------
>>> 2 + 2 = 5 for extremely large values of 2.
>>>
>>> _______________________________________________
>>> Ecrit mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
>