Re: [MMUSIC] base64 and datetimes in 2326bis

[Claudio Allocchio <[e-mail]>]

Hi all,

On Mon, 7 Oct 2013, Magnus Westerlund wrote:

> Hi,
>
> Claudio Allocchio sent a private comment regarding the NPT formats
> definition in Section 4.4.2 having similar format issues like Section
> 4.4.3. This has resulted in my attempting to write a clearer
> specification. In that work it is clear that this format is not really
> using ISO 8601 syntax. I have attempted to try to make clear this in the
> below new definition of NPT syntax.
>
>  The syntax is based on ISO 8601 [ISO.8601.2000].  Two different
>   notations are allowed.  The npt-hhmmss notation are using a ISO 8601
>   extended complete representation of the time of the day format
>   (Section 5.3.1.1 of [ISO.8601.2000]) using colon (":") as separators
>   between hours, minutes and seconds (hh:mm:ss).  With the exception
>   that it expresses duration since presentation start rather than time
>   since midnight and the hour counter is not limited to 0-24 hours,
>   instead up to nineteen (19) digits of hours are allowed.

OK, tha above is very clear now.

>   ISO 8601
>   time format requires all digits to be used for each format, and all
>   format required needs to be included, e.g. if one use a hh:mm:ss
>   format, then that requires two digits for hours, two digits for
>   minutes and two digits for second, a time value such as 7 minutes and
>   0 seconds, needs to be expressed as 00:07:00.  The npt-sec notation

Minor comment: you could user "MUST" instead of "needs" in the above, as a 
normative statement, too. It is "minor" anyhow because you're referring to 
an external specification here.

>   is expressing the duration since presentation start in seconds, using
>   one to nineteen (19) digits.  Both notations allows decimal fractions
>   of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000] with
>   the limitation of at maximum of 9 digits and only allowing "." (full
>   stop) as separator.  Due to RTSP 1.0 and the fact that the highest
>   values are expanded beyond two digits, all implementations must allow

this is an uppercase "MUST" normative statement.

>   the highest value to be single digit and SHALL NOT send leading zeros
>   for hours in the npt-hhmmss notation and leading zeros for seconds in
>   the ntp-sec notation.  The hours and the seconds in the npt-hhmmss
>   notation SHALL be sent using leading zeros, but receivers SHALL
>   accept values without leading zeros.
>
> So please review this and provide feedback on also this change.

se above ;-)

