From laura.liess.dt@googlemail.com Thu Jan 10 00:19:14 2013 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA1E21F8953 for ; Thu, 10 Jan 2013 00:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyoDBUHsXQVr for ; Thu, 10 Jan 2013 00:19:12 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id AE19D21F893E for ; Thu, 10 Jan 2013 00:19:11 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id ge1so268973lbb.40 for ; Thu, 10 Jan 2013 00:19:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IQV76MAhWnUxWPZazHKw+DeiweYGzgThrjtob/tBiuc=; b=s0g8gutIXTvKPb7UZanNEKY2TF9I4orX54uHiHqC/oX2zmzeQUL8KjAA7sbfwRVuS3 hkLgK8DX5JJf5kqNEWws2eFK/nPEKX4ERLpWJyCutDtarGOuxMGqw+bpb7Rx3WRjbubk X7dSsqL5j3EKRrdOm6KvU42zPpUmcGoNCoyOx1KoeL3x95+DX0aYCNi+fdYboYdeASrb cDdd5Y6UyTdblbiyVo29d/7K3tAnyExtC0RXElSI/hFamIlbCrsYkYaCjB8u4IMt1FWq QxFl8VUfDJjR/Qg06GX5ue7YyLpdz4clfJESAxVURdkevkvQ5vOu8eidoZcdS7c0/Nku m9Sg== MIME-Version: 1.0 Received: by 10.152.122.39 with SMTP id lp7mr68015006lab.0.1357805950288; Thu, 10 Jan 2013 00:19:10 -0800 (PST) Received: by 10.114.98.73 with HTTP; Thu, 10 Jan 2013 00:19:10 -0800 (PST) Date: Thu, 10 Jan 2013 09:19:10 +0100 Message-ID: From: Laura Liess To: salud@ietf.org, Paul Kyzivat , "Dale R. Worley" Content-Type: multipart/alternative; boundary=f46d042dfd9357438404d2ead575 Subject: [salud] format X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 08:19:14 -0000 --f46d042dfd9357438404d2ead575 Content-Type: text/plain; charset=ISO-8859-1 Hi, My understanding from the last discussions is that we think to have a reasonable chance to get the IESG OK without doing major modifications to existing implementations and to the algorithm in Section 9 if we add the year to the domain-name in s as in following examples: a) urn:alert:service:call-waiting:telephone.com~2013 or b) urn:alert:service:call-waiting:telephone.com~13, the URNs above representing the call-waiting Alert-Info URN used by the company which owns the domain telephone.com during 2013. We also may have c) urn:alert:service:call-waiting:telephone.com~13:foo and d) urn:alert:service:call-waiting:telephone.com~12:foo:example.org~13 s are not registred with IANA. Is my understanding correct or did I miss something? Are there additional examples which are relevant for the ABNF-syntax? I am not sure about trying to leave out the year when the enterprise makes sure that it is the first owner of the domain. I suspect the URNBIS people and the IESG will not accept it because IMO there is no mean to ensure that the enterprise guys who defining s will not just assume that the enterprise is the first domain owner instead of verifying it. What is your opinion? Thank you Laura --f46d042dfd9357438404d2ead575 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

My understanding from the =
last discussions is that we think to have a reasonable chance to get the IE=
SG OK without doing major modifications to existing implementations and to =
the algorithm in Section 9 if we add the year to the domain-name in <pri=
vate-name>s as in following examples:=A0=A0 <=
/span>

a) urn:al=
ert:service:call-waiting:telephone.com=
~2013 or

b) urn:alert:service:call-waiting:tele=
phone.com~13,

the URNs above=
 representing the call-waiting Alert-Info URN used by the company which own=
s the domain telephone.com during 2013=
.

=A0
   We also may have =A0

<=
span style=3D"font-family:courier new,monospace">c) urn:alert:service:call-waiting:telephone.com~13:foo =A0<=
/font>

=A0and

=
d) urn:alert:ser=
vice:call-waiting:telephone.com~12:foo=
:example.org~13 =A0<=
/font>

=A0

<private-name>s are not registred with IANA.

=A0

Is my understanding correct or did I miss something? =A0
<=
/span>

Are there additional examples which are relevant for the=
 ABNF-syntax? 

=A0

I am not sure about trying to leav=
e out the year when the enterprise makes 
sure that it is the first owne=
r of the domain. I suspect the URNBIS people and 

the IESG will not accept it because IMO there is no mean to ensure that the=
 
enterprise guys who defining <private-urn>s will not just assume=
 that the enterprise 
is the first domain owner instead of verifying it.=
 What is your opinion?

=A0

Thank you<=
/pre>Laura

--f46d042dfd9357438404d2ead575--

From pkyzivat@alum.mit.edu  Thu Jan 10 11:27:59 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8806321F84CA for ; Thu, 10 Jan 2013 11:27:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.106
X-Spam-Level: 
X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[AWL=0.331,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GprCa0cfVeoe for ; Thu, 10 Jan 2013 11:27:58 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3130221F860A for ; Thu, 10 Jan 2013 11:27:57 -0800 (PST)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id mBiz1k0060bG4ec53KTxtc; Thu, 10 Jan 2013 19:27:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id mKTx1k0063ZTu2S3PKTxHC; Thu, 10 Jan 2013 19:27:57 +0000
Message-ID: <50EF163C.5020103@alum.mit.edu>
Date: Thu, 10 Jan 2013 14:27:56 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Laura Liess 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357846077; bh=zs9niwecajModEhxPyPbIMm80kOaN4jhrQ5eJQ+x3vw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hYfAo443JPIXM/1XOVRvngfi+dgMH/fkju+Jh0+XxuAS+pqV1gfovwTiVxKEW/iJN xJXLkVmNk0kcI/f2b6Y+leVfygtDvlYfkT6JEkvVSnrLhuwbffrWfmzK5eDFNlS2Om hr8oi0k+s6i1y58ELCno4K3Lufoo+WIaf8poYUAzRlIlbmmDrzbJkBwzRbsdHpPb21 Ci8mxV+1st+3/t3hg83Ye6Vv+SVsy8zgUMv9fTnl4xIguzzZbDZTS65vEDkCTXKSc4 pFMEcNponSK16w9juC35NBLJArUC3ribzr3VeUih1Ah0vCkSv/9IYIwFmzQAZC2aYG xpJ+BgJUsdo5A==
Cc: salud@ietf.org
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 10 Jan 2013 19:27:59 -0000

Its been so long that I had to go review the email history to recall 
where the discussion left off.

On 1/10/13 3:19 AM, Laura Liess wrote:
> Hi,
>
> My understanding from the last discussions is that we think to have a reasonable chance to get the IESG OK without doing major modifications to existing implementations and to the algorithm in Section 9 if we add the year to the domain-name in s as in following examples:
>
> a)  urn:alert:service:call-waiting:telephone.com  ~2013 or
>
> b)  urn:alert:service:call-waiting:telephone.com  ~13,
>
> the URNs above representing the call-waiting Alert-Info URN used by the company which owns the domaintelephone.com    during 2013.
>
>     We also may have
>
> c)  urn:alert:service:call-waiting:telephone.com  ~13:foo
>
>   and
>
> d)  urn:alert:service:call-waiting:telephone.com  ~12:foo:example.org  ~13
>
> s are not registred with IANA.
>
> Is my understanding correct or did I miss something?
>
> Are there additional examples which are relevant for the ABNF-syntax?

What I had proposed had a number of options in the date syntax so that 
common cases can be short while still supporting other cases that 
require more to be specified about the date.

(I'm not fond of the ~ syntax. I find it ugly and "peculiar" to look at.
I like enclosing the data in () to be more visually appealing and 
intuitive to understand. But this is a secondary issue.)

> I am not sure about trying to leave out the year when the enterprise makes
> sure that it is the first owner of the domain. I suspect the URNBIS people and
> the IESG will not accept it because IMO there is no mean to ensure that the
> enterprise guys who defining s will not just assume that the enterprise
> is the first domain owner instead of verifying it. What is your opinion?

I would still like to try for it, because:
- the usage is much more convenient and readable without the date
- I think we can come up with a rule where the date won't be needed
   for a large fraction of private names
- if the date is not used in a case where it should be, the negative
   consequences are minor.

	Thanks,
	Paul


From laura.liess.dt@googlemail.com  Fri Jan 11 07:52:33 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1989921F8717 for ; Fri, 11 Jan 2013 07:52:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5Vy4dGKwAY6 for ; Fri, 11 Jan 2013 07:52:31 -0800 (PST)
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 7932221F8610 for ; Fri, 11 Jan 2013 07:52:28 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id gk1so1424001lbb.28 for ; Fri, 11 Jan 2013 07:52:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e0zdNKwYgMPBgmCBP/+th+UO4UitLdPi0EfdSgzzNG8=; b=JIj246khdIL/DF3YG31/Hp3ro3ygxy58c7EiqkaAgC71TPLSmXTFOeCMEh8CQ5k7Zh 8j7iUkH+lpVhzFsi6e2287vXxJd9Pl/Mf3WZXETHqAf7zNmroBUavjRfHyckn3yLiIsY Bws1etDjgEFD2lZB+X87MPUkz+f9WBs4CIVyGvhFrvIzCiPSoTI9XrfRzc5Exlsf+6TU QIYm/IQV3iDVz+rdgyTQAOEbiqqiaBufZ4lq9gBR6kZ7a9/hSimPpgks8RhkJgsZyW9o IBmLGpaqWZZ3R29wHAoeovPZxHx5PJgGfvER1DC94BTTdrhVxV7MwBO9rh8DfJjwB4Fr HBHw==
MIME-Version: 1.0
Received: by 10.152.123.49 with SMTP id lx17mr21233301lab.52.1357919546376; Fri, 11 Jan 2013 07:52:26 -0800 (PST)
Received: by 10.114.98.73 with HTTP; Fri, 11 Jan 2013 07:52:26 -0800 (PST)
In-Reply-To: <50EF163C.5020103@alum.mit.edu>
References:  <50EF163C.5020103@alum.mit.edu>
Date: Fri, 11 Jan 2013 16:52:26 +0100
Message-ID: 
From: Laura Liess 
To: Paul Kyzivat 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: salud@ietf.org
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jan 2013 15:52:33 -0000

Paul,

Thank you. I am trying to put together from the e-mails the
description of the syntax itself and clarifications I can put in the
draft and there are quite a lot issues which are not clear to me.

I have your last proposal on the overall syntax
http://www.ietf.org/mail-archive/web/salud/current/msg00277.html  :

alert-URN       =3D "urn:alert:" alert-identifier
alert-identifier=3D alert-category ":" alert-indication
alert-category  =3D label
alert-indication=3D standard-name / private-name
standard-name   =3D standard-part *(":" standard-part)
private-name    =3D [standard-name ":"] private-part *(":" alert-part)
alert-part      =3D standard-part / private-part
standard-part   =3D label
private-part    =3D label "@" dns-name ["(" version ")"]
dns-name        =3D label "." label *[ "." label ]
version         =3D DIGIT-2-9 / DIGIT-1-9 1*2DIGIT; 2...999
label           =3D let-dig [ *let-dig-hyp let-dig ]
let-dig-hyp     =3D let-dig / "-"
let-dig         =3D ALPHA / DIGIT
ALPHA           =3D %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT           =3D %x30-39 ; 0-9
DIGIT-1-9       =3D %x31-39 ; 1-9
DIGIT-2-9       =3D %x32-39 ; 2-9

Then we agreed to replace the version by date and you sent the syntax
for it http://www.ietf.org/mail-archive/web/salud/current/msg00291.html
:

  CC =3D DIGIT DIGIT
 YY =3D CC
 MM =3D CC
 DD =3D CC

 DATE =3D [CC] YY ["-" MM ["-" DD] ]
  or
 DATE =3D YY [ MM [ DD ]] / CC YY MM DD

Or should we  for the date  just copy the syntax of DateId in the RFC
4198 and make CC optional like

      DateId     =3D [CC]YY [MM [DD]]
      CC           =3D 2(DIGIT)
      YY          =3D 2(DIGIT)
      MM          =3D ("0" %x31-39) / ("1" %x30-32)
      DD          =3D ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"

Also we have following open issues:
 a) The rule for where the date is not needed.
 b) Use "@" or ":" in front of the domain names. "@" makes private
urn's easier to understand, but Dale didn't agree with and I think we
need minor modifications to the algorythm if we use it.
c) Dale proposed  "~"  as the separator  because it is the  only
"unreserved" character available according to RFC
  3986. ( http://www.ietf.org/mail-archive/web/salud/current/msg00290.html =
).

What can we do with these issues? ( I still have additional questions
on the syntax, but let's first solve the issues above.)

Thank you
Laura





2013/1/10 Paul Kyzivat 
>
> Its been so long that I had to go review the email history to recall wher=
e the discussion left off.
>
>
> On 1/10/13 3:19 AM, Laura Liess wrote:
>>
>> Hi,
>>
>> My understanding from the last discussions is that we think to have a re=
asonable chance to get the IESG OK without doing major modifications to exi=
sting implementations and to the algorithm in Section 9 if we add the year =
to the domain-name in s as in following examples:
>>
>> a)  urn:alert:service:call-waiting:telephone.com ~2013 or
>>
>> b)  urn:alert:service:call-waiting:telephone.com  ~13,
>>
>> the URNs above representing the call-waiting Alert-Info URN used by the =
company which owns the domain telephone.com   during 2013.
>>
>>     We also may have
>>
>> c)  urn:alert:service:call-waiting:telephone.com ~13:foo
>>
>>   and
>>
>> d)  urn:alert:service:call-waiting:telephone.com  ~12:foo:example.org  >=
~13
>>
>>
>> s are not registred with IANA.
>>
>> Is my understanding correct or did I miss something?
>>
>> Are there additional examples which are relevant for the ABNF-syntax?
>
>
> What I had proposed had a number of options in the date syntax so that co=
mmon cases can be short while still supporting other cases that require mor=
e to be specified about the date.
>
> (I'm not fond of the ~ syntax. I find it ugly and "peculiar" to look at.
> I like enclosing the data in () to be more visually appealing and intuiti=
ve to understand. But this is a secondary issue.)
>
>
>> I am not sure about trying to leave out the year when the enterprise mak=
es
>> sure that it is the first owner of the domain. I suspect the URNBIS peop=
le and
>> the IESG will not accept it because IMO there is no mean to ensure that =
the
>> enterprise guys who defining s will not just assume that th=
e enterprise
>> is the first domain owner instead of verifying it. What is your opinion?
>
>
> I would still like to try for it, because:
> - the usage is much more convenient and readable without the date
> - I think we can come up with a rule where the date won't be needed
>   for a large fraction of private names
> - if the date is not used in a case where it should be, the negative
>   consequences are minor.
>
>         Thanks,
>         Paul
>

