Subject: [MMUSIC] base64 and datetimes in 2326bis

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Sep 2013 11:27:51 -0600

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.

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.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/