Subject: Re: [MMUSIC] base64 and datetimes in 2326bis

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Oct 2013 14:45:00 +0200

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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Oct 2013 16:43:18 +0200

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

Cheers

Magnus

On 2013-10-07 14:45, Magnus Westerlund wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 

-- 

Magnus Westerlund

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 8 Oct 2013 16:06:35 +0200 (CEST)

Hi all,

On Mon, 7 Oct 2013, Magnus Westerlund wrote:

>   instead up to nineteen (19) digits of hours are allowed.

OK, tha above is very clear now.

>   ISO 8601

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.

>   values are expanded beyond two digits, all implementations must allow

this is an uppercase "MUST" normative statement.

> So please review this and provide feedback on also this change.

se above ;-)

>>      Time-Limited=20141224T1500Z

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 9 Oct 2013 11:19:52 +0200

Hi Claudio,

Thanks for the feedback. See inline.

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

I changed to "is expressed as" being a factual statement in an example.

> this is an uppercase "MUST" normative statement.

Agreed, fixed in my source.

Thanks

Magnus Westerlund