From pkyzivat@alum.mit.edu  Fri Jan 11 08:45:41 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B625021F891A for ; Fri, 11 Jan 2013 08:45:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.012
X-Spam-Level: *
X-Spam-Status: No, score=1.012 tagged_above=-999 required=5 tests=[AWL=-0.851,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  MANGLED_TOOL=2.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKkKpqAvjpSm for ; Fri, 11 Jan 2013 08:45:41 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 98D6321F8971 for ; Fri, 11 Jan 2013 08:45:40 -0800 (PST)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id mcGm1k0020vyq2s53glfsc; Fri, 11 Jan 2013 16:45:39 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id mglf1k00e3ZTu2S3RglfJd; Fri, 11 Jan 2013 16:45:39 +0000
Message-ID: <50F041B3.2080004@alum.mit.edu>
Date: Fri, 11 Jan 2013 11:45:39 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Laura Liess 
References:  <50EF163C.5020103@alum.mit.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357922739; bh=shHAWzcvVYaDhlWk1Dzln09AjVXt/hcNL+4nqlgvC68=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VRdaGWXs0owWVSz/BoUaYNSoKunM1ebnfKmAty1MSN225KRFZuzOtCf7NimI1pB/7 5avT9zHSBQ8fKClyXJdsCDyrE0l6cqvuoP9XoygnVgspXStfaWwKJI0npQI+jTWwka Szdj9Ic8uaQcw83fjm5ml62ODObsBGgfjdoaUQlm/S6H81O0h3MHEuosvaZ5eT6sOL CkC3GG75it1ix9jG6ppNND1zpbQwbD75XBCQc8iIW3QbquDEvht6bikMjVUmgcUrML 6ZVyb3dSqpHLNSgg9BSnEOOMJ5Yj3bj0sEMgCRjt81NT7gP59epz+M7tJESEne/uhA OO2HZweJKe4BA==
Cc: salud@ietf.org
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Jan 2013 16:45:41 -0000

On 1/11/13 10:52 AM, Laura Liess wrote:
> Paul,
>
> Thank you. I am trying to put together from the e-mails the
> description of the syntax itself and clarifications I can put in the
> draft and there are quite a lot issues which are not clear to me.
>
> I have your last proposal on the overall syntax
> http://www.ietf.org/mail-archive/web/salud/current/msg00277.html  :
>
> alert-URN       = "urn:alert:" alert-identifier
> alert-identifier= alert-category ":" alert-indication
> alert-category  = label
> alert-indication= standard-name / private-name
> standard-name   = standard-part *(":" standard-part)
> private-name    = [standard-name ":"] private-part *(":" alert-part)
> alert-part      = standard-part / private-part
> standard-part   = label
> private-part    = label "@" dns-name ["(" version ")"]
> dns-name        = label "." label *[ "." label ]
> version         = DIGIT-2-9 / DIGIT-1-9 1*2DIGIT; 2...999
> label           = let-dig [ *let-dig-hyp let-dig ]
> let-dig-hyp     = let-dig / "-"
> let-dig         = ALPHA / DIGIT
> ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
> DIGIT           = %x30-39 ; 0-9
> DIGIT-1-9       = %x31-39 ; 1-9
> DIGIT-2-9       = %x32-39 ; 2-9
>
> Then we agreed to replace the version by date and you sent the syntax
> for it http://www.ietf.org/mail-archive/web/salud/current/msg00291.html
> :
>
>    CC = DIGIT DIGIT
>   YY = CC
>   MM = CC
>   DD = CC
>
>   DATE = [CC] YY ["-" MM ["-" DD] ]
>    or
>   DATE = YY [ MM [ DD ]] / CC YY MM DD

Note that the above is two alternatives for the date.
We would need to choose one. I think I prefer the first, but I don't 
feel strongly about it. (I doubt that the month and day will be used 
much. They are only needed if you are not the first owner of the dns 
name and you need to form one of these before the year has rolled over 
after you gained ownership.)

The syntax for either of these can be tightened up regarding MM and DD, 
as is done below.

> Or should we  for the date  just copy the syntax of DateId in the RFC
> 4198 and make CC optional like
>
>        DateId     = [CC]YY [MM [DD]]
>        CC           = 2(DIGIT)
>        YY          = 2(DIGIT)
>        MM          = ("0" %x31-39) / ("1" %x30-32)
>        DD          = ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"

Making CC optional above makes the syntax ambiguous. Four digits could 
be either CCYY or YYMM.

> Also we have following open issues:
>   a) The rule for where the date is not needed.

Yep.

How about:
- if the date is absent, it defaults to 20000101
- if DD or MM are absent each default to 01
- if CC is absent it defaults to 20
- comparison is based on the full CCYYMMDD after
   defaults have been filled in.

You are permitted to use any date when you control the DNS name. If you 
are the first owner of a DNS name then you may also use dates prior to 
your ownership. This rule for use actually applies to the assignment of 
meaning to the name, rather than use of the name in a message.

>   b) Use "@" or ":" in front of the domain names. "@" makes private
> urn's easier to understand, but Dale didn't agree with and I think we
> need minor modifications to the algorythm if we use it.
> c) Dale proposed  "~"  as the separator  because it is the  only
> "unreserved" character available according to RFC
>    3986. ( http://www.ietf.org/mail-archive/web/salud/current/msg00290.html ).

This is all about esthetics. I still like @ better.
Shall we vote?

> What can we do with these issues? ( I still have additional questions
> on the syntax, but let's first solve the issues above.)

You have my opinions. Lets see what others think.

	Thanks,
	Paul


From laura.liess.dt@googlemail.com  Mon Jan 14 07:51:04 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E8621F87A6 for ; Mon, 14 Jan 2013 07:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Level: 
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk9uIjYqPPqV for ; Mon, 14 Jan 2013 07:51:04 -0800 (PST)
Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) by ietfa.amsl.com (Postfix) with ESMTP id 831E421F85A2 for ; Mon, 14 Jan 2013 07:51:03 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id fs13so3925477lab.23 for ; Mon, 14 Jan 2013 07:51:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yo/mnPSQLwW/W9XbppXGWUAM9Zry+2fs/h0bOCgXNl4=; b=w0ecPyq0V29K7OYDwHe2A+cxBdWAtayGhvL5mdJPIxjZtJgOPsL+9OGcb8wJXd/Zc1 rMcPrOrhuMSeaR4SYzw9jJxpBwTx7ewcksaEBelPW6+TiHz6Cq8UVL888syQb0Nle6I/ 9TJMoKmjRnwJ2GjceBBfZyo5JQbwEWYgJKiYKWcqzfoc3vQzRXuA0rhMZZwEIXzzHcQ9 NVk77LDhDecyWFXIkAsQD4JiWjykIJeH72rg7zDXCaGx1e9hsPdZorZiZqOxk1zY4g6m 5lovy3+KWxBwCPjH3KYbh5Bvg8DCWd4ZyFRyWmnbQt2ou3rOgwTRJIxYJIvX6Xt3CDr5 fQQQ==
MIME-Version: 1.0
Received: by 10.152.104.112 with SMTP id gd16mr83400070lab.26.1358178662280; Mon, 14 Jan 2013 07:51:02 -0800 (PST)
Received: by 10.114.98.73 with HTTP; Mon, 14 Jan 2013 07:51:02 -0800 (PST)
In-Reply-To: <50F041B3.2080004@alum.mit.edu>
References:  <50EF163C.5020103@alum.mit.edu>  <50F041B3.2080004@alum.mit.edu>
Date: Mon, 14 Jan 2013 16:51:02 +0100
Message-ID: 
From: Laura Liess 
To: Paul Kyzivat 
Content-Type: text/plain; charset=ISO-8859-1
Cc: salud@ietf.org
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Jan 2013 15:51:04 -0000

Paul,

Before asking for the  WG feedback, let me write down my understanding
on your proposal with  instead of ,  just to ensure
that I didn't miss anything:

alert-URN          = "urn:alert:" alert-identifier
alert-identifier= alert-category ":" alert-indication
alert-category  = label
alert-indication= standard-name / private-name
standard-name   = standard-part *(":" standard-part)
private-name    = [standard-name ":"] private-part *(":" alert-part)
alert-part      = standard-part / private-part
standard-part   = label
private-part    = label "@" dns-name ["(" date ")"]
dns-name        = label "." label *[ "." label ]
date = [CC] YY ["-" MM ["-" DD] ]
label           = let-dig [ *let-dig-hyp let-dig ]
let-dig-hyp     = let-dig / "-"
let-dig         = ALPHA / DIGIT
YY = CC
MM = CC
DD = CC
CC = DIGIT DIGIT
ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT           = %x30-39 ; 0-9
DIGIT-1-9       = %x31-39 ; 1-9
DIGIT-2-9       = %x32-39 ; 2-9


Dale would prefer a different syntax for :
private-part    = label ":" dns-name ["~" date ]

Following rules apply to the  usage
a) A domain is permited to use any  within its domain name
ownership time period.
b) Only the first owner of a DNS name is allowed to leave out the
 or to use s prior to its ownership.
c) If the  is absent, it defaults to 20000101.
d) If  or  are absent each default to 01
e) If  is absent it defaults to 20
f) Comparison is based on the full  after defaults have been
filled in.

Is this OK?

Thanks a lot
Laura