>
> Cheers
>
> Magnus
>
>
> On 2013-10-07 14:45, Magnus Westerlund wrote:
>> Hi Peter,
>>
>> Thanks for your feedback, and see inline. Especially on the DATE and
>> Time issue I would appreciate feedback.
>>
>> On 2013-09-26 19:27, Peter Saint-Andre wrote:
>>> Here is some brief feedback on 2326bis. I'm sorry that I don't
>>> have time for a longer review.
>>>
>>> BASE64
>>>
>>> The usages of Base64 do not specify which exact encoding of Base64
>>> they require and what to do about padding bits. For example,
>>> Section 18.54 says:
>>>
>>> The binary MIKEY message SHALL be Base64 [RFC4648] encoded before
>>> being included in the value part of the parameter.
>>>
>>> If the specification assumes that the rules from Section 4 of RFC
>>> 4648 are to be used, that text would be more accurate as:
>>>
>>> The binary MIKEY message SHALL be BASE64 [RFC4648] encoded before
>>> being included in the value part of the parameter, where the
>>> encoding adheres to the definition in Section 4 of RFC 4648 and
>>> where the padding bits are set to zero.
>>
>> Yes, you are correct, it is the Section 4 BASE64 mode of the RFC that
>> we want to use here.
>>
>> This will effect three places:
>>
>> Section 18.2:
>>
>>     Each credential MUST consist of one URI
>>    identifying the proxy or server, the hash algorithm identifier, and
>>    the hash over that agent's ASN.1 distinguished encoding rules (DER)
>>    encoded certificate [RFC5280] in BASE64, according to Section 4 of
>>    [RFC4648] and where the padding bits are set to zero.
>>
>>
>> Section 18.13:
>>
>> The header MUST
>>    include the URI of the next hop (proxy or server) and a BASE64
>>    (according to Section 4 of [RFC4648] and where the padding bits are
>>    set to zero) encoded binary structure containing a sequence of DER
>>    encoded X.509v3 certificates [RFC5280].
>>
>>
>> Section 18.54:
>>
>> Under MIKEY parameter
>>
>>                            This parameter can be included both in
>>          request and response messages.  The binary MIKEY message SHALL
>>          be BASE64 [RFC4648] encoded before being included in the value
>>          part of the parameter, where the encoding adheres to the
>>          definition in Section 4 of RFC 4648 and where the padding bits
>>          are set to zero.
>>
>>
>>>
>>> DATETIME FORMATS
>>>
>>> Section 4.4.3 seems to be underspecified:
>>>
>>> Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps,
>>> using UTC (GMT).  Fractions of a second may be indicated.
>>>
>>> Example for clock format range request for a starting time of
>>> November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC
>>> playing for 10 min and 5 seconds, a Media-Properties header's
>>> "Time- Limited UTC property for 24th of December 2014 at 15 hours
>>> and 00 mins, and a Terminate-Readon headers "time" property for
>>> 18th of June 2013 at 16 hours, 12 minutes and 56 seconds:
>>>
>>> clock=19961108T143720.25Z-19961108T144725.25Z
>>> Time-Limited=20141224T1500Z time=20130618T161256Z
>>>
>>> ISO 8601 has many profiles. Is the profile defined in RFC 3339
>>> supported? That would result in a datetime of the following form:
>>>
>>> 1996-11-08T14:37:20.25Z
>>>
>>> Also are timezone offsets allowed?
>>>
>>> If the answers are "no" then it would be good to explain that in
>>> the text.
>>
>> The answers are no on both accounts. The reasons is really the ABNF
>> syntax specified since RTSP 1.0 for this. Thus, I have written a new
>> more complete specification for this time format that matches the ABNF
>> and still uses ISO 8601 relevant sections for some clarifications and
>> specifications. Feedback are much appreciated if you think this is
>> complete.
>>
>> 4.4.3.  Absolute Time
>>
>>    Absolute time is expressed following a specific types of ISO 8601
>>    [ISO.8601.2000] based timestamps.  The date is complete
>>    representation calendar date in basic format (YYYYMMDD) without
>>    separators (per Section 5.2.1.1 of [ISO.8601.2000]).  The time of day
>>    is provided in the complete representation basic format (hhmmss) as
>>    specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal
>>    fractions of seconds following Section 5.3.1.3 requiring "." (full
>>    stop) as decimal separator and limiting the number of digits to no
>>    more than nine (9).  The time expressed MUST be using UTC (GMT), i.e.
>>    no timezone offsets allowed.  The full date and time specification is
>>    the eight digit date followed by a "T" followed by the six digits
>>    time value, optionally followed by a full stop followed by one to
>>    nine fractions of a second and ended by "Z", e.g.
>>    YYYYMMDDThhmmss.ssZ.
>>
>>       The reason for this time format rather than using "Date and Time
>>       on the Internet: Timestamps" [RFC3339] are historic and using the
>>       format specified in RTSP 1.0.  The motivations raised in RFC 3339
>>       applies to why a selection from ISO 8601 was done, but a different
>>       and even more restrictive selection was applied in this case.
>>
>>    Example for clock format range request for a starting time of
>>    November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC
>>    playing for 10 min and 5 seconds, a Media-Properties header's "Time-
>>    Limited UTC property for 24th of December 2014 at 15 hours and 00
>>    mins, and a Terminate-Readon headers "time" property for 18th of June
>>    2013 at 16 hours, 12 minutes and 56 seconds:
>>
>>      clock=19961108T143720.25Z-19961108T144725.25Z
>>      Time-Limited=20141224T1500Z
>>      time=20130618T161256Z
>>
>>
>>
>> cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  [phone]
>> Färögatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>
>
> -- 
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
>
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [e-mail]
                         Senior Technical Officer
tel: [phone]      Italian Academic and       G=Claudio; S=Allocchio;
fax: [phone]        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca