Subject: [salud] Date format background info

From: [email-masked] (Dale R. Worley)
Date: Tue, 15 Jan 2013 21:30:29 -0500 (EST)

[as an individual]

I was looking for other instances of URIs containing dates.  I found:

RFC 3339 - a standards-track RFC describing preferred ways to
represent dates.  The syntax is:

   5.6. Internet Date/Time Format

   The following profile of ISO 8601 [ISO8601] dates SHOULD be used in
   new protocols on the Internet.  This is specified using the syntax
   description notation defined in [ABNF].

   date-fullyear   = 4DIGIT
   date-month      = 2DIGIT  ; 01-12
   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                             ; month/year
   time-hour       = 2DIGIT  ; 00-23
   time-minute     = 2DIGIT  ; 00-59
   time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                             ; rules
   time-secfrac    = "." 1*DIGIT
   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-time       = full-date "T" full-time

      NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
      syntax may alternatively be lower case "t" or "z" respectively.

draft-masinter-dated-uri-10 - a draft proposing a "duri" scheme, in
which a URI is extended by adding a date on which the URI was valid.
It uses a syntax taken from RFC 3339:

   2. Syntax

   A 'duri' URI takes the form:
        duri:<timestamp>:<embeddedURI>

   and A 'tdb' URI takes a similar form:
        tdb:<timestamp>:<embeddedURI>

   <embeddedURI> is an absoluteURI (as defined in [RFC3986]).

   Whether <embeddedURI> in duri and tdb URIs should allow an embedded
   fra gment identifier was a subject of some discussion; doing so seems
   useful and harmless.

   A <timestamp> in these URI schemes consists of a restricted subset of
   date times, as per [RFC3339].

     timestamp = date [ "T" time "Z" ]
     date       =date-fullyear [ "-" date-month [ "-" date-mday ]]
     time       = time-hour  [ ":" time-minute
                  [ ":" time-second [ time-secfrac ]]]

   where non-terminals "date-fullyear", "date-month", "date-mday",
   "time-hour", "time-minute", "time-second", "time-secfrac" are taken
   from [RFC3339].  The goal is to allow relatively short expressions
   with no ambiguity, but also allow arbitrary precision.  While shorter
   forms are available (e.g., year-only timestamps), it is possible to
   use forms that are exactly compatible with [RFC3339] "date-time" non-
   terminal.

RFC 4151 - defines a "tag" scheme for constructing entity
identifiers.  It uses the YYYY[-MM[-DD]] format, but does not
reference RFC 3339:

   2.1.  Tag Syntax and Examples

   The general syntax of a tag URI, in ABNF [2], is:

      tagURI = "tag:" taggingEntity ":" specific [ "#" fragment ]

   Where:

      taggingEntity = authorityName "," date
      authorityName = DNSname / emailAddress
      date = year ["-" month ["-" day]]
      year = 4DIGIT
      month = 2DIGIT
      day = 2DIGIT
      DNSname = DNScomp *( "."  DNScomp ) ; see RFC 1035 [3]
      DNScomp = alphaNum [*(alphaNum /"-") alphaNum]
      emailAddress = 1*(alphaNum /"-"/"."/"_") "@" DNSname
      alphaNum = DIGIT / ALPHA
      specific = *( pchar / "/" / "?" ) ; pchar from RFC 3986 [1]
      fragment = *( pchar / "/" / "?" ) ; same as RFC 3986 [1]

The pattern shown by these documents supports using "-" as separators
for the MM and DD components.  They also suggest not allowing the
century to be omitted from the year.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jan 2013 21:45:00 -0500

The value of omitting the century and other such abbreviations depends 
on how important we think it is to shorten the identifier. And that 
depends mostly on how often we think it will be necessary to use the 
date at all. If we assume the date is mostly a formality, and it won't 
usually be used, then requiring a four digit year as the minimal form 
may be ok.

	Thanks,
	Paul

On 1/15/13 9:30 PM, Dale R. Worley wrote:
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: Laura Liess <[email-masked]>
Date: Wed, 16 Jan 2013 13:42:17 +0100

And on whether our rule allowing to leave out the date will stand the
review of the URNBIS guys.
If the rule is accepted,  we could even recommend or require in the
draft to leave out the date if the rule applies. Then the date will be
probably not necessary in most cases.
What do you think about working first on the rule for omitting the
date, discuss it with the URNBIS people and then decide if leaving out
the century is a real issue or not?

Thank you
Laura

2013/1/16 Paul Kyzivat <[email-masked]>:
> The value of omitting the century and other such abbreviations depends on
> how important we think it is to shorten the identifier. And that depends
> mostly on how often we think it will be necessary to use the date at all. If
> we assume the date is mostly a formality, and it won't usually be used, then
> requiring a four digit year as the minimal form may be ok.
>
>         Thanks,
>         Paul
>
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 16 Jan 2013 18:50:06 +0100

I'm trying to work out whether I believe we have a problem here to solve or not.

After all, in SIP we have plenty of other URIs that don't carry a date addition.

For example, I make an emergency call. I include a URI (possibly a GRUU) in the Contact information. The PSAP wants to make a callback. Between the emergency call and the callback the domain name has been reassigned. Clearly for that short (matter of hours) duration this has not been identified as an issue.

Why do we need a date as opposed to say inserting a note that indicates that if you reassign the domain name in a salud usage, you need to take steps to refresh the information at entities that may use URLs with that domain name.

Regards

Keith

P.S. If we do end up with a date, I would prefer something conformant with ISO 8601. I also note that the ABNF looks syntactically correct to ISO 8601, but there are additional constraints - for example time-different can only be specified in 15 or 30 minute quanta (I forget which).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dale R. Worley
> Sent: 16 January 2013 02:30
> To: [email-masked]
> Subject: [salud] Date format background info
> 
> [as an individual]
>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 16 Jan 2013 14:57:36 -0500 (EST)

> From: "DRAGE, Keith (Keith)" <[email-masked]>
> 

I spent some time at the Vancouver IETF checking out the issue.  Mark
Nottingham and Alfred Hoenes, among other knowledgeable people, say we
have a problem.  The problem is that these aren't URIs, they're URNs,
and there is a requirement that the meaning of a URN be stable over
time.

> P.S. If we do end up with a date, I would prefer something
> conformant with ISO 8601. I also note that the ABNF looks
> syntactically correct to ISO 8601, but there are additional
> constraints - for example time-different can only be specified in 15
> or 30 minute quanta (I forget which).

Well, the "full" dates we are considering are (assuming that we use
hyphen separators and require the century digits) conformant with
"full-date" in RFC 3339, and RFC 3339 claims it is a subset of ISO
8601.  We don't intend to allow specification of the time component
because there doesn't seem to be any need for it.

Dale