2013/1/11 Paul Kyzivat :
> On 1/11/13 10:52 AM, Laura Liess wrote:
>>
>> Paul,
>>
>> Thank you. I am trying to put together from the e-mails the
>> description of the syntax itself and clarifications I can put in the
>> draft and there are quite a lot issues which are not clear to me.
>>
>> I have your last proposal on the overall syntax
>> http://www.ietf.org/mail-archive/web/salud/current/msg00277.html  :
>>
>> alert-URN       = "urn:alert:" alert-identifier
>> alert-identifier= alert-category ":" alert-indication
>> alert-category  = label
>> alert-indication= standard-name / private-name
>> standard-name   = standard-part *(":" standard-part)
>> private-name    = [standard-name ":"] private-part *(":" alert-part)
>> alert-part      = standard-part / private-part
>> standard-part   = label
>> private-part    = label "@" dns-name ["(" version ")"]
>> dns-name        = label "." label *[ "." label ]
>> version         = DIGIT-2-9 / DIGIT-1-9 1*2DIGIT; 2...999
>> label           = let-dig [ *let-dig-hyp let-dig ]
>> let-dig-hyp     = let-dig / "-"
>> let-dig         = ALPHA / DIGIT
>> ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
>> DIGIT           = %x30-39 ; 0-9
>> DIGIT-1-9       = %x31-39 ; 1-9
>> DIGIT-2-9       = %x32-39 ; 2-9
>>
>> Then we agreed to replace the version by date and you sent the syntax
>> for it http://www.ietf.org/mail-archive/web/salud/current/msg00291.html
>> :
>>
>>    CC = DIGIT DIGIT
>>   YY = CC
>>   MM = CC
>>   DD = CC
>>
>>   DATE = [CC] YY ["-" MM ["-" DD] ]
>>    or
>>   DATE = YY [ MM [ DD ]] / CC YY MM DD
>
>
> Note that the above is two alternatives for the date.
> We would need to choose one. I think I prefer the first, but I don't feel
> strongly about it. (I doubt that the month and day will be used much. They
> are only needed if you are not the first owner of the dns name and you need
> to form one of these before the year has rolled over after you gained
> ownership.)
>
> The syntax for either of these can be tightened up regarding MM and DD, as
> is done below.
>
>
>> Or should we  for the date  just copy the syntax of DateId in the RFC
>> 4198 and make CC optional like
>>
>>        DateId     = [CC]YY [MM [DD]]
>>        CC           = 2(DIGIT)
>>        YY          = 2(DIGIT)
>>        MM          = ("0" %x31-39) / ("1" %x30-32)
>>        DD          = ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"
>
>
> Making CC optional above makes the syntax ambiguous. Four digits could be
> either CCYY or YYMM.
>
>
>> Also we have following open issues:
>>   a) The rule for where the date is not needed.
>
>
> Yep.
>
> How about:
> - if the date is absent, it defaults to 20000101
> - if DD or MM are absent each default to 01
> - if CC is absent it defaults to 20
> - comparison is based on the full CCYYMMDD after
>   defaults have been filled in.
>
> You are permitted to use any date when you control the DNS name. If you are
> the first owner of a DNS name then you may also use dates prior to your
> ownership. This rule for use actually applies to the assignment of meaning
> to the name, rather than use of the name in a message.
>
>
>>   b) Use "@" or ":" in front of the domain names. "@" makes private
>> urn's easier to understand, but Dale didn't agree with and I think we
>> need minor modifications to the algorythm if we use it.
>> c) Dale proposed  "~"  as the separator  because it is the  only
>> "unreserved" character available according to RFC
>>    3986. (
>> http://www.ietf.org/mail-archive/web/salud/current/msg00290.html ).
>
>
> This is all about esthetics. I still like @ better.
> Shall we vote?
>
>
>> What can we do with these issues? ( I still have additional questions
>> on the syntax, but let's first solve the issues above.)
>
>
> You have my opinions. Lets see what others think.
>
>         Thanks,
>         Paul
>

From pkyzivat@alum.mit.edu  Mon Jan 14 11:40:08 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961E821F8AF4 for ; Mon, 14 Jan 2013 11:40:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.999
X-Spam-Level: 
X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[AWL=-0.864,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  MANGLED_TOOL=2.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFUX7RhrRLfP for ; Mon, 14 Jan 2013 11:40:07 -0800 (PST)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id A8E0621F8AD4 for ; Mon, 14 Jan 2013 11:40:07 -0800 (PST)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta02.westchester.pa.mail.comcast.net with comcast id nnnz1k0061swQuc51vg7j8; Mon, 14 Jan 2013 19:40:07 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id nvg61k00x3ZTu2S3bvg6Z4; Mon, 14 Jan 2013 19:40:07 +0000
Message-ID: <50F45F16.3080403@alum.mit.edu>
Date: Mon, 14 Jan 2013 14:40:06 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Laura Liess 
References:  <50EF163C.5020103@alum.mit.edu>  <50F041B3.2080004@alum.mit.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358192407; bh=l+iKGGcfwKwTzKwnfLYF9A/ST8p8EjPmylGFHs0iLEU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DLKTJaB2M+PbUofLT1yD8H9kGhoFjAmnv/pS6RSxx+0tY4aQ8vxkW0NPjMrcSoe7z rohUBOrKdAD6RnCFoGSFo7/oAfFpT2a1/TZF2e8srbEG5m5z4MhcZvYzoxpX2I1vz7 sqLiEbSKK4W0OqVo+CqOgKLbZSpwwxP2HbNc9dYhGXgCECz5H/3om/jCsMoGm6lYqV Z7cuydV9NxuPqb9E22fyjWjrEIh17rcEZXo9SAR1d+TKR/p1r5wuAgk6PytZS8AtxK tJ3hQ6H2u7/ADeSfBfVP4QjqtsXBVK19LXCOibtoRdJNFLMbaU2KWAg5ZCzWX2Cfpy vAHL61T9i8s2Q==
Cc: salud@ietf.org
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Jan 2013 19:40:08 -0000

On 1/14/13 10:51 AM, Laura Liess wrote:
> Paul,
>
> Before asking for the  WG feedback, let me write down my understanding
> on your proposal with  instead of ,  just to ensure
> that I didn't miss anything:
>
> alert-URN          = "urn:alert:" alert-identifier
> alert-identifier= alert-category ":" alert-indication
> alert-category  = label
> alert-indication= standard-name / private-name
> standard-name   = standard-part *(":" standard-part)
> private-name    = [standard-name ":"] private-part *(":" alert-part)
> alert-part      = standard-part / private-part
> standard-part   = label
> private-part    = label "@" dns-name ["(" date ")"]
> dns-name        = label "." label *[ "." label ]
> date = [CC] YY ["-" MM ["-" DD] ]
> label           = let-dig [ *let-dig-hyp let-dig ]
> let-dig-hyp     = let-dig / "-"
> let-dig         = ALPHA / DIGIT
> YY = CC
> MM = CC
> DD = CC
> CC = DIGIT DIGIT
> ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
> DIGIT           = %x30-39 ; 0-9
> DIGIT-1-9       = %x31-39 ; 1-9
> DIGIT-2-9       = %x32-39 ; 2-9

Yes. I have noted that this can be enhanced to be more precise about the 
month and day (so day 99 isn't syntactically valid). But we can do that 
after we have agreement on this.

> Dale would prefer a different syntax for :
> private-part    = label ":" dns-name ["~" date ]

Without looking back, I'm not certain. But it was something like this. 
(I'm thinking the it might have had the label on the right rather than 
the left.

My biggest problem with this is that it has a ":" separator in the 
middle of a private part. That at least makes it complex to explain the 
rules for dropping parts to find a match.

> Following rules apply to the  usage
> a) A domain is permited to use any  within its domain name
> ownership time period.
> b) Only the first owner of a DNS name is allowed to leave out the
>  or to use s prior to its ownership.
> c) If the  is absent, it defaults to 20000101.
> d) If 
 or  are absent each default to 01
> e) If  is absent it defaults to 20
> f) Comparison is based on the full  after defaults have been
> filled in.

Yes, more or less. We have more to sort out here, and the language to do 
it might get tricky.

The thing is that the use we are specifying the syntax for is a 
*reference* to an alert that we presume has already been defined. 
Anybody can write a reference, not just the owner. (E.g. I am allowed to 
reference your private alert.) The limitation on use applies to those 
who define them. And since we don't specify how private alerts are 
defined or advertised, this part is all very hypothetical.

	Thanks,
	Paul

> Is this OK?
>
> Thanks a lot
> Laura
>
>
> 2013/1/11 Paul Kyzivat :
>> On 1/11/13 10:52 AM, Laura Liess wrote:
>>>
>>> Paul,
>>>
>>> Thank you. I am trying to put together from the e-mails the
>>> description of the syntax itself and clarifications I can put in the
>>> draft and there are quite a lot issues which are not clear to me.
>>>
>>> I have your last proposal on the overall syntax
>>> http://www.ietf.org/mail-archive/web/salud/current/msg00277.html  :
>>>
>>> alert-URN       = "urn:alert:" alert-identifier
>>> alert-identifier= alert-category ":" alert-indication
>>> alert-category  = label
>>> alert-indication= standard-name / private-name
>>> standard-name   = standard-part *(":" standard-part)
>>> private-name    = [standard-name ":"] private-part *(":" alert-part)
>>> alert-part      = standard-part / private-part
>>> standard-part   = label
>>> private-part    = label "@" dns-name ["(" version ")"]
>>> dns-name        = label "." label *[ "." label ]
>>> version         = DIGIT-2-9 / DIGIT-1-9 1*2DIGIT; 2...999
>>> label           = let-dig [ *let-dig-hyp let-dig ]
>>> let-dig-hyp     = let-dig / "-"
>>> let-dig         = ALPHA / DIGIT
>>> ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
>>> DIGIT           = %x30-39 ; 0-9
>>> DIGIT-1-9       = %x31-39 ; 1-9
>>> DIGIT-2-9       = %x32-39 ; 2-9
>>>
>>> Then we agreed to replace the version by date and you sent the syntax
>>> for it http://www.ietf.org/mail-archive/web/salud/current/msg00291.html
>>> :
>>>
>>>     CC = DIGIT DIGIT
>>>    YY = CC
>>>    MM = CC
>>>    DD = CC
>>>
>>>    DATE = [CC] YY ["-" MM ["-" DD] ]
>>>     or
>>>    DATE = YY [ MM [ DD ]] / CC YY MM DD
>>
>>
>> Note that the above is two alternatives for the date.
>> We would need to choose one. I think I prefer the first, but I don't feel
>> strongly about it. (I doubt that the month and day will be used much. They
>> are only needed if you are not the first owner of the dns name and you need
>> to form one of these before the year has rolled over after you gained
>> ownership.)
>>
>> The syntax for either of these can be tightened up regarding MM and DD, as
>> is done below.
>>
>>
>>> Or should we  for the date  just copy the syntax of DateId in the RFC
>>> 4198 and make CC optional like
>>>
>>>         DateId     = [CC]YY [MM [DD]]
>>>         CC           = 2(DIGIT)
>>>         YY          = 2(DIGIT)
>>>         MM          = ("0" %x31-39) / ("1" %x30-32)
>>>         DD          = ("0" %x31-39) / (%x31-32 DIGIT) / "30" / "31"
>>
>>
>> Making CC optional above makes the syntax ambiguous. Four digits could be
>> either CCYY or YYMM.
>>
>>
>>> Also we have following open issues:
>>>    a) The rule for where the date is not needed.
>>
>>
>> Yep.
>>
>> How about:
>> - if the date is absent, it defaults to 20000101
>> - if DD or MM are absent each default to 01
>> - if CC is absent it defaults to 20
>> - comparison is based on the full CCYYMMDD after
>>    defaults have been filled in.
>>
>> You are permitted to use any date when you control the DNS name. If you are
>> the first owner of a DNS name then you may also use dates prior to your
>> ownership. This rule for use actually applies to the assignment of meaning
>> to the name, rather than use of the name in a message.
>>
>>
>>>    b) Use "@" or ":" in front of the domain names. "@" makes private
>>> urn's easier to understand, but Dale didn't agree with and I think we
>>> need minor modifications to the algorythm if we use it.
>>> c) Dale proposed  "~"  as the separator  because it is the  only
>>> "unreserved" character available according to RFC
>>>     3986. (
>>> http://www.ietf.org/mail-archive/web/salud/current/msg00290.html ).
>>
>>
>> This is all about esthetics. I still like @ better.
>> Shall we vote?
>>
>>
>>> What can we do with these issues? ( I still have additional questions
>>> on the syntax, but let's first solve the issues above.)
>>
>>
>> You have my opinions. Lets see what others think.
>>
>>          Thanks,
>>          Paul
>>
>


From worley@shell01.TheWorld.com  Mon Jan 14 15:31:05 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DB821F8B7C for ; Mon, 14 Jan 2013 15:31:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.528
X-Spam-Level: 
X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-fB5OQTl3hj for ; Mon, 14 Jan 2013 15:31:05 -0800 (PST)
Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 405AE21F8B77 for ; Mon, 14 Jan 2013 15:31:04 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0ENUMqH002045 for ; Mon, 14 Jan 2013 18:30:24 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0ENUMn35183492 for ; Mon, 14 Jan 2013 18:30:22 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0ENULa95176575; Mon, 14 Jan 2013 18:30:21 -0500 (EST)
Date: Mon, 14 Jan 2013 18:30:21 -0500 (EST)
Message-Id: <201301142330.r0ENULa95176575@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <50F45F16.3080403@alum.mit.edu> (pkyzivat@alum.mit.edu)
References:  <50EF163C.5020103@alum.mit.edu>  <50F041B3.2080004@alum.mit.edu>  <50F45F16.3080403@alum.mit.edu>
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Jan 2013 23:31:06 -0000

[I am back on the Salud mailing list, so you don't have to Cc: me on
messages any more.]

I've assembled this list, which I think includes all the issues we've
been discussing regarding dates attached to domain names in
private-names.  I've tried to assemble all the issues and all of the
solutions that have been suggested so far.  (Issues regarding
private-names generically are not included.)

-----

Open issues regarding dates for domain names in private-names

(1) In order to provide every successive owner of a domain name the
ability to use the domain name in a unique way in URNs, we can extend
the domain name with (1a) the sequential number of the owner of the
domain name among all owners of the domain name, or (1b) a date on
which the domain name was owned.

Assuming choice (1b), the current baseline syntax proposal is as in
this example:

    urn:alert:service:call-waiting:telephone.com~2013:foo

(2) What syntax is used to combine the domain name with the date?
(2a) Separate the two with "~", e.g., "telephone.com~2013" (because
"~" is the only URI "unreserved" character that does not appear in any
other syntactic component of Alert-Info URNs).  (2b) Enclose the date
in "(...)", e.g., "telephone.com(2013)".

(Note:  The URI generic syntax is in RFC 3986, which is significantly
different from the predecessor, RFC 2396.  "(" and ")" are
, but  can appear in every location that
 can.)

(3) Is it possible to omit the date, and if so, what is the
significance of that?  (3a) The date can be omitted, and: (3a1) is
equivalent to a fixed "default" date, both for URN comparison and URN
interpretation, (3a2) is *not* equivalent to the domain name with a
date.  (3b) The date cannot be omitted.

There seems to be general agreement that the date syntax will be
somewhat like CCYY[MM[DD]], that is, it can be specified down to the
day if necessary, but the month and day can be omitted.  Omitted month
and day are equivalent to "01".

(4) How is the century indicated?  (4a) Century is not indicated, and
is always "20".  (4b) Century must always be indicated.  (4c) Century
may be omitted, in which case it defaults to "20" (both for URN
comparison and URN interpretation).

(5) Should there be separators between the CCYY, MM, and DD
components?  (5a) There are no separators.  (5b) The separator is "-".

Note:  (4c) [CC optional] together with (5a) [no separator] is
syntactically ambiguous.

(6) What date is the default if no date is provided?  (6a) Use
2000-01-01, as it is a convenient round number.  (6b) Use 2013-01-01,
since the maximizes the number of current users who can use the
default date.

(7) If an entity is the first owner of a domain name, but did not own
it on the default date, is the entity permitted to use the domain name
without a date?  (Is it possible to verify that one is the first owner
of a domain name, or at least the only owner since the default date?)
(7a) Yes, the first owner can do that.  (7b) No, the first owner
cannot do that.

-----

Dale

From pkyzivat@alum.mit.edu  Mon Jan 14 17:40:01 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05AF21F8717 for ; Mon, 14 Jan 2013 17:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.019
X-Spam-Level: *
X-Spam-Status: No, score=1.019 tagged_above=-999 required=5 tests=[AWL=-0.844,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  MANGLED_TOOL=2.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCeqB5a9LuNc for ; Mon, 14 Jan 2013 17:40:00 -0800 (PST)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDCC11E80C5 for ; Mon, 14 Jan 2013 17:39:58 -0800 (PST)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id np0l1k0031GhbT8551fybW; Tue, 15 Jan 2013 01:39:58 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id o1fy1k00A3ZTu2S3T1fySZ; Tue, 15 Jan 2013 01:39:58 +0000
Message-ID: <50F4B36D.9030603@alum.mit.edu>
Date: Mon, 14 Jan 2013 20:39:57 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: salud@ietf.org
References:  <50EF163C.5020103@alum.mit.edu>  <50F041B3.2080004@alum.mit.edu>  <50F45F16.3080403@alum.mit.edu> <201301142330.r0ENULa95176575@shell01.TheWorld.com>
In-Reply-To: <201301142330.r0ENULa95176575@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358213998; bh=5LMECywTTWNWHiHRRGrk1gIiC+9rvR1u4eQaUfgNxOw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Tt3VPuLUdTdpmazv6vNjGkgJcCAD9gZheQR6MASV3FPL+aTQquYggBMeKK9m8dw2n l5/QXPOVe1hDhx4deBaIAwQ4fcof8cIDTO6dMBOKytZrhBHIVUyU+wrgqnQeiBqsRM 2J6ZPwNfeLS795/KOtHjUF1Z4uAkxrcdJpKj1Kl4a2RvgGCWvSC1Ay76HVzQk+TofC 5JEiFuiVjdI3s1EFnxxUqRb3iq67N7mFcnbQY/CFaJKBAI2ji/QmNxZdAhyhHmMFtO PVCQGxAUypZWlXcqC3uxV2dPwrZb7JHvC6BVgpfWR5AqFgRnDeOxXPxCp3lCQ5aELz rlAeZGW3m1iaw==
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jan 2013 01:40:01 -0000

This seems to cover it.

	Thanks,
	Paul

On 1/14/13 6:30 PM, Dale R. Worley wrote:
> [I am back on the Salud mailing list, so you don't have to Cc: me on
> messages any more.]
>
> I've assembled this list, which I think includes all the issues we've
> been discussing regarding dates attached to domain names in
> private-names.  I've tried to assemble all the issues and all of the
> solutions that have been suggested so far.  (Issues regarding
> private-names generically are not included.)
>
> -----
>
> Open issues regarding dates for domain names in private-names
>
> (1) In order to provide every successive owner of a domain name the
> ability to use the domain name in a unique way in URNs, we can extend
> the domain name with (1a) the sequential number of the owner of the
> domain name among all owners of the domain name, or (1b) a date on
> which the domain name was owned.
>
> Assuming choice (1b), the current baseline syntax proposal is as in
> this example:
>
>      urn:alert:service:call-waiting:telephone.com~2013:foo
>
> (2) What syntax is used to combine the domain name with the date?
> (2a) Separate the two with "~", e.g., "telephone.com~2013" (because
> "~" is the only URI "unreserved" character that does not appear in any
> other syntactic component of Alert-Info URNs).  (2b) Enclose the date
> in "(...)", e.g., "telephone.com(2013)".
>
> (Note:  The URI generic syntax is in RFC 3986, which is significantly
> different from the predecessor, RFC 2396.  "(" and ")" are
> , but  can appear in every location that
>  can.)
>
> (3) Is it possible to omit the date, and if so, what is the
> significance of that?  (3a) The date can be omitted, and: (3a1) is
> equivalent to a fixed "default" date, both for URN comparison and URN
> interpretation, (3a2) is *not* equivalent to the domain name with a
> date.  (3b) The date cannot be omitted.
>
> There seems to be general agreement that the date syntax will be
> somewhat like CCYY[MM[DD]], that is, it can be specified down to the
> day if necessary, but the month and day can be omitted.  Omitted month
> and day are equivalent to "01".
>
> (4) How is the century indicated?  (4a) Century is not indicated, and
> is always "20".  (4b) Century must always be indicated.  (4c) Century
> may be omitted, in which case it defaults to "20" (both for URN
> comparison and URN interpretation).
>
> (5) Should there be separators between the CCYY, MM, and DD
> components?  (5a) There are no separators.  (5b) The separator is "-".
>
> Note:  (4c) [CC optional] together with (5a) [no separator] is
> syntactically ambiguous.
>
> (6) What date is the default if no date is provided?  (6a) Use
> 2000-01-01, as it is a convenient round number.  (6b) Use 2013-01-01,
> since the maximizes the number of current users who can use the
> default date.
>
> (7) If an entity is the first owner of a domain name, but did not own
> it on the default date, is the entity permitted to use the domain name
> without a date?  (Is it possible to verify that one is the first owner
> of a domain name, or at least the only owner since the default date?)
> (7a) Yes, the first owner can do that.  (7b) No, the first owner
> cannot do that.
>
> -----
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From worley@shell01.TheWorld.com  Mon Jan 14 18:49:10 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274A711E809A for ; Mon, 14 Jan 2013 18:49:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.509
X-Spam-Level: 
X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.471,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L53JfgAiVo+C for ; Mon, 14 Jan 2013 18:49:09 -0800 (PST)
Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 9115311E8099 for ; Mon, 14 Jan 2013 18:49:09 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0F2moJj005948 for ; Mon, 14 Jan 2013 21:48:52 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0F2moNN5160817 for ; Mon, 14 Jan 2013 21:48:50 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0F2mnYI5181179; Mon, 14 Jan 2013 21:48:49 -0500 (EST)
Date: Mon, 14 Jan 2013 21:48:49 -0500 (EST)
Message-Id: <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> (trac+salud@grenache.tools.ietf.org)
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org>
Subject: Re: [salud] #1: Year/version for domain names used in private-names
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jan 2013 02:49:10 -0000

[as chair]

I've decided to use the IETF Trac tracker as a *personal* tool for the
chair (me) to track the open issues in the draft.  That is, I am using
it as a personal reference; other WG members do not need to pay
attention to it.

But it seems that the WG mailing list receives messages whenever a
ticket is created or updated; please forgive the extra e-mail.

WG members should feel free to look at the tickets if they want.  The
listing is at http://trac.tools.ietf.org/wg/salud/trac/report/1  If
you find any errors, please tell me and I will correct them.

Dale

> From: "salud issue tracker" 
> 
> #1: Year/version for domain names used in private-names
> 
>  The URN scheme uses domain names to provide unique namespaces for private
>  extensions.  However, a single domain name may be owned by different
>  entities over the years, and so an entity does not have clearly unique
>  ownership of a namespace identified only by a domain name.  Thus, we need
>  to extend domain names with some sort of indicator to produce identifiers
>  that are uniquely owned by entities.
> 
[etc.]

From worley@shell01.TheWorld.com  Mon Jan 14 19:10:03 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7866B11E80AE for ; Mon, 14 Jan 2013 19:10:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.693
X-Spam-Level: 
X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=-1.502, BAYES_05=-1.11, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBpVrZB3cJRJ for ; Mon, 14 Jan 2013 19:10:03 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id D83CB11E80A5 for ; Mon, 14 Jan 2013 19:10:02 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0F39pBP028622 for ; Mon, 14 Jan 2013 22:09:53 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0F39pKi5186331 for ; Mon, 14 Jan 2013 22:09:51 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0F39ohG5179371; Mon, 14 Jan 2013 22:09:50 -0500 (EST)
Date: Mon, 14 Jan 2013 22:09:50 -0500 (EST)
Message-Id: <201301150309.r0F39ohG5179371@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to:  (laura.liess.dt@googlemail.com)
References:  <50EF163C.5020103@alum.mit.edu>  <50F041B3.2080004@alum.mit.edu> 
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jan 2013 03:10:03 -0000

> From: Laura Liess 
> 
> Following rules apply to the  usage
> a) A domain is permited to use any  within its domain name
> ownership time period.
> b) Only the first owner of a DNS name is allowed to leave out the
>  or to use s prior to its ownership.
> c) If the  is absent, it defaults to 20000101.
> d) If 
 or  are absent each default to 01
