Re: [MMUSIC] base64 and datetimes in 2326bis

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 07 October 2013 14:42 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A179211E80F2 for <mmusic@ietfa.amsl.com>; Mon, 7 Oct 2013 07:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.511
X-Spam-Level:
X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE9xZAe8cmFX for <mmusic@ietfa.amsl.com>; Mon, 7 Oct 2013 07:42:32 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id CDA8C11E80E6 for <mmusic@ietf.org>; Mon, 7 Oct 2013 07:42:31 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-02-5252c8566703
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 3E.04.25272.658C2525; Mon, 7 Oct 2013 16:42:30 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.2.328.9; Mon, 7 Oct 2013 16:42:30 +0200
Message-ID: <5252C886.8030200@ericsson.com>
Date: Mon, 07 Oct 2013 16:43:18 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mmusic@ietf.org
References: <52446E97.8030700@stpeter.im> <5252ACCC.50303@ericsson.com>
In-Reply-To: <5252ACCC.50303@ericsson.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+JvrW7YiaAgg9+/9SwW3tnMbjF1+WMW i2N7+pkdmD22vnvH6LFkyU8mj7l7XjAHMEdx2aSk5mSWpRbp2yVwZWxce4u94JhrxcaDv5ga GCebdTFyckgImEgsWn6ZCcIWk7hwbz1bFyMXh5DAUUaJI1smMUI4yxglru74xw5SxSugLbFk 2xJmEJtFQEWi9/BqFhCbTcBC4uaPRjYQW1QgWKJ9+1c2iHpBiZMzn4DViAiISjy6uIgVxGYW iJY4u28+2ExhAVOJ/bPbgZZxAC1zl3i9LAkkzCmgJTHr5kQWiOMkJbYtOsYO0aonMeVqCyOE LS/RvHU22DlCQKc1NHWwTmAUmoVk8ywkLbOQtCxgZF7FyFGcWpyUm25ksIkRGMAHt/y22MF4 +a/NIUZpDhYlcd6Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDmfd0Z7Ct8YF7IdXnB Vxf/fZS2e7xBoN3b1Uup0Kdl2cUO091TmFqV309N4RLdWH2MebNk+Mz7l/bdWifULOe45+I+ p1azqvDcBxVyYXwTdip4cthp344Q2vD07787nGVM/6dqvvbfJfCVe2/BL+mM4C8bGI7krwyQ KZ8ilxMX7n/ht/yWuEdKLMUZiYZazEXFiQDcTA1YLgIAAA==
Cc: Claudio Allocchio <Claudio.Allocchio@garr.it>
Subject: Re: [MMUSIC] base64 and datetimes in 2326bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2013 14:42:37 -0000

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:
> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 


-- 

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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------