Re: [MMUSIC] base64 and datetimes in 2326bis

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------