> e) If  is absent it defaults to 20
> f) Comparison is based on the full  after defaults have been
> filled in.

Based on the list of issues regarding dates, this proposal is the set
of choices:

    (1b) date to extend domain name

    (2b) Use "(...)" as a separator.

    (3a1) Missing date defaults to 2000-01-01.

    (4c) Century defaults to "20".

    (5b) MM and DD are separated by "-".

    (6a) Default date is 2000-01-01.

    (7a) First owner of domain name can use dates before its ownership.

Generally, I agree with this proposal.  But I would like to change the
default date to 2013-01-01, because it may allow a larger number of
users to define URNs without dates, and there is no user who will need
to define a URN with a date before 2013.

Dale

From laura.liess.dt@googlemail.com  Tue Jan 15 05:15:34 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC15321F87D9 for ; Tue, 15 Jan 2013 05:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.594
X-Spam-Level: 
X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.383,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drAiXdWh+Acb for ; Tue, 15 Jan 2013 05:15:34 -0800 (PST)
Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id CBA7B21F889D for ; Tue, 15 Jan 2013 05:15:33 -0800 (PST)
Received: by mail-lb0-f171.google.com with SMTP id n8so144140lbj.16 for ; Tue, 15 Jan 2013 05:15:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yQp2B54hCRZ89GOLdot/VIEi9qYUaQjcTJpz0fnTa4E=; b=NqtJ/KrMBoi7hDkv1+Xkc281mKdrdnStAAl7B/7ViPUo7FseL4ZG8ioRF1DrPsQeNG r2EKvBxgFHpxLYyp0pFQ9O2NP7gBSAqAuZFTpDks8yPbzPT5ow2bnNlLe3mht4Vj0DTy qTxr7pyrUdjCiJhS32hHquE+ZIMeCgmk1TipzKIombMERneWdl16dAF9HG9MQ+FQkYg1 WI7VhYWkNCr49x6/9sElx/3h3LAydWC+c2nLti095I/gZNsjeDFLDr3dHAn/5QhR1715 TcHmhq2KkOJFtRCeNPuH2i2bjZbbwDdHa37BhQNYuX7jbMwmvJxwuDPysVcnrPNfn2Mi pObQ==
MIME-Version: 1.0
Received: by 10.152.123.49 with SMTP id lx17mr33706462lab.52.1358255732725; Tue, 15 Jan 2013 05:15:32 -0800 (PST)
Received: by 10.114.98.73 with HTTP; Tue, 15 Jan 2013 05:15:32 -0800 (PST)
In-Reply-To: <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>
Date: Tue, 15 Jan 2013 14:15:32 +0100
Message-ID: 
From: Laura Liess 
To: "Dale R. Worley" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: salud@ietf.org
Subject: Re: [salud] #1: Year/version for domain names used in private-names
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jan 2013 13:15:34 -0000

Dale,

We have an additional issue concerning the separator between the
 and the  in the . It's not a major
issue, just syntax, but it has to be clarified.

The alternatives which I know about up to now:
a) "@"
b) ":"

Thank you
Laura



2013/1/15 Dale R. Worley :
> [as chair]
>
> I've decided to use the IETF Trac tracker as a *personal* tool for the
> chair (me) to track the open issues in the draft.  That is, I am using
> it as a personal reference; other WG members do not need to pay
> attention to it.
>
> But it seems that the WG mailing list receives messages whenever a
> ticket is created or updated; please forgive the extra e-mail.
>
> WG members should feel free to look at the tickets if they want.  The
> listing is at http://trac.tools.ietf.org/wg/salud/trac/report/1  If
> you find any errors, please tell me and I will correct them.
>
> Dale
>
>> From: "salud issue tracker" 
>>
>> #1: Year/version for domain names used in private-names
>>
>>  The URN scheme uses domain names to provide unique namespaces for private
>>  extensions.  However, a single domain name may be owned by different
>>  entities over the years, and so an entity does not have clearly unique
>>  ownership of a namespace identified only by a domain name.  Thus, we need
>>  to extend domain names with some sort of indicator to produce identifiers
>>  that are uniquely owned by entities.
>>
> [etc.]
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From pkyzivat@alum.mit.edu  Tue Jan 15 08:23:03 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD4821F84CE for ; Tue, 15 Jan 2013 08:23:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.037
X-Spam-Level: *
X-Spam-Status: No, score=1.037 tagged_above=-999 required=5 tests=[AWL=-0.826,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  MANGLED_TOOL=2.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+U2H-oMJ65O for ; Tue, 15 Jan 2013 08:23:01 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 82A3921F849A for ; Tue, 15 Jan 2013 08:23:00 -0800 (PST)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id oBfh1k00C1YDfWL53GNxDq; Tue, 15 Jan 2013 16:22:57 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id oGNx1k0123ZTu2S3gGNxVe; Tue, 15 Jan 2013 16:22:57 +0000
Message-ID: <50F58261.9050302@alum.mit.edu>
Date: Tue, 15 Jan 2013 11:22:57 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: salud@ietf.org
References:  <50EF163C.5020103@alum.mit.edu>  <50F041B3.2080004@alum.mit.edu>  <201301150309.r0F39ohG5179371@shell01.TheWorld.com>
In-Reply-To: <201301150309.r0F39ohG5179371@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358266977; bh=0UxCV8a3hzMewvu8sy/pu8lYUntxB+gSf6UWc4ZWiVM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=I5sqw21kfRoUIAUEW+T3coG55bU8tuziKFIQQGa761f2DxeG2fm7UQlUGHbb9qoI6 B34H50sxjDMiKAlJP4E/UopQRr430aGsRYz4RrMbZXZMMphJhYrjoXepYg62dd2uL6 toBLrajQ3kbsueanb0URICm8TTMf942JbV3R6rOIZVo/AgpyB/evrzTITezfYhfN/Q ku7WN+h27P5CIWBmW652Ir9LM38+I+LWNvuXAz/bir7KUheaAzqq85OoZaMAm8ij6V TAmx6fsb0V0Qj0ucDRtZ3xhew502X4EM+y11ZIko+zrK3tEmddp5T9X9abZukX3Ylm sYRwgvQ/GYrwQ==
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Jan 2013 16:23:03 -0000

I'm ok with a default of 2013.

On 1/14/13 10:09 PM, Dale R. Worley wrote:
>> From: Laura Liess 
>>
>> Following rules apply to the  usage
>> a) A domain is permited to use any  within its domain name
>> ownership time period.
>> b) Only the first owner of a DNS name is allowed to leave out the
>>  or to use s prior to its ownership.
>> c) If the  is absent, it defaults to 20000101.
>> d) If 
 or  are absent each default to 01
>> e) If  is absent it defaults to 20
>> f) Comparison is based on the full  after defaults have been
>> filled in.
>
> Based on the list of issues regarding dates, this proposal is the set
> of choices:
>
>      (1b) date to extend domain name
>
>      (2b) Use "(...)" as a separator.
>
>      (3a1) Missing date defaults to 2000-01-01.
>
>      (4c) Century defaults to "20".
>
>      (5b) MM and DD are separated by "-".
>
>      (6a) Default date is 2000-01-01.
>
>      (7a) First owner of domain name can use dates before its ownership.
>
> Generally, I agree with this proposal.  But I would like to change the
> default date to 2013-01-01, because it may allow a larger number of
> users to define URNs without dates, and there is no user who will need
> to define a URN with a date before 2013.
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From worley@shell01.TheWorld.com  Tue Jan 15 18:31:06 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8045011E80F2 for ; Tue, 15 Jan 2013 18:31:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.373
X-Spam-Level: 
X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.607,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btddOkNnSJIk for ; Tue, 15 Jan 2013 18:31:06 -0800 (PST)
Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id D0C6411E80E1 for ; Tue, 15 Jan 2013 18:31:05 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0G2UVAj011386 for ; Tue, 15 Jan 2013 21:30:33 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0G2UU7A5218333 for ; Tue, 15 Jan 2013 21:30:30 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0G2UTOa5199085; Tue, 15 Jan 2013 21:30:29 -0500 (EST)
Date: Tue, 15 Jan 2013 21:30:29 -0500 (EST)
Message-Id: <201301160230.r0G2UTOa5199085@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
Subject: [salud] Date format background info
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jan 2013 02:31:06 -0000

[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::

   and A 'tdb' URI takes a similar form:
        tdb::

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

   Whether  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  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 pkyzivat@alum.mit.edu  Tue Jan 15 18:45:04 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF81811E80AD for ; Tue, 15 Jan 2013 18:45:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.108
X-Spam-Level: 
X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[AWL=0.329,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dfxQVWq9RmV for ; Tue, 15 Jan 2013 18:45:03 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 7D56D11E80E1 for ; Tue, 15 Jan 2013 18:45:01 -0800 (PST)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta15.westchester.pa.mail.comcast.net with comcast id oJJr1k0030mv7h05FSl1oB; Wed, 16 Jan 2013 02:45:01 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id oSl11k00B3ZTu2S3XSl19C; Wed, 16 Jan 2013 02:45:01 +0000
Message-ID: <50F6142C.4070709@alum.mit.edu>
Date: Tue, 15 Jan 2013 21:45:00 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: salud@ietf.org
References: <201301160230.r0G2UTOa5199085@shell01.TheWorld.com>
In-Reply-To: <201301160230.r0G2UTOa5199085@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358304301; bh=q57U7Sw2LJQX1K7RyMsIUS6vlNIj5B0xBIIlPQ4Dkt4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rh5hErMavhjtzrugDvevHumJzC3FviemrDabZX6ogGEDninhMpR+WvERRfA6mAxfL l/SC6m5XCPiGA9bJ7piOqIDjQYACSozXLKYnCTZH2nrmbPKY74bVpTO/6KI4jaXOjY PuxPVO1dnldgwjra21Qu0loKtuV0FBE/9ZHePdWbW7D08Q5p6WLgzyZ2t7HUjp9dlv u9tR3peA8qkcLDsBq4+dwJg1o+4ycNfuibbhkTUS//DuPOiY+KHtmPR7yVj8F9b0hd 5WM6qIEKb1gh/miyfejcd+hLguJuPe1BU+BHM/r9meaSt3gv8xEj1U1MnJnmXWecI5 9C6MMWumDuhRg==
Subject: Re: [salud] Date format background info
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jan 2013 02:45:05 -0000

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:
> [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::
>
>     and A 'tdb' URI takes a similar form:
>          tdb::
>
>      is an absoluteURI (as defined in [RFC3986]).
>
>     Whether  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  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
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From laura.liess.dt@googlemail.com  Wed Jan 16 04:42:19 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BB421F8584 for ; Wed, 16 Jan 2013 04:42:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level: 
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=0.288,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-k6dmAAoq1U for ; Wed, 16 Jan 2013 04:42:19 -0800 (PST)
Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id AB96121F859D for ; Wed, 16 Jan 2013 04:42:18 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id j14so1011698lbo.1 for ; Wed, 16 Jan 2013 04:42:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9egGZWMiBMiGoprPb/Heniaxsnc6uea+V6+SsO4ZWcY=; b=h8kRcQb8IbwFy/3V7cxxrIHFfbqd+RLyDr9jyEdL6Tdsxi1cb765lgEv6bgZaXw8o3 pmyloIMSHq0+yCa62vj3iuAQlYAenqZSwywoPpnAUTsXa48orZrtkz7c1VbR96sa5Dcg ld2sr8xfgUBcHSl54qiA3dwmgOkpmsTok68yj/6hsJNUp22jP9U2PqHmArNh15pmARBv 4p02xL3EzVM7yzjuaoX0TDbe0M1CIimv+YnDhPH98ivqSppV14hzJzEBoax5Ncih2r/m VyTMvxjt6Xc5xnhqpF5vP6doduFKyffhDRslWTe2i75gaphZ9wh6bNX43Zl0Vvc3TI1y r8Xg==
MIME-Version: 1.0
X-Received: by 10.112.8.163 with SMTP id s3mr555075lba.113.1358340137513; Wed, 16 Jan 2013 04:42:17 -0800 (PST)
Received: by 10.114.98.73 with HTTP; Wed, 16 Jan 2013 04:42:17 -0800 (PST)
In-Reply-To: <50F6142C.4070709@alum.mit.edu>
References: <201301160230.r0G2UTOa5199085@shell01.TheWorld.com> <50F6142C.4070709@alum.mit.edu>
Date: Wed, 16 Jan 2013 13:42:17 +0100
Message-ID: 
From: Laura Liess 
To: Paul Kyzivat 
Content-Type: text/plain; charset=ISO-8859-1
Cc: salud@ietf.org
Subject: Re: [salud] Date format background info
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jan 2013 12:42:20 -0000

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 :
> 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:
>>
>> [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::
>>
>>     and A 'tdb' URI takes a similar form:
>>          tdb::
>>
>>      is an absoluteURI (as defined in [RFC3986]).
>>
>>     Whether  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  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
>> _______________________________________________
>> salud mailing list
>> salud@ietf.org
>> https://www.ietf.org/mailman/listinfo/salud
>>
>
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From keith.drage@alcatel-lucent.com  Wed Jan 16 09:50:23 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B012121F8BA1 for ; Wed, 16 Jan 2013 09:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.929
X-Spam-Level: 
X-Spam-Status: No, score=-106.929 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20HvzZ5t28kA for ; Wed, 16 Jan 2013 09:50:23 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id B867E21F8B8A for ; Wed, 16 Jan 2013 09:50:22 -0800 (PST)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0GHo7I2026928 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 16 Jan 2013 18:50:08 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 16 Jan 2013 18:50:08 +0100
From: "DRAGE, Keith (Keith)" 
To: "Dale R. Worley" , "salud@ietf.org" 
Date: Wed, 16 Jan 2013 18:50:06 +0100
Thread-Topic: [salud] Date format background info
Thread-Index: Ac3zkY2GC5KYjJppTmeSEkFvG4plxwAf6rdA
Message-ID: 
References: <201301160230.r0G2UTOa5199085@shell01.TheWorld.com>
In-Reply-To: <201301160230.r0G2UTOa5199085@shell01.TheWorld.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84
Subject: Re: [salud] Date format background info
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jan 2013 17:50:24 -0000

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 addi=
tion.

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 em=
ergency call and the callback the domain name has been reassigned. Clearly =
for that short (matter of hours) duration this has not been identified as a=
n issue.

Why do we need a date as opposed to say inserting a note that indicates tha=
t 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 n=
ame.

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 onl=
y be specified in 15 or 30 minute quanta (I forget which).



> -----Original Message-----
> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of
> Dale R. Worley
> Sent: 16 January 2013 02:30
> To: salud@ietf.org
> Subject: [salud] Date format background info
>=20
> [as an individual]
>=20
> I was looking for other instances of URIs containing dates.  I found:
>=20
> RFC 3339 - a standards-track RFC describing preferred ways to
> represent dates.  The syntax is:
>=20
>    5.6. Internet Date/Time Format
>=20
>    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].
>=20
>    date-fullyear   =3D 4DIGIT
>    date-month      =3D 2DIGIT  ; 01-12
>    date-mday       =3D 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
>                              ; month/year
>    time-hour       =3D 2DIGIT  ; 00-23
>    time-minute     =3D 2DIGIT  ; 00-59
>    time-second     =3D 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
>                              ; rules
>    time-secfrac    =3D "." 1*DIGIT
>    time-numoffset  =3D ("+" / "-") time-hour ":" time-minute
>    time-offset     =3D "Z" / time-numoffset
>=20
>    partial-time    =3D time-hour ":" time-minute ":" time-second
>                      [time-secfrac]
>    full-date       =3D date-fullyear "-" date-month "-" date-mday
>    full-time       =3D partial-time time-offset
>=20
>    date-time       =3D full-date "T" full-time
>=20
>       NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
>       syntax may alternatively be lower case "t" or "z" respectively.
>=20
> 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:
>=20
>    2. Syntax
>=20
>    A 'duri' URI takes the form:
>         duri::
>=20
>    and A 'tdb' URI takes a similar form:
>         tdb::
>=20
>     is an absoluteURI (as defined in [RFC3986]).
>=20
>    Whether  in duri and tdb URIs should allow an embedded
>    fra gment identifier was a subject of some discussion; doing so seems
>    useful and harmless.
>=20
>    A  in these URI schemes consists of a restricted subset of
>    date times, as per [RFC3339].
>=20
>      timestamp =3D date [ "T" time "Z" ]
>      date       =3Ddate-fullyear [ "-" date-month [ "-" date-mday ]]
>      time       =3D time-hour  [ ":" time-minute
>                   [ ":" time-second [ time-secfrac ]]]
>=20
>    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.
>=20
> RFC 4151 - defines a "tag" scheme for constructing entity
> identifiers.  It uses the YYYY[-MM[-DD]] format, but does not
> reference RFC 3339:
>=20
>    2.1.  Tag Syntax and Examples
>=20
>    The general syntax of a tag URI, in ABNF [2], is:
>=20
>       tagURI =3D "tag:" taggingEntity ":" specific [ "#" fragment ]
>=20
>    Where:
>=20
>       taggingEntity =3D authorityName "," date
>       authorityName =3D DNSname / emailAddress
>       date =3D year ["-" month ["-" day]]
>       year =3D 4DIGIT
>       month =3D 2DIGIT
>       day =3D 2DIGIT
>       DNSname =3D DNScomp *( "."  DNScomp ) ; see RFC 1035 [3]
>       DNScomp =3D alphaNum [*(alphaNum /"-") alphaNum]
>       emailAddress =3D 1*(alphaNum /"-"/"."/"_") "@" DNSname
>       alphaNum =3D DIGIT / ALPHA
>       specific =3D *( pchar / "/" / "?" ) ; pchar from RFC 3986 [1]
>       fragment =3D *( pchar / "/" / "?" ) ; same as RFC 3986 [1]
>=20
> 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.
>=20
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From worley@shell01.TheWorld.com  Wed Jan 16 11:57:06 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CFE21F8A61 for ; Wed, 16 Jan 2013 11:57:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.531,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okxzPV4+UVjU for ; Wed, 16 Jan 2013 11:57:06 -0800 (PST)
Received: from TheWorld.com (pcls2.std.com [192.74.137.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0E14E21F8625 for ; Wed, 16 Jan 2013 11:57:05 -0800 (PST)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0GJuPSR004732 for ; Wed, 16 Jan 2013 14:56:27 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0GJuOUq5276674 for ; Wed, 16 Jan 2013 14:56:25 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0GJuOWG4887702; Wed, 16 Jan 2013 14:56:24 -0500 (EST)
Date: Wed, 16 Jan 2013 14:56:24 -0500 (EST)
Message-Id: <201301161956.r0GJuOWG4887702@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to:  (laura.liess.dt@googlemail.com)
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> <201301150248.r0F2mnYI5181179@shell01.TheWorld.com> 
Subject: [salud]  separator
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jan 2013 19:57:06 -0000

[as an individual]

> From: Laura Liess 
> 
> We have an additional issue concerning the separator between the
>  and the  in the . It's not a major
> issue, just syntax, but it has to be clarified.
> 
> The alternatives which I know about up to now:
> a) "@"
> b) ":"

Yes.  Let me summarize what I've seen about this syntax question:

(1) When a FQDN is added to create a private-name component, do we
require an additional label (whose meaning is defined by the owner of
the FQDN)?

(2) Suggested syntaxes (omitting any date specification):

    ...:label@FQDN:...

    ...:FQDN:label:...

(Of course there are other possibilities.)

Dale

From worley@shell01.TheWorld.com  Wed Jan 16 11:58:03 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C63121F8629 for ; Wed, 16 Jan 2013 11:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level: 
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.472,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpJXKr3PooC2 for ; Wed, 16 Jan 2013 11:58:02 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7A73821F8758 for ; Wed, 16 Jan 2013 11:58:02 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0GJvbLP000735; Wed, 16 Jan 2013 14:57:39 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0GJvbD85287529; Wed, 16 Jan 2013 14:57:37 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0GJvau95293737; Wed, 16 Jan 2013 14:57:36 -0500 (EST)
Date: Wed, 16 Jan 2013 14:57:36 -0500 (EST)
Message-Id: <201301161957.r0GJvau95293737@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: "DRAGE, Keith (Keith)" 
In-reply-to:  (keith.drage@alcatel-lucent.com)
References: <201301160230.r0G2UTOa5199085@shell01.TheWorld.com> 
Cc: salud@ietf.org
Subject: Re: [salud] Date format background info
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jan 2013 19:58:03 -0000

> From: "DRAGE, Keith (Keith)" 
> 
> I'm trying to work out whether I believe we have a problem here to
> solve or not.

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

From pkyzivat@alum.mit.edu  Wed Jan 16 13:30:48 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E91211E80FD for ; Wed, 16 Jan 2013 13:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.483
X-Spam-Level: 
X-Spam-Status: No, score=0.483 tagged_above=-999 required=5 tests=[AWL=-0.280,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  J_CHICKENPOX_45=0.6, J_CHICKENPOX_55=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhudrG-M-QrR for ; Wed, 16 Jan 2013 13:30:47 -0800 (PST)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 83F7A11E80FA for ; Wed, 16 Jan 2013 13:30:47 -0800 (PST)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id od3K1k0021swQuc51lWmMA; Wed, 16 Jan 2013 21:30:46 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id olWm1k00S3ZTu2S3blWm96; Wed, 16 Jan 2013 21:30:46 +0000
Message-ID: <50F71C05.3080008@alum.mit.edu>
Date: Wed, 16 Jan 2013 16:30:45 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: salud@ietf.org
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>  <201301161956.r0GJuOWG4887702@shell01.TheWorld.com>
In-Reply-To: <201301161956.r0GJuOWG4887702@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1358371846; bh=7V4an9OU9bwqyuYYTDKESAzsRhTpesBwLBfwe8684GM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=S/VcdfOP+RNwIDwE+g80TOOVVkOwnJH0rseYtstQLIVyGq08hM09qGIqhjo6Hj3lW 0KnFRiTSLtH7cNMIPihRvg/Epb5L0LUGfPguXPDPLCoj3YQEyJOWjiAKKUwdMdFPDD 1+L9TpfNV4OZwFw6aCxMjn/5zC1ZfQeyHwwbHbXTLtj/hmVmsM8jUUbComdze8cOB0 v5fCVlMoyFsn/OH4KOrp9SWYe5+kYazQcrndQ5vbZU3XCvfGgRPTXJGVi4fKBoPfL8 Pfth3rwm1EKeyeBqN7ut5WInDggQP66GOYl2+BnjMgKXo57XT1Frgq3O06GCc+TJcY LcQGnrqqeG/cw==
Subject: Re: [salud]  separator
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Jan 2013 21:30:48 -0000

On 1/16/13 2:56 PM, Dale R. Worley wrote:
> [as an individual]
>
>> From: Laura Liess 
>>
>> We have an additional issue concerning the separator between the
>>  and the  in the . It's not a major
>> issue, just syntax, but it has to be clarified.
>>
>> The alternatives which I know about up to now:
>> a) "@"
>> b) ":"
>
> Yes.  Let me summarize what I've seen about this syntax question:
>
> (1) When a FQDN is added to create a private-name component, do we
> require an additional label (whose meaning is defined by the owner of
> the FQDN)?

IMO the issue isn't *if* we require it. The issue is how it is 
represented if it is present.

IOW, I am ok with allowing both:

  ...:label@FQDN:...
and
  ...:FQDN:...

> (2) Suggested syntaxes (omitting any date specification):
>
>      ...:label@FQDN:...
>
>      ...:FQDN:label:...

The issue I have with the latter syntax is:

the FQDN:label syntax is very similar to label:label. It implies that 
you can drop the label while looking for a match. That is OK if FQDN is 
itself intended to have meaning without a subsequent label.

With the @ syntax, it is clear (I hope) that label@FQDN is a single 
element that must be dropped as a whole.

Either way, you can then have subsequent labels, that will be in the 
scope of this one.

So maybe you can consider the @ syntax to be an extension to your : 
syntax, rather than an alternative.

	Thanks,
	Paul

> (Of course there are other possibilities.)
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From laura.liess.dt@googlemail.com  Sat Jan 19 12:33:41 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27AC21F86CA for ; Sat, 19 Jan 2013 12:33:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Level: 
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEcdavZgzQ-L for ; Sat, 19 Jan 2013 12:33:39 -0800 (PST)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 6E55421F86BA for ; Sat, 19 Jan 2013 12:33:39 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id gj3so3475788lbb.39 for ; Sat, 19 Jan 2013 12:33:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=p8uAk/AlOL1urXua00ZC6g3Z0N8DAtlOhBB2JtjRY0I=; b=tKfS7sIhjX1QbhTsWJ1ed4NUqdKZFuL33XggyaGwvYSklYD20Dh+7uKZq6yZIUVemX BbnBlBfiA20GC9NJAkzU24zuCIHBkcJ1nSnkQCCdkwMoX2mLnuWLTZD1d58EIwQCCys5 Ymwmc4EfSC8oGmb7v13i0k3Bu1d4fWwEhVKm/UDKChg8Qsqhg5YUCN+pFEkgvs5p8uDK 2ww18RtrtvNICSIOGFsLPIZQjoxEpPDPoWEH40CFFeSKql7u+D6nrXj3qAsrfsrApkiP /NCLtnfue5cDZtJHltxYKWjmW1KsXlajMUu1ziO5HWswT2oHrZUbWqZPqr5dmWycC075 uIGg==
MIME-Version: 1.0
X-Received: by 10.152.148.129 with SMTP id ts1mr12684524lab.19.1358627618058;  Sat, 19 Jan 2013 12:33:38 -0800 (PST)
Received: by 10.114.98.73 with HTTP; Sat, 19 Jan 2013 12:33:37 -0800 (PST)
In-Reply-To: <50F71C05.3080008@alum.mit.edu>
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>  <201301161956.r0GJuOWG4887702@shell01.TheWorld.com> <50F71C05.3080008@alum.mit.edu>
Date: Sat, 19 Jan 2013 21:33:37 +0100
Message-ID: 
From: Laura Liess 
To: Paul Kyzivat , salud@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [salud]  separator
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Jan 2013 20:33:41 -0000

Hi,

> The issue I have with the latter syntax is:
>
> the FQDN:label syntax is very similar to label:label. It implies that you
> can drop the label while looking for a match. That is OK if FQDN is itself
> intended to have meaning without a subsequent label.
>
> With the @ syntax, it is clear (I hope) that label@FQDN is a single element
> that must be dropped as a whole.

IMO this aspect is essential.
If we expect an UA which receives e.g.
urn:alert:service:recall:holdtelephone.com and does not
understand it to remove both "hold" and "telephone.com" and proceed
with the urn:alert:service:recall  and not with
urn:alert:service:recall:hold, we should not use ":" as a separator.
Previously to Paul's mail I thought we want the UA to remove just
telephone.com and continue with   urn:alert:service:recall:hold  so
urn:alert:service:recall:hold:telephone.com was OK for me. I do not
really like the format   urn:alert:service:recall:telephone.com:hold
for the reason described by Paul.
I vote for using "@" as a separator because it is intuitive and we do
not have to change the algorithm.

By the way, do we need to add to Section 6.2.1
urn:alert:service:recall or to say something about a default value?

Thank you
Laura







2013/1/16 Paul Kyzivat :
> On 1/16/13 2:56 PM, Dale R. Worley wrote:
>>
>> [as an individual]
>>
>>> From: Laura Liess 
>>>
>>> We have an additional issue concerning the separator between the
>>>  and the  in the . It's not a major
>>> issue, just syntax, but it has to be clarified.
>>>
>>> The alternatives which I know about up to now:
>>> a) "@"
>>> b) ":"
>>
>>
>> Yes.  Let me summarize what I've seen about this syntax question:
>>
>> (1) When a FQDN is added to create a private-name component, do we
>> require an additional label (whose meaning is defined by the owner of
>> the FQDN)?
>
>
> IMO the issue isn't *if* we require it. The issue is how it is represented
> if it is present.
>
> IOW, I am ok with allowing both:
>
>  ...:label@FQDN:...
> and
>  ...:FQDN:...
>
>
>> (2) Suggested syntaxes (omitting any date specification):
>>
>>      ...:label@FQDN:...
>>
>>      ...:FQDN:label:...
>
>
> The issue I have with the latter syntax is:
>
> the FQDN:label syntax is very similar to label:label. It implies that you
> can drop the label while looking for a match. That is OK if FQDN is itself
> intended to have meaning without a subsequent label.
>
> With the @ syntax, it is clear (I hope) that label@FQDN is a single element
> that must be dropped as a whole.
>
> Either way, you can then have subsequent labels, that will be in the scope
> of this one.
>
> So maybe you can consider the @ syntax to be an extension to your : syntax,
> rather than an alternative.
>
>         Thanks,
>         Paul
>
>
>> (Of course there are other possibilities.)
>>
>> Dale
>> _______________________________________________
>> salud mailing list
>> salud@ietf.org
>> https://www.ietf.org/mailman/listinfo/salud
>>
>
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From worley@shell01.TheWorld.com  Fri Jan 25 14:35:09 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D5021F8438 for ; Fri, 25 Jan 2013 14:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.83
X-Spam-Level: 
X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-1.150,  BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i49J9oWaMY69 for ; Fri, 25 Jan 2013 14:35:08 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAEE21F8428 for ; Fri, 25 Jan 2013 14:35:04 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0PMYcA6001962 for ; Fri, 25 Jan 2013 17:34:40 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0PMYcBb514139 for ; Fri, 25 Jan 2013 17:34:38 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0PMYc3m523413; Fri, 25 Jan 2013 17:34:38 -0500 (EST)
Date: Fri, 25 Jan 2013 17:34:38 -0500 (EST)
Message-Id: <201301252234.r0PMYc3m523413@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <50F58261.9050302@alum.mit.edu> (pkyzivat@alum.mit.edu)
References:  <50EF163C.5020103@alum.mit.edu>  <50F041B3.2080004@alum.mit.edu>  <201301150309.r0F39ohG5179371@shell01.TheWorld.com> <50F58261.9050302@alum.mit.edu>
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 22:35:09 -0000

[as chair]

Based on these e-mails:
http://www.ietf.org/mail-archive/web/salud/current/msg00312.html
http://www.ietf.org/mail-archive/web/salud/current/msg00310.html
http://www.ietf.org/mail-archive/web/salud/current/msg00305.html
it appears that we are moving toward agreement on this proposal:

    private-part    = label "@" dns-name ["(" date ")"]
       [the use of "@" is not completely agreed to yet]
    dns-name        = label "." label *[ "." label ]
    date = [CC] YY ["-" MM ["-" DD] ]
    label           = let-dig [ *let-dig-hyp let-dig ]
    let-dig-hyp     = let-dig / "-"
    let-dig         = ALPHA / DIGIT
    YY = CC
    MM = CC
    DD = CC
    CC = DIGIT DIGIT
    ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
    DIGIT           = %x30-39 ; 0-9
    DIGIT-1-9       = %x31-39 ; 1-9
    DIGIT-2-9       = %x32-39 ; 2-9

    Following rules apply to the  usage
    a) A domain is permited to use any  within its domain name
    ownership time period.
    b) Only the first owner of a DNS name is allowed to leave out the
     or to use s prior to its ownership.
    c) If the  is absent, it defaults to 20130101.
                                               [note change from 20000101]
    d) If 
 or  are absent each default to 01
    e) If  is absent it defaults to 20
    f) Comparison is based on the full  after defaults have been
    filled in.

With reference to the list of choices in
http://trac.tools.ietf.org/wg/salud/trac/ticket/1
this proposal for dates is:

    (1b) Use date (rather than sequence number) to extend domain names

    (2b) Use "(...)" as a separator, i.e., "example.com(2013-01-25)".

    (3a1) Missing date is equivalent to the date specified in (6b), 2013-01-01.

    (4c) Century defaults to "20".

    (5b) MM and DD are separated by "-".

    (6b) Default date is 2013-01-01.

    (7a) First owner of domain name can use dates before its ownership.
	 (I assume that this means, "No owner from 2013-01-10 until the
	 current owner acquired domain name.")

Are we all in favor of this set of choices?

Dale

From worley@shell01.TheWorld.com  Fri Jan 25 14:35:09 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2990B21F843D for ; Fri, 25 Jan 2013 14:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level: 
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, SARE_URI_EQUALS=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HADu-ZsFVynY for ; Fri, 25 Jan 2013 14:35:08 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2D74721F8203 for ; Fri, 25 Jan 2013 14:35:04 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0PMY7ll018276 for ; Fri, 25 Jan 2013 17:34:09 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0PMY76S510177 for ; Fri, 25 Jan 2013 17:34:07 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0PMY7TY522607; Fri, 25 Jan 2013 17:34:07 -0500 (EST)
Date: Fri, 25 Jan 2013 17:34:07 -0500 (EST)
Message-Id: <201301252234.r0PMY7TY522607@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to:  (laura.liess.dt@googlemail.com)
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>  <201301161956.r0GJuOWG4887702@shell01.TheWorld.com> <50F71C05.3080008@alum.mit.edu> 
Subject: Re: [salud]  separator
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 22:35:09 -0000

[as an individual]

Regarding how we specify private extensions, which is the syntax of
:

I believe that we are all agreed that within a URN, an FQDN
() can be specified, and that can be followed by one or more
s, all of which are interpreted based on some definition made
by the owner of the FQDN.

I believe that we are all agreed that if URN specifies an FQDN
(), then there must be at least one following label, i.e.,
that a URN can't simply say "example.com's version of
urn:alert:service:call-waiting" (which would be
urn:alert:service:call-waiting:example.com"), it has to include some
specification of a particular modification
("urn:alert:service:call-waiting:example.com:xyz").

Two syntaxes have been proposed:

    private-part    = label "@" dns-name ["(" date ")"]
    Example: urn:alert:service:call-waiting:xyz@example.com

    private-part    = dns-name ["(" date ")"] ":" label
    Example: urn:alert:service:call-waiting:example.com:xyz

Desirable features for the syntax:

1. Expresses the hierarchical relationship of the labels, that is, for
   each label, it is visually clear which elements provide the context
   within which this label must be interpreted.

2. Expresses what the components are that are to be deleted during the
   loop in the resolution process.

Let us consider a specialization of urn:alert:service:call-waiting,
defined by example.com, which has a level of subdivision, so its
labels are (primary) "abc" and (secondary) "def".  The two syntax
proposals above would express this as:

    urn:alert:service:call-waiting:abc@example.com:def

    urn:alert:service:call-waiting:example.com:abc:def

What I notice is that the first example does not conform well to
desideratum 1, because "abc" is to the left of "example.com", whereas
the general hierarchical structure is that the primary categories are
to the left and the secondary categories are to the right.

("desideratum" = "something that is wished for, or considered
desirable"
http://en.wiktionary.org/wiki/desideratum#English
It is not a requirement because we do not *need* this to be true, but
it is desirable for it to be true.)

The second example does not conform to desideratum 2, because the ":"
between "example.com" and "abc" suggests that "abc" can be removed
from the URN without removing "example.com".

I think we need a different syntax, one that places "example.com"
before "abc", but does not use ":" as a separator.  One possibility is

    urn:alert:service:call-waiting:example.com@abc:def

but that conflicts with the normal uses of "@", where the hostname
always goes after "@".

Based on RFC 3986, the URI syntax, I believe that we can use the
following characters freely in alert-info URNs:

   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

   pct-encoded   = "%" HEXDIG HEXDIG

   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

Since ALPHA, DIGIT, ".", and "-" are allowed in , we don't
want to use them as delimiters.

Perhaps we could use this syntax:

    urn:alert:service:call-waiting:example.com=abc:def

or even use the old UUCP addressing syntax:

    urn:alert:service:call-waiting:example.com!abc:def

I suppose we could use parentheses, if we weren't using them for
dates:

    urn:alert:service:call-waiting:(example.com)abc:def

Dale

From worley@shell01.TheWorld.com  Fri Jan 25 14:49:05 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1476121F86A5 for ; Fri, 25 Jan 2013 14:49:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level: 
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjspwtVimAeX for ; Fri, 25 Jan 2013 14:49:04 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8F04F21F842A for ; Fri, 25 Jan 2013 14:49:04 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0PMmh8D028492 for ; Fri, 25 Jan 2013 17:48:45 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0PMmh6q521889 for ; Fri, 25 Jan 2013 17:48:43 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0PMmgUA527089; Fri, 25 Jan 2013 17:48:42 -0500 (EST)
Date: Fri, 25 Jan 2013 17:48:42 -0500 (EST)
Message-Id: <201301252248.r0PMmgUA527089@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to:  (laura.liess.dt@googlemail.com)
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>  <201301161956.r0GJuOWG4887702@shell01.TheWorld.com> <50F71C05.3080008@alum.mit.edu> 
Subject: Re: [salud]  separator
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Jan 2013 22:49:05 -0000

[as an individual]

> From: Laura Liess 
> 
> By the way, do we need to add to Section 6.2.1
> urn:alert:service:recall or to say something about a default value?

There is a similar question regarding urn:alert:locale:country.  But I
don't think that we need to assign a meaning to these URNs.  If a UA
is processing a list of URNs, and it removes a component for a URN and
that results in a URN that is undefined (and thus the UA knows now
meaning for it), the rules specify that it must remove another
component.  In these cases, that results in urn:alert:service or
urn:alert:locale.  Those URNs have no  and are thus
discarded.

Dale

From pkyzivat@alum.mit.edu  Fri Jan 25 16:08:21 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DBE21F8844 for ; Fri, 25 Jan 2013 16:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.396
X-Spam-Level: 
X-Spam-Status: No, score=0.396 tagged_above=-999 required=5 tests=[AWL=-0.833,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1, SARE_URI_EQUALS=1.666]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9eR9mBWN3Gr for ; Fri, 25 Jan 2013 16:08:20 -0800 (PST)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFEE21F87F7 for ; Fri, 25 Jan 2013 16:08:16 -0800 (PST)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta02.westchester.pa.mail.comcast.net with comcast id sCMu1k0051uE5Es51Q8Gde; Sat, 26 Jan 2013 00:08:16 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id sQ8G1k00L3ZTu2S3cQ8GMq; Sat, 26 Jan 2013 00:08:16 +0000
Message-ID: <51031E6F.8020108@alum.mit.edu>
Date: Fri, 25 Jan 2013 19:08:15 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: salud@ietf.org
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>  <201301161956.r0GJuOWG4887702@shell01.TheWorld.com> <50F71C05.3080008@alum.mit.edu>  <201301252234.r0PMY7TY522607@shell01.TheWorld.com>
In-Reply-To: <201301252234.r0PMY7TY522607@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359158896; bh=b7PPxzj7h/OA5TE7yuSNrVpHQVEOEEr3QvLeB9EA4t8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KzQbUIv0MFPGgctbhCm3EwcAeCdd2oMWcUS2oH+FPii/wMYh/0WmYK9wLhNmOqe96 /fHkDuITCaRzqzX1/vl0/TKSplE9KEt1qF6hpRQLkrVpWjGoWe4lVtOZ5krcQDlcYh oiG12bCFYaLxN8jrmxynO3/oE0x6atARbLFnLehpkQ6N6omKEY9Ej9tOUkfpSEej3K ITgJOP8AxXXKWaZlOMwtBo/mLnrJNPVJfyuKefwihIsFypMrRmNr+kgJz6pe5f8G8I JqQpkpI2SmRkkhCNFXVA/FJkTK5NhBCeA2j0dKo2/KYcVGeZWSo4AHdhLzFOJiKggN gyVtMWKWA+phw==
Subject: Re: [salud]  separator
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Jan 2013 00:08:21 -0000

Dale,

I agree with most of your analysis, but not the conclusion. More inline.

On 1/25/13 5:34 PM, Dale R. Worley wrote:
> [as an individual]
>
> Regarding how we specify private extensions, which is the syntax of
> :
>
> I believe that we are all agreed that within a URN, an FQDN
> () can be specified, and that can be followed by one or more
> s, all of which are interpreted based on some definition made
> by the owner of the FQDN.
>
> I believe that we are all agreed that if URN specifies an FQDN
> (), then there must be at least one following label, i.e.,
> that a URN can't simply say "example.com's version of
> urn:alert:service:call-waiting" (which would be
> urn:alert:service:call-waiting:example.com"), it has to include some
> specification of a particular modification
> ("urn:alert:service:call-waiting:example.com:xyz").
>
> Two syntaxes have been proposed:
>
>      private-part    = label "@" dns-name ["(" date ")"]
>      Example: urn:alert:service:call-waiting:xyz@example.com
>
>      private-part    = dns-name ["(" date ")"] ":" label
>      Example: urn:alert:service:call-waiting:example.com:xyz
>
> Desirable features for the syntax:
>
> 1. Expresses the hierarchical relationship of the labels, that is, for
>     each label, it is visually clear which elements provide the context
>     within which this label must be interpreted.
>
> 2. Expresses what the components are that are to be deleted during the
>     loop in the resolution process.
>
> Let us consider a specialization of urn:alert:service:call-waiting,
> defined by example.com, which has a level of subdivision, so its
> labels are (primary) "abc" and (secondary) "def".  The two syntax
> proposals above would express this as:
>
>      urn:alert:service:call-waiting:abc@example.com:def
>
>      urn:alert:service:call-waiting:example.com:abc:def
>
> What I notice is that the first example does not conform well to
> desideratum 1, because "abc" is to the left of "example.com", whereas
> the general hierarchical structure is that the primary categories are
> to the left and the secondary categories are to the right.

This component has a familiar look to it, and so the "left of the 
domain" is comfortable. I am just not bothered by this. I view 
abc@example.com as a *single* component - the label isn't optional. It 
satisfies (1) in that xyz follows it.

> ("desideratum" = "something that is wished for, or considered
> desirable"
> http://en.wiktionary.org/wiki/desideratum#English
> It is not a requirement because we do not *need* this to be true, but
> it is desirable for it to be true.)
>
> The second example does not conform to desideratum 2, because the ":"
> between "example.com" and "abc" suggests that "abc" can be removed
> from the URN without removing "example.com".
>
> I think we need a different syntax, one that places "example.com"
> before "abc", but does not use ":" as a separator.  One possibility is
>
>      urn:alert:service:call-waiting:example.com@abc:def
>
> but that conflicts with the normal uses of "@", where the hostname
> always goes after "@".
>
> Based on RFC 3986, the URI syntax, I believe that we can use the
> following characters freely in alert-info URNs:
>
>     pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
>
>     pct-encoded   = "%" HEXDIG HEXDIG
>
>     unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
>
>     sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
>                   / "*" / "+" / "," / ";" / "="
>
> Since ALPHA, DIGIT, ".", and "-" are allowed in , we don't
> want to use them as delimiters.
>
> Perhaps we could use this syntax:
>
>      urn:alert:service:call-waiting:example.com=abc:def
>
> or even use the old UUCP addressing syntax:
>
>      urn:alert:service:call-waiting:example.com!abc:def
>
> I suppose we could use parentheses, if we weren't using them for
> dates:
>
>      urn:alert:service:call-waiting:(example.com)abc:def

I don't find any of these to be as pleasant as the @ notation.

But of course this is all in the realm of esthetics, so it's not 
surprising that there are multiple preferences.

	Thanks,
	Paul


From pkyzivat@alum.mit.edu  Mon Jan 28 06:25:23 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE9621F8871 for ; Mon, 28 Jan 2013 06:25:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.88
X-Spam-Level: 
X-Spam-Status: No, score=0.88 tagged_above=-999 required=5 tests=[AWL=-0.983,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  MANGLED_TOOL=2.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kys9FSyHVaCe for ; Mon, 28 Jan 2013 06:25:22 -0800 (PST)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id A2F1A21F88A1 for ; Mon, 28 Jan 2013 06:25:22 -0800 (PST)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta02.westchester.pa.mail.comcast.net with comcast id tPbx1k0011uE5Es51SRMC0; Mon, 28 Jan 2013 14:25:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id tSRL1k00g3ZTu2S3cSRMrZ; Mon, 28 Jan 2013 14:25:21 +0000
Message-ID: <51068A4F.1040801@alum.mit.edu>
Date: Mon, 28 Jan 2013 09:25:19 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: salud@ietf.org
References:  <50EF163C.5020103@alum.mit.edu>  <50F041B3.2080004@alum.mit.edu>  <201301150309.r0F39ohG5179371@shell01.TheWorld.com> <50F58261.9050302@alum.mit.edu> <201301252234.r0PMYc3m523413@shell01.TheWorld.com>
In-Reply-To: <201301252234.r0PMYc3m523413@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359383121; bh=3LSpFeYV5Fh8cWWe/Mxgyd+tjbmDkqwZi6bpJFidKzI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Tg5HavrbnlzW8qxjxhEHhWmfOUNYNlpJ3wavI1+sRI3uBpebF06ZdsNc0Mg8p6zWk ujcj5zH39QHhzHrB1XEsn5Yfr9uVjAGknKaE/+TRPnVAP0/NpP6izknBUhkUKqP8Pv dn9hahLLWQgafo/7StMCHNWPOeF8Eap/xgkCZOyLXUs5SC7eR+S2oOLFY2TIwpunKh lzak5gOE6d83WbeFg9rrsjW5exFxQ/tDHZorr/wjoHNi+m4b2TWBODX10O6OM3KXa/ r8Chv2mMnM39AyLmQfX7clUmozSGNoP8T5wB57PNoRbJd7y32GUOJ+x5+1yYYdcDyb rwIRVAnqCk5Qg==
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 14:25:23 -0000

Dale,

I'm generally in agreement.

As I said somewhere recently, I have realized that saying what dates 
someone is allowed to use is probably wrong, since the uses we are 
describing are *references*, not *definitions*.

So this is really more about what the reference *means*.

It also suggests to me that we let the date default to *now*.

This might require some contortions in how we describe what this means 
as a URN. Basically it means that the recipient who is interpreting the 
URN have alerts with IDs that match a range of dates.

So, *in principle* I could have one alert defined to match 
abc@example.com(20112-01-01)...abc@example.com(2012-12-31),
and another for (abc@example.com(2013-01-01)... when the ownership of 
example.com changed from somebody I had a special relationship with to 
one when I no longer did.

	Thanks,
	Paul

On 1/25/13 5:34 PM, Dale R. Worley wrote:
> [as chair]
>
> Based on these e-mails:
> http://www.ietf.org/mail-archive/web/salud/current/msg00312.html
> http://www.ietf.org/mail-archive/web/salud/current/msg00310.html
> http://www.ietf.org/mail-archive/web/salud/current/msg00305.html
> it appears that we are moving toward agreement on this proposal:
>
>      private-part    = label "@" dns-name ["(" date ")"]
>         [the use of "@" is not completely agreed to yet]
>      dns-name        = label "." label *[ "." label ]
>      date = [CC] YY ["-" MM ["-" DD] ]
>      label           = let-dig [ *let-dig-hyp let-dig ]
>      let-dig-hyp     = let-dig / "-"
>      let-dig         = ALPHA / DIGIT
>      YY = CC
>      MM = CC
>      DD = CC
>      CC = DIGIT DIGIT
>      ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
>      DIGIT           = %x30-39 ; 0-9
>      DIGIT-1-9       = %x31-39 ; 1-9
>      DIGIT-2-9       = %x32-39 ; 2-9
>
>      Following rules apply to the  usage
>      a) A domain is permited to use any  within its domain name
>      ownership time period.
>      b) Only the first owner of a DNS name is allowed to leave out the
>       or to use s prior to its ownership.
>      c) If the  is absent, it defaults to 20130101.
>                                                 [note change from 20000101]
>      d) If 
 or  are absent each default to 01
>      e) If  is absent it defaults to 20
>      f) Comparison is based on the full  after defaults have been
>      filled in.
>
> With reference to the list of choices in
> http://trac.tools.ietf.org/wg/salud/trac/ticket/1
> this proposal for dates is:
>
>      (1b) Use date (rather than sequence number) to extend domain names
>
>      (2b) Use "(...)" as a separator, i.e., "example.com(2013-01-25)".
>
>      (3a1) Missing date is equivalent to the date specified in (6b), 2013-01-01.
>
>      (4c) Century defaults to "20".
>
>      (5b) MM and DD are separated by "-".
>
>      (6b) Default date is 2013-01-01.
>
>      (7a) First owner of domain name can use dates before its ownership.
> 	 (I assume that this means, "No owner from 2013-01-10 until the
> 	 current owner acquired domain name.")
>
> Are we all in favor of this set of choices?
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>


From worley@shell01.TheWorld.com  Mon Jan 28 14:14:03 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AF821F8634 for ; Mon, 28 Jan 2013 14:14:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.390,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUeyfuYBlQcy for ; Mon, 28 Jan 2013 14:14:03 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id E48E721F8630 for ; Mon, 28 Jan 2013 14:14:02 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0SMDuP1006309 for ; Mon, 28 Jan 2013 17:13:58 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0SMDs2i745033 for ; Mon, 28 Jan 2013 17:13:56 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0SMDr4d741030; Mon, 28 Jan 2013 17:13:53 -0500 (EST)
Date: Mon, 28 Jan 2013 17:13:53 -0500 (EST)
Message-Id: <201301282213.r0SMDr4d741030@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <51068A4F.1040801@alum.mit.edu> (pkyzivat@alum.mit.edu)
References:  <50EF163C.5020103@alum.mit.edu>  <50F041B3.2080004@alum.mit.edu>  <201301150309.r0F39ohG5179371@shell01.TheWorld.com> <50F58261.9050302@alum.mit.edu> <201301252234.r0PMYc3m523413@shell01.TheWorld.com> <51068A4F.1040801@alum.mit.edu>
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 22:14:03 -0000

[as an individual]

> From: Paul Kyzivat 
> 
> I'm generally in agreement.
> 
> As I said somewhere recently, I have realized that saying what dates 
> someone is allowed to use is probably wrong, since the uses we are 
> describing are *references*, not *definitions*.
> 
> So this is really more about what the reference *means*.
> 
> It also suggests to me that we let the date default to *now*.
> 
> This might require some contortions in how we describe what this means 
> as a URN. Basically it means that the recipient who is interpreting the 
> URN have alerts with IDs that match a range of dates.
> 
> So, *in principle* I could have one alert defined to match 
> abc@example.com(20112-01-01)...abc@example.com(2012-12-31),
> and another for (abc@example.com(2013-01-01)... when the ownership of 
> example.com changed from somebody I had a special relationship with to 
> one when I no longer did.

I'm not sure that I understand you.

My understanding is:

,
, and
 are all different.

 is considered to be an abbreviation of
 (or which ever date is the
default).

The entity that owns "example.com" on 2012-01-01 is permitted to
define the meaning of .

The meaning of any URN (character string) is independent of the time
at which it is interpreted (excepting that undefined URNs can become
defined).

Dale

From worley@shell01.TheWorld.com  Mon Jan 28 14:15:07 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A54721F8634 for ; Mon, 28 Jan 2013 14:15:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.639
X-Spam-Level: 
X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.341,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlccbXfezkhx for ; Mon, 28 Jan 2013 14:15:06 -0800 (PST)
Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 95B1C21F8630 for ; Mon, 28 Jan 2013 14:15:06 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0SMEikX026960 for ; Mon, 28 Jan 2013 17:14:46 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0SMEiIn745412 for ; Mon, 28 Jan 2013 17:14:44 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0SMEia4746025; Mon, 28 Jan 2013 17:14:44 -0500 (EST)
Date: Mon, 28 Jan 2013 17:14:44 -0500 (EST)
Message-Id: <201301282214.r0SMEia4746025@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to: <51031E6F.8020108@alum.mit.edu> (pkyzivat@alum.mit.edu)
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>  <201301161956.r0GJuOWG4887702@shell01.TheWorld.com> <50F71C05.3080008@alum.mit.edu>  <201301252234.r0PMY7TY522607@shell01.TheWorld.com> <51031E6F.8020108@alum.mit.edu>
Subject: Re: [salud]  separator
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Jan 2013 22:15:07 -0000

[as an individual]

> From: Paul Kyzivat 
> 
> I don't find any of these to be as pleasant as the @ notation.
> 
> But of course this is all in the realm of esthetics, so it's not 
> surprising that there are multiple preferences.

I agree that this question is all a matter of esthetics.  Which do
other people prefer?

Dale

From pkyzivat@alum.mit.edu  Mon Jan 28 16:41:26 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496DD21E8049 for ; Mon, 28 Jan 2013 16:41:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.107
X-Spam-Level: 
X-Spam-Status: No, score=-0.107 tagged_above=-999 required=5 tests=[AWL=0.331,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE1+4RMblDyQ for ; Mon, 28 Jan 2013 16:41:25 -0800 (PST)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 35D1E21E8042 for ; Mon, 28 Jan 2013 16:41:24 -0800 (PST)
Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta02.westchester.pa.mail.comcast.net with comcast id tUFv1k00D0SCNGk51chPZK; Tue, 29 Jan 2013 00:41:23 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id tchP1k00B3ZTu2S3VchPA0; Tue, 29 Jan 2013 00:41:23 +0000
Message-ID: <51071AB2.6050204@alum.mit.edu>
Date: Mon, 28 Jan 2013 19:41:22 -0500
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: salud@ietf.org
References:  <50EF163C.5020103@alum.mit.edu>  <50F041B3.2080004@alum.mit.edu>  <201301150309.r0F39ohG5179371@shell01.TheWorld.com> <50F58261.9050302@alum.mit.edu> <201301252234.r0PMYc3m523413@shell01.TheWorld.com> <51068A4F.1040801@alum.mit.edu> <201301282213.r0SMDr4d741030@shell01.TheWorld.com>
In-Reply-To: <201301282213.r0SMDr4d741030@shell01.TheWorld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359420083; bh=yJePmRdmW0Iz1Fq3L7SWeFlrEpBufw4z4+IvpKPWITY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WTaV1n1NsPQG6VN6tUkUemKw9sB6LJaYoKYQhPXs0QXE4czaWr2TaX3lsO7qjwMJa nve35lWPQJslIsB1wfGTzO4WE2jPNuXEtul+Q3a5vMDijEMITv+q0Tl0TAldtB8Egs XgaIPzfPhamyfqJpTXS2G3P83xL0g/RGPUZiX9kIlssCMBk6HuRGNcOwf9IxSABGYV Nb0eWm6KTByPqrnMRiuOu5XY/y3nMdCAkgtwPwAr+hY5ZNVzEfhenQ5Tn4hzEjHivy Vy1rL0yl24a1cZha6dSjOwmqGf6fRcLrzlPqxP6299+B66w28WWrIbhqpFLz+6WXA2 IQmoguj7yfb7w==
Subject: Re: [salud]  format
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jan 2013 00:41:26 -0000

On 1/28/13 5:13 PM, Dale R. Worley wrote:
> [as an individual]
>
>> From: Paul Kyzivat 
>>
>> I'm generally in agreement.
>>
>> As I said somewhere recently, I have realized that saying what dates
>> someone is allowed to use is probably wrong, since the uses we are
>> describing are *references*, not *definitions*.
>>
>> So this is really more about what the reference *means*.
>>
>> It also suggests to me that we let the date default to *now*.
>>
>> This might require some contortions in how we describe what this means
>> as a URN. Basically it means that the recipient who is interpreting the
>> URN have alerts with IDs that match a range of dates.
>>
>> So, *in principle* I could have one alert defined to match
>> abc@example.com(20112-01-01)...abc@example.com(2012-12-31),
>> and another for (abc@example.com(2013-01-01)... when the ownership of
>> example.com changed from somebody I had a special relationship with to
>> one when I no longer did.
>
> I'm not sure that I understand you.
>
> My understanding is:
>
> ,
> , and
>  are all different.

Yes, they are all different URNs. But they could all be defined to have 
the same *meaning*.

>  is considered to be an abbreviation of
>  (or which ever date is the
> default).
>
> The entity that owns "example.com" on 2012-01-01 is permitted to
> define the meaning of .

That entity defines the meaning of the URN, but somebody else may be 
defining what alert to render for it. So if I am defining the alerts, I 
can *choose* to assign the same alert to a bunch of different URNs, and 
specifically to a bunch of alert URNs that differ only by the date.

In fact, I could assign the same alert to a *range* of dates. And if I 
*choose* to assign the same alert without regard to the date part of the 
label, that is also my right. This is *policy*, so I can do as I wish.

And if somebody built an implementation that supported such policies, so 
much the better.

> The meaning of any URN (character string) is independent of the time
> at which it is interpreted (excepting that undefined URNs can become
> defined).

Yes.

*Unless* we made the default for a missing date be the current day. In 
some ways that is appealing. But I think we would get a lot of grief 
from the URN police for it. So we probably don't want to do it.

	Thanks,
	Paul

From laura.liess.dt@googlemail.com  Tue Jan 29 07:16:52 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02F521F8860 for ; Tue, 29 Jan 2013 07:16:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0osJYwWKXu97 for ; Tue, 29 Jan 2013 07:16:50 -0800 (PST)
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 66EC821F87EE for ; Tue, 29 Jan 2013 07:16:49 -0800 (PST)
Received: by mail-lb0-f180.google.com with SMTP id q12so858050lbc.39 for ; Tue, 29 Jan 2013 07:16:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=5d19HxB70cPCqum6KqcvsxN/VH8pCJIhK5zoIel8Xg4=; b=qPTQpEEhrC5Ymscvks3MCrz/lBX7uNrRpKIQ43DPIVABEbIgBvxIVWnSiyuDqhGtOP Z09ur7V8PSK16791q/ky92ZxFRLWqFgXMFhqxVAPIIDt9BFNtZC/rV0JJQ27nYlt99GQ zQpe8silTNvAY/TEJiIITw7z3BQUmfa1eMGrVAJMD7ViryzuKpIuOltbmW8jOhijONNj aJ8SfIe/W8pImujGNDWzfULY3IyOqGgAAJFJON3Q4/7bwyTCydF0T28ZL8QyKyCc8JQU d7jw3Lw3ittq3tXH7LSP1PGqP0DDHPxW7/BwK0voAB9C+K9/3QjVkAe6ZF9sUeeYTRc5 QFlA==
MIME-Version: 1.0
X-Received: by 10.152.123.34 with SMTP id lx2mr1426530lab.52.1359472608216; Tue, 29 Jan 2013 07:16:48 -0800 (PST)
Received: by 10.114.95.99 with HTTP; Tue, 29 Jan 2013 07:16:48 -0800 (PST)
In-Reply-To: <201301282214.r0SMEia4746025@shell01.TheWorld.com>
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>  <201301161956.r0GJuOWG4887702@shell01.TheWorld.com> <50F71C05.3080008@alum.mit.edu>  <201301252234.r0PMY7TY522607@shell01.TheWorld.com> <51031E6F.8020108@alum.mit.edu> <201301282214.r0SMEia4746025@shell01.TheWorld.com>
Date: Tue, 29 Jan 2013 16:16:48 +0100
Message-ID: 
From: Laura Liess 
To: salud@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [salud]  separator
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jan 2013 15:16:52 -0000

My personal preference is @.  I agree with Paul's view about (1) and I
think it is easy to understand and to keep in mind.

Thank you
Laura


2013/1/28 Dale R. Worley :
> [as an individual]
>
>> From: Paul Kyzivat 
>>
>> I don't find any of these to be as pleasant as the @ notation.
>>
>> But of course this is all in the realm of esthetics, so it's not
>> surprising that there are multiple preferences.
>
> I agree that this question is all a matter of esthetics.  Which do
> other people prefer?
>
> Dale
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud

From worley@shell01.TheWorld.com  Tue Jan 29 13:03:23 2013
Return-Path: 
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD77521F8820 for ; Tue, 29 Jan 2013 13:03:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.303,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfY7TeMpuigv for ; Tue, 29 Jan 2013 13:03:23 -0800 (PST)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 42E4121F880B for ; Tue, 29 Jan 2013 13:03:22 -0800 (PST)
Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r0TL2Z3o016246 for ; Tue, 29 Jan 2013 16:02:37 -0500
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r0TL2Y9g797216 for ; Tue, 29 Jan 2013 16:02:34 -0500 (EST)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r0TL2YhO789456; Tue, 29 Jan 2013 16:02:34 -0500 (EST)
Date: Tue, 29 Jan 2013 16:02:34 -0500 (EST)
Message-Id: <201301292102.r0TL2YhO789456@shell01.TheWorld.com>
From: worley@ariadne.com (Dale R. Worley)
Sender: worley@ariadne.com (Dale R. Worley)
To: salud@ietf.org
In-reply-to:  (laura.liess.dt@googlemail.com)
References: <059.66bff8c1bba57fcb82dda7303599e980@trac.tools.ietf.org> <201301150248.r0F2mnYI5181179@shell01.TheWorld.com>  <201301161956.r0GJuOWG4887702@shell01.TheWorld.com> <50F71C05.3080008@alum.mit.edu>  <201301252234.r0PMY7TY522607@shell01.TheWorld.com> <51031E6F.8020108@alum.mit.edu> <201301282214.r0SMEia4746025@shell01.TheWorld.com> 
Subject: Re: [salud]  separator
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jan 2013 21:03:24 -0000

[as an individual]

> From: Laura Liess 
> 
> My personal preference is @.  I agree with Paul's view about (1) and I
> think it is easy to understand and to keep in mind.

I certainly don't feel strongly enough about the matter to stand in
the way of a consensus.  So let us agree on the
...:label@FQDN:... syntax.

Dale