From daemon@optimus.ietf.org Wed May 22 04:56:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17928 for ; Wed, 22 May 2002 04:56:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA07997 for enum-archive@odin.ietf.org; Wed, 22 May 2002 04:56:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07504; Wed, 22 May 2002 04:43:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07424 for ; Wed, 22 May 2002 04:43:17 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17617 for ; Wed, 22 May 2002 04:42:32 -0400 (EDT) Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090173; Wed, 22 May 2002 09:41:49 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Wed, 22 May 2002 09:41:35 +0100 To: enum@ietf.org From: Lawrence Conroy Cc: jon.peterson@neustar.biz, Rudi Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] enumservice names Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Folks, This is a minor point, but from discussions we've had I wonder if the name of each enumservice should be DIFFERENT from the URI schemes they may use. For example, writing about the 'tel' enumservice is confusing, as one also needs to write about the "tel:" URI scheme (So it's not just confusing to read :). Likewise, does one talk about the 'sip' enumservice or the "sip:" URI scheme? Thus I suggest that we re-name the enumservices. BTW, as 'sip' is, AFAICT, a "Service Resolution Service", why not call the enumservice just that (well, 'srs', anyway)? Comments? all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 22 10:16:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03732 for ; Wed, 22 May 2002 10:16:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27314 for enum-archive@odin.ietf.org; Wed, 22 May 2002 10:17:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA26858; Wed, 22 May 2002 10:07:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21982 for ; Wed, 22 May 2002 09:07:47 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29900 for ; Wed, 22 May 2002 09:07:28 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11568 for ; Wed, 22 May 2002 09:06:04 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11557 for ; Wed, 22 May 2002 09:06:04 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20191.C696923C" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Enum] enumservice names Date: Wed, 22 May 2002 07:08:33 -0600 Message-ID: Thread-Topic: [Enum] enumservice names Thread-Index: AcIBeAeIlrO+lgApTCy3PDX1gMQ6gAAFf0oA From: "Zmolek, Andrew (Andrew)" To: "=SMTP:lwc@roke.co.uk" <'=SMTP:lwc@roke.co.uk'>, "=SMTP:enum@ietf.org" <'=SMTP:enum@ietf.org'> Cc: "=SMTP:jon.peterson@neustar.biz" <'=SMTP:jon.peterson@neustar.biz'>, "=SMTP:Rudolf.Brandner@icn.siemens.de" <'=SMTP:Rudolf.Brandner@icn.siemens.de'> Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C20191.C696923C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Wasn't the consensus from IETF 53 that in fact the enumservice name = SHOULD be distinct from the protocol used in the URI scheme? The idea = being that if the enumservice and protocol are always the same, there = isn't much point in having the enumservice to begin with. The trick seems to be just what deciding what level of granularity or = abstraction is most appropriate for what makes up an enumservice. There = have been attempts do divide this up by media (voice/im/video), by = signaling protocol (sip, etc already captured in the URI), by capability = profile (vpim/fax classes/transcoding), and by intent (complete a class = of call or communication, find the right place to deposit a message, or = find a service resolution service to authenticate you and expose a = current snapshot set of options based on rules and presence data). My own bias is that I would like most to be able to do with the = enumservice is distinguish between a URI that can be used to complete a = call/transaction/session versus a URI that can iterate one step further = into service resolution by giving me a list of options that I can select = from or present back to the end user or application to select from. If = that distinction can be made just by looking at the URI itself, then = that's cool. But using SIP as an example, I have no good way (yet) of = doing this, except by separating the 'srs' enumservice from the 'sip' or = 'voice' or whatever the alternative is that we choose. I suspect there are similar arguments to be made for other enumservice = "schemas" and am surprised we have not had more debate on this topic = since the meeting. I do think there is general agreement that whatever = the schema, the number of enumservices should be kept as small as = possible so that enum does not become a repository for detailed = capability information. On an unrelated topic, am I remembering right that an update to the new = bis with a finalized "template" was going to be forthcoming so we could = update our enumservice drafts? Did I just miss this or is this still in = the queue? --Andy Zmolek=20 Technology & Standards Engineer=20 CTO Standards=20 Avaya Inc.=20 zmolek@avaya.com=20 +1 720 444 4001=20 sip:zmolek@avaya.com > -----Original Message----- > From: Lawrence Conroy [mailto:lwc@roke.co.uk] > Sent: Wednesday, May 22, 2002 2:42 AM > To: enum@ietf.org > Cc: jon.peterson@neustar.biz; Rudi > Subject: [Enum] enumservice names >=20 >=20 > Hi Folks, > This is a minor point, but from discussions we've had > I wonder if the name of each enumservice should be DIFFERENT > from the URI schemes they may use. >=20 > For example, writing about the 'tel' enumservice is > confusing, as one also needs to write about the "tel:" > URI scheme (So it's not just confusing to read :). >=20 > Likewise, does one talk about the 'sip' enumservice or > the "sip:" URI scheme? >=20 > Thus I suggest that we re-name the enumservices. >=20 > BTW, as 'sip' is, AFAICT, a "Service Resolution Service", > why not call the enumservice just that (well, 'srs', anyway)? >=20 > Comments? >=20 > all the best, > Lawrence > --=20 > lwc@roke.co.uk: +44 1794 833666::: >=20 > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum >=20 ------_=_NextPart_001_01C20191.C696923C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Enum] enumservice names

Wasn't the consensus from IETF 53 that in fact the = enumservice name SHOULD be distinct from the protocol used in the URI = scheme? The idea being that if the enumservice and protocol are always = the same, there isn't much point in having the enumservice to begin = with.

The trick seems to be just what deciding what level of = granularity or abstraction is most appropriate for what makes up an = enumservice. There have been attempts do divide this up by media = (voice/im/video), by signaling protocol (sip, etc already captured in = the URI), by capability profile (vpim/fax classes/transcoding), and by = intent (complete a class of call or communication, find the right place = to deposit a message, or find a service resolution service to = authenticate you and expose a current snapshot set of options based on = rules and presence data).

My own bias is that I would like most to be able to do = with the enumservice is distinguish between a URI that can be used to = complete a call/transaction/session versus a URI that can iterate one = step further into service resolution by giving me a list of options that = I can select from or present back to the end user or application to = select from. If that distinction can be made just by looking at the URI = itself, then that's cool. But using SIP as an example, I have no good = way (yet) of doing this, except by separating the 'srs' enumservice from = the 'sip' or 'voice' or whatever the alternative is that we = choose.

I suspect there are similar arguments to be made for = other enumservice "schemas" and am surprised we have not had = more debate on this topic since the meeting. I do think there is general = agreement that whatever the schema, the number of enumservices should be = kept as small as possible so that enum does not become a repository for = detailed capability information.

On an unrelated topic, am I remembering right that an = update to the new bis with a finalized "template" was going to = be forthcoming so we could update our enumservice drafts? Did I just = miss this or is this still in the queue?

--Andy Zmolek
    Technology & Standards = Engineer
      CTO Standards
        Avaya Inc. =

          &nbs= p; zmolek@avaya.com
          &nbs= p;   +1 720 444 4001
          &nbs= p;     sip:zmolek@avaya.com




> -----Original Message-----
> From: Lawrence Conroy [mailto:lwc@roke.co.uk]
> Sent: Wednesday, May 22, 2002 2:42 AM
> To: enum@ietf.org
> Cc: jon.peterson@neustar.biz; Rudi
> Subject: [Enum] enumservice names
>
>
> Hi Folks,
>    This is a minor point, but = from discussions we've had
> I wonder if the name of each enumservice should = be DIFFERENT
> from the URI schemes they may use.
>
> For example, writing about the 'tel' enumservice = is
> confusing, as one also needs to write about the = "tel:"
> URI scheme (So it's not just confusing to read = :).
>
> Likewise, does one talk about the 'sip' = enumservice or
> the "sip:" URI scheme?
>
> Thus I suggest that we re-name the = enumservices.
>
> BTW, as 'sip' is, AFAICT, a "Service = Resolution Service",
> why not call the enumservice just that (well, = 'srs', anyway)?
>
> Comments?
>
> all the best,
>     Lawrence
> --
> lwc@roke.co.uk: +44 1794 833666::<my = opinions>:
>
> = _______________________________________________
> enum mailing list
> enum@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/enum
>

------_=_NextPart_001_01C20191.C696923C-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 22 10:23:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04143 for ; Wed, 22 May 2002 10:23:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA27686 for enum-archive@odin.ietf.org; Wed, 22 May 2002 10:23:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27200; Wed, 22 May 2002 10:15:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27173 for ; Wed, 22 May 2002 10:15:09 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03668 for ; Wed, 22 May 2002 10:14:49 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g4MEDOV3028283; Wed, 22 May 2002 10:13:24 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g4MEDMJT028282; Wed, 22 May 2002 10:13:22 -0400 (EDT) Date: Wed, 22 May 2002 10:13:22 -0400 From: Michael Mealling To: Lawrence Conroy Cc: enum@ietf.org, jon.peterson@neustar.biz, Rudi Subject: Re: [Enum] enumservice names Message-ID: <20020522101322.Z21856@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Wed, May 22, 2002 at 09:41:35AM +0100, Lawrence Conroy wrote: > Hi Folks, > This is a minor point, but from discussions we've had > I wonder if the name of each enumservice should be DIFFERENT > from the URI schemes they may use. > > For example, writing about the 'tel' enumservice is > confusing, as one also needs to write about the "tel:" > URI scheme (So it's not just confusing to read :). > > Likewise, does one talk about the 'sip' enumservice or > the "sip:" URI scheme? > > Thus I suggest that we re-name the enumservices. > > BTW, as 'sip' is, AFAICT, a "Service Resolution Service", > why not call the enumservice just that (well, 'srs', anyway)? > > Comments? That was always my intent just to keep myself straight. The SIP examples were the exception and I would be happy with SRS instead of SIP to make it clear... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 22 11:22:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09494 for ; Wed, 22 May 2002 11:22:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01492 for enum-archive@odin.ietf.org; Wed, 22 May 2002 11:22:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00948; Wed, 22 May 2002 11:12:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00917 for ; Wed, 22 May 2002 11:12:46 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07977 for ; Wed, 22 May 2002 11:12:26 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4MFBXoh003266; Wed, 22 May 2002 17:11:37 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 22 May 2002 17:11:47 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 22 May 2002 17:11:46 +0200 Date: Wed, 22 May 2002 17:05:22 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Zmolek, Andrew (Andrew)" cc: enum@ietf.org Subject: RE: [Enum] enumservice names Message-ID: <48622267.1022087122@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 22 May 2002 15:11:47.0684 (UTC) FILETIME=[FDF55A40:01C201A2] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-22 07.08 -0600 "Zmolek, Andrew (Andrew)" wrote: > Wasn't the consensus from IETF 53 that in fact the enumservice name > SHOULD be distinct from the protocol used in the URI scheme? The consensus, which I tried to explain in version 00 of 2916bis is that the URI scheme is one thing, and enumservice another. I.e. two different things. I.e. two different namespaces for them. That means that one enumservice can have the same name (consist of the same characters) as a URI scheme, without having anything to do with that scheme. So, my suggestion is that when one enumservice is specified that the name of that service is chosen wisely. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 22 12:05:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14968 for ; Wed, 22 May 2002 12:05:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA06236 for enum-archive@odin.ietf.org; Wed, 22 May 2002 12:06:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04177; Wed, 22 May 2002 11:57:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04146 for ; Wed, 22 May 2002 11:57:03 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14000 for ; Wed, 22 May 2002 11:56:41 -0400 (EDT) Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090179; Wed, 22 May 2002 16:56:35 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <48622267.1022087122@localhost> References: <48622267.1022087122@localhost> Date: Wed, 22 May 2002 16:56:23 +0100 To: Jon From: Lawrence Conroy Subject: RE: [Enum] enumservice names Cc: enum@ietf.org, zmolek@avaya.com, michael@neonym.net, paf@cisco.com Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA04147 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 5:05 pm +0200 22/5/02, Patrik Fältström wrote: >--On 2002-05-22 07.08 -0600 "Zmolek, Andrew (Andrew)" >wrote: > >> Wasn't the consensus from IETF 53 that in fact the enumservice name >> SHOULD be distinct from the protocol used in the URI scheme? > >The consensus, which I tried to explain in version 00 of 2916bis is that >the URI scheme is one thing, and enumservice another. I.e. two different >things. > >I.e. two different namespaces for them. > >That means that one enumservice can have the same name (consist of the same >characters) as a URI scheme, without having anything to do with that scheme. > >So, my suggestion is that when one enumservice is specified that the name >of that service is chosen wisely. > > paf > Hi folks, OK, to summarise - I am easily confused, and asked if we could ensure that the name used for an enumservice is always different from the name used for the URI schemes. Andrew and Michael think that ensuring that the string value used for an enumserevice should be different from the string value used for any of the URI schemes that can be used with that enumservice. Patrik highlights that (i) this is not NEEDED as they are separate namespaces and so do not clash, but (ii) the service name should be chosen wisely. Michael agrees that the 'sip' enumservice could be re-named 'srs'. So... Jon - is it OK with you to change the name of the 'sip' enumservice to 'srs'? I guess the ball is in our court - we will rename the 'tel' enumservice. I have a couple of ideas for names that might be appropriate - 'talk' or 'phone' spring to mind, as the erstwhile 'tel' enumservice is intended for use in interactive telephony calls; either seems appropriate. Do any folks have a preference? all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 22 12:31:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16809 for ; Wed, 22 May 2002 12:31:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA07853 for enum-archive@odin.ietf.org; Wed, 22 May 2002 12:31:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06985; Wed, 22 May 2002 12:22:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06956 for ; Wed, 22 May 2002 12:22:05 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16250 for ; Wed, 22 May 2002 12:21:45 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4MGLWc06300; Wed, 22 May 2002 12:21:32 -0400 Message-Id: <5.1.0.14.2.20020522122154.0270a520@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 22 May 2002 12:26:39 -0400 To: Lawrence Conroy , Jon From: Richard Shockey Subject: RE: [Enum] enumservice names Cc: enum@ietf.org, zmolek@avaya.com, michael@neonym.net, paf@cisco.com In-Reply-To: References: <48622267.1022087122@localhost> <48622267.1022087122@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A >Hi folks, > OK, to summarise - >I am easily confused, and asked if we could ensure that the name used for >an enumservice >is always different from the name used for the URI schemes. > >Andrew and Michael think that ensuring that the string value used for an >enumserevice >should be different from the string value used for any of the URI schemes >that can be used >with that enumservice. > >Patrik highlights that (i) this is not NEEDED as they are separate >namespaces and >so do not clash, but (ii) the service name should be chosen wisely. > >Michael agrees that the 'sip' enumservice could be re-named 'srs'. > >So... >Jon - is it OK with you to change the name of the 'sip' enumservice to 'srs'? yea right ... :-) >I guess the ball is in our court - we will rename the 'tel' enumservice. > >I have a couple of ideas for names that might be appropriate - 'talk' or >'phone' spring >to mind, as the erstwhile 'tel' enumservice is intended for use in >interactive telephony >calls; either seems appropriate. > >Do any folks have a preference? It could be foofoo for all it matters so long as the applicability statement in requesting the appropriate enumservice registration defines 1. the reason for the registration 2. defines the service 3. the URI scheme 4. anticipated context/behavior that the C/UA needs to understand. >all the best, > Lawrence >-- >lwc@roke.co.uk: +44 1794 833666::: > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 22 13:51:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21793 for ; Wed, 22 May 2002 13:51:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11373 for enum-archive@odin.ietf.org; Wed, 22 May 2002 13:51:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10828; Wed, 22 May 2002 13:43:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10802 for ; Wed, 22 May 2002 13:43:02 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21460 for ; Wed, 22 May 2002 13:42:41 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4MHfQqW020895; Wed, 22 May 2002 19:41:53 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 22 May 2002 19:42:16 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 22 May 2002 19:42:15 +0200 Date: Wed, 22 May 2002 19:41:50 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , Jon cc: enum@ietf.org, zmolek@avaya.com, michael@neonym.net Subject: RE: [Enum] enumservice names Message-ID: <49185515.1022096510@localhost> In-Reply-To: References: <48622267.1022087122@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 22 May 2002 17:42:16.0091 (UTC) FILETIME=[034EEEB0:01C201B8] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-22 16.56 +0100 Lawrence Conroy wrote: > Patrik highlights that (i) this is not NEEDED as they are separate > namespaces and so do not clash, but (ii) the service name should be > chosen wisely. Note, I am the editor of the document, and only explain what is in the document now. Please suggest changes if you want me to have some wording which makes this more clear. As non-editor, I think your suggestion on finding "non-confusing-names" (especially as I made the "mistake" of having a 1:1 mapping between scheme and ENUM service in RFC 2916) which means not use the same name as the scheme is a good idea. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 22 13:51:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21823 for ; Wed, 22 May 2002 13:51:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11387 for enum-archive@odin.ietf.org; Wed, 22 May 2002 13:51:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10868; Wed, 22 May 2002 13:43:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10800 for ; Wed, 22 May 2002 13:43:00 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21458 for ; Wed, 22 May 2002 13:42:39 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4MHfeZ2020920; Wed, 22 May 2002 19:41:40 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 22 May 2002 19:42:12 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 22 May 2002 19:42:11 +0200 Date: Wed, 22 May 2002 19:39:40 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Richard Shockey , Lawrence Conroy , Jon cc: enum@ietf.org, zmolek@avaya.com, michael@neonym.net Subject: RE: [Enum] enumservice names Message-ID: <49177759.1022096380@localhost> In-Reply-To: <5.1.0.14.2.20020522122154.0270a520@popd.ix.netcom.com> References: <48622267.1022087122@localhost> <48622267.1022087122@localhost> <5.1.0.14.2.20020522122154.0270a520@popd.ix.netcom.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 22 May 2002 17:42:12.0419 (UTC) FILETIME=[011EA130:01C201B8] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-22 12.26 -0400 Richard Shockey wrote: > It could be foofoo for all it matters so long as the applicability > statement in requesting the appropriate enumservice registration defines > 1. the reason for the registration 2. defines the service 3. the URI > scheme 4. anticipated context/behavior that the C/UA needs to understand. 5. Approptiate security considerations section paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 22 16:40:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29432 for ; Wed, 22 May 2002 16:40:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21447 for enum-archive@odin.ietf.org; Wed, 22 May 2002 16:41:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21047; Wed, 22 May 2002 16:32:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21019 for ; Wed, 22 May 2002 16:32:22 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29119 for ; Wed, 22 May 2002 16:32:02 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4MKUZR07612 for ; Wed, 22 May 2002 16:30:35 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4MKUZc07601 for ; Wed, 22 May 2002 16:30:35 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Enum] enumservice names Date: Wed, 22 May 2002 14:33:08 -0600 Message-ID: Thread-Topic: [Enum] enumservice names Thread-Index: AcIBqVzDLKr7ABd7S76IdLlhlVdQFAAJiK5A From: "Zmolek, Andrew (Andrew)" To: "Lawrence Conroy" , "Jon" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA21020 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Lawrence wrote: > I have a couple of ideas for names that might be appropriate - 'talk' > or 'phone' spring to mind, as the erstwhile 'tel' enumservice is > intended for use in interactive telephony calls; either seems > appropriate. > > Do any folks have a preference? I actually like 'talk' a lot because underneath it could resolve to a lot of different protocols but the intention of the enum query remains relatively clear nonetheless. This means that the srs enumservice could be called something like 'inquire' to express the idea that one is asking about what services are currently available to the originator of the inquiry, given the identity verification, presence knowledge, and application of policy rules associated with the service resolution service in question. Faxes and voicemail could fall under the 'deliver' service (really hate that name, but 'message' is overloaded and I don't want to confuse with session-oriented IM) or something similar where the operative function is the deposit of a page or snippet of media. IM and other session-oriented text could be 'chat' though that might be confusing with talk (would need something that is text-centric without being a page-delivery service) Video could be 'view', but page mode vs. stream mode wouldn't be clear enough ('see' has the same problem) And neither talks to the associated audio much. Worlkflow and whiteboard applications or other rich, complex interactions could be 'share' (though that might overlap with something else if we're not careful) Still, I think there may be a usable pattern in here somewhere... --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 sip:zmolek@avaya.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 22 17:19:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01910 for ; Wed, 22 May 2002 17:19:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24151 for enum-archive@odin.ietf.org; Wed, 22 May 2002 17:19:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23733; Wed, 22 May 2002 17:11:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23709 for ; Wed, 22 May 2002 17:10:58 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01171 for ; Wed, 22 May 2002 17:10:38 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4ML9n3W002413; Wed, 22 May 2002 23:09:50 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 22 May 2002 23:10:13 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 22 May 2002 23:10:12 +0200 Date: Wed, 22 May 2002 23:08:49 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Zmolek, Andrew (Andrew)" , Lawrence Conroy , Jon cc: enum@ietf.org, michael@neonym.net Subject: RE: [Enum] enumservice names Message-ID: <49930648.1022108929@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 22 May 2002 21:10:13.0256 (UTC) FILETIME=[10473880:01C201D5] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-22 14.33 -0600 "Zmolek, Andrew (Andrew)" wrote: > I actually like 'talk' a lot because underneath it could resolve to a lot > of different protocols but the intention of the enum query remains > relatively clear nonetheless. Note that the enumservice must specify a function + a URI scheme. I.e. given that you know what URI schemes you can take care of, and what "function" you want to handle, you should be able to (as application) to know what enumservices you can handle and not. So, "talk" with the help of a tel: URI scheme should most certainly be a different enumservicefield than "talk" with the help of a sip: URI scheme. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 22 18:47:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06009 for ; Wed, 22 May 2002 18:47:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28202 for enum-archive@odin.ietf.org; Wed, 22 May 2002 18:48:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27872; Wed, 22 May 2002 18:39:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27844 for ; Wed, 22 May 2002 18:39:06 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05661 for ; Wed, 22 May 2002 18:38:43 -0400 (EDT) Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090184; Wed, 22 May 2002 23:38:35 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <49930648.1022108929@localhost> References: <49930648.1022108929@localhost> Date: Wed, 22 May 2002 23:38:22 +0100 To: paf@cisco.com From: Lawrence Conroy Subject: RE: [Enum] enumservice names Cc: enum@ietf.org, michael@neonym.net, zmolek@avaya.com, jon.peterson@neustar.biz Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA27845 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 11:08 pm +0200 22/5/02, Patrik Fältström wrote: >--On 2002-05-22 14.33 -0600 "Zmolek, Andrew (Andrew)" >wrote: > >> I actually like 'talk' a lot because underneath it could resolve to a lot >> of different protocols but the intention of the enum query remains >> relatively clear nonetheless. > >Note that the enumservice must specify a function + a URI scheme. I.e. >given that you know what URI schemes you can take care of, and what >"function" you want to handle, you should be able to (as application) to >know what enumservices you can handle and not. > >So, "talk" with the help of a tel: URI scheme should most certainly be a >different enumservicefield than "talk" with the help of a sip: URI scheme. > > paf Hi Patrik, Andrew, folks, Couple of points here. First, please let's not call any enumservice by the "Inquire" tag, or you'll make half of the English speaking population unhappy (Enquire, maybe :). Second - a set of NAPTRs all with 'talk' as their enumservice tag, may have different schemes in their contained URIs. 'tel:' makes sense, bus so does 'sip:' (or even "h323:", if the Typhon people come through :). The Application knows it wants an interactive (telephony) conversation, and it also knows what drivers or associated software is available locally. If it doesn't have a SIP UAS then it has to discard a NAPTR with a sip: URI. I hope that is what we all expect. I am a bit confused over the different "enumservicefield" comment, however. Does this imply that the servicefield definition is going to change again :( I sure hope not! The current definition seems to work OK, IMHO. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 02:11:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27561 for ; Thu, 23 May 2002 02:11:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA25714 for enum-archive@odin.ietf.org; Thu, 23 May 2002 02:11:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25343; Thu, 23 May 2002 02:01:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25312 for ; Thu, 23 May 2002 02:01:36 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20667 for ; Thu, 23 May 2002 02:01:13 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4N60Et2020291; Thu, 23 May 2002 08:00:26 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 08:00:50 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 08:00:48 +0200 Date: Thu, 23 May 2002 07:57:23 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy cc: enum@ietf.org, michael@neonym.net, zmolek@avaya.com, jon.peterson@neustar.biz Subject: RE: [Enum] enumservice names Message-ID: <276076.1022140643@localhost> In-Reply-To: References: <49930648.1022108929@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 23 May 2002 06:00:49.0684 (UTC) FILETIME=[30449D40:01C2021F] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-22 23.38 +0100 Lawrence Conroy wrote: > Second - a set of NAPTRs all with 'talk' as their enumservice tag, may > have different schemes in their contained URIs. 'tel:' makes sense, bus > so does 'sip:' (or even "h323:", if the Typhon people come through :). No, that is not ok. The enumservice together with the domainname itself MUST be enough for selecting what record you want. You can not belive the party looking up a record is to parse and apply the rewrite rules before selecting the record. So, this described above is not acceptable. Voicecalls via tel URI and voicecalls via sip URI need to have different enumservices. Secondly: > First, please let's not call any enumservice by the "Inquire" tag, or > you'll make half of the English speaking population unhappy (Enquire, > maybe :). I don't understand this sentence. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 02:21:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27714 for ; Thu, 23 May 2002 02:21:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA26153 for enum-archive@odin.ietf.org; Thu, 23 May 2002 02:21:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25753; Thu, 23 May 2002 02:11:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25726 for ; Thu, 23 May 2002 02:11:43 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27576 for ; Thu, 23 May 2002 02:11:21 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g4N69sV3000538; Thu, 23 May 2002 02:09:54 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g4N69s4G000537; Thu, 23 May 2002 02:09:54 -0400 (EDT) Date: Thu, 23 May 2002 02:09:53 -0400 From: Michael Mealling To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: Lawrence Conroy , enum@ietf.org, michael@neonym.net, zmolek@avaya.com, jon.peterson@neustar.biz Subject: Re: [Enum] enumservice names Message-ID: <20020523020953.L21856@bailey.dscga.com> Reply-To: Michael Mealling References: <276076.1022140643@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <276076.1022140643@localhost> User-Agent: Mutt/1.3.22.1i Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit On Thu, May 23, 2002 at 07:57:23AM +0200, Patrik Fältström wrote: > --On 2002-05-22 23.38 +0100 Lawrence Conroy wrote: > > Second - a set of NAPTRs all with 'talk' as their enumservice tag, may > > have different schemes in their contained URIs. 'tel:' makes sense, bus > > so does 'sip:' (or even "h323:", if the Typhon people come through :). > > No, that is not ok. The enumservice together with the domainname itself > MUST be enough for selecting what record you want. You can not belive the > party looking up a record is to parse and apply the rewrite rules before > selecting the record. > > So, this described above is not acceptable. Voicecalls via tel URI and > voicecalls via sip URI need to have different enumservices. So how do you specify the case where an application can handle both a sip: and tel: URI for a voice call? That was one of the original reasons for creating the service field: two or more protocols/URI schemes that were useable for the same type of service. Hence the reason I had the enumservice and the protocol in the Service field. > Secondly: > > > First, please let's not call any enumservice by the "Inquire" tag, or > > you'll make half of the English speaking population unhappy (Enquire, > > maybe :). > > I don't understand this sentence. British vs American spelling.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 02:25:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27790 for ; Thu, 23 May 2002 02:25:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA26356 for enum-archive@odin.ietf.org; Thu, 23 May 2002 02:26:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25961; Thu, 23 May 2002 02:16:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA25929 for ; Thu, 23 May 2002 02:16:15 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27630 for ; Thu, 23 May 2002 02:15:53 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4N6F6t2021147; Thu, 23 May 2002 08:15:06 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 08:15:42 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 08:15:40 +0200 Date: Thu, 23 May 2002 08:15:32 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Michael Mealling cc: Lawrence Conroy , enum@ietf.org, michael@neonym.net, zmolek@avaya.com, jon.peterson@neustar.biz Subject: Re: [Enum] enumservice names Message-ID: <341396.1022141732@localhost> In-Reply-To: <20020523020953.L21856@bailey.dscga.com> References: <276076.1022140643@localhost> <20020523020953.L21856@bailey.dscga.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 23 May 2002 06:15:41.0856 (UTC) FILETIME=[440B4200:01C20221] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-23 02.09 -0400 Michael Mealling wrote: > So how do you specify the case where an application can handle > both a sip: and tel: URI for a voice call? That was one of the original > reasons for creating the service field: two or more protocols/URI schemes > that were useable for the same type of service. Hence the reason > I had the enumservice and the protocol in the Service field. If voice with tel is called telvoice and voice with sip is called sipvoice, then the application pick the two NAPTR which have those enumservices. I.e. the records have the same owner, so you still get back all of them when you issue the DNS query. I.e. you query for NAPTR records for an E.164. Then out of that set of records, you select records based on the enumservice field. Then, as third step you start applying the rewrite rules. You are the one which have tought me this! :-) paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 02:33:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27934 for ; Thu, 23 May 2002 02:33:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA27273 for enum-archive@odin.ietf.org; Thu, 23 May 2002 02:34:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26271; Thu, 23 May 2002 02:24:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26239 for ; Thu, 23 May 2002 02:24:26 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27766 for ; Thu, 23 May 2002 02:24:03 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g4N6MdV3000582; Thu, 23 May 2002 02:22:39 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g4N6Mcbm000581; Thu, 23 May 2002 02:22:38 -0400 (EDT) Date: Thu, 23 May 2002 02:22:38 -0400 From: Michael Mealling To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: Michael Mealling , Lawrence Conroy , enum@ietf.org, zmolek@avaya.com, jon.peterson@neustar.biz Subject: Re: [Enum] enumservice names Message-ID: <20020523022238.M21856@bailey.dscga.com> Reply-To: Michael Mealling References: <276076.1022140643@localhost> <20020523020953.L21856@bailey.dscga.com> <341396.1022141732@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <341396.1022141732@localhost> User-Agent: Mutt/1.3.22.1i Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit On Thu, May 23, 2002 at 08:15:32AM +0200, Patrik Fältström wrote: > --On 2002-05-23 02.09 -0400 Michael Mealling wrote: > > So how do you specify the case where an application can handle > > both a sip: and tel: URI for a voice call? That was one of the original > > reasons for creating the service field: two or more protocols/URI schemes > > that were useable for the same type of service. Hence the reason > > I had the enumservice and the protocol in the Service field. > > If voice with tel is called telvoice and voice with sip is called sipvoice, > then the application pick the two NAPTR which have those enumservices. I.e. > the records have the same owner, so you still get back all of them when you > issue the DNS query. > > I.e. you query for NAPTR records for an E.164. Then out of that set of > records, you select records based on the enumservice field. Then, as third > step you start applying the rewrite rules. > > You are the one which have tought me this! :-) Yes. But I'm after something different. I want to be able to define telvoice and sipvoice to be the same class of service (voice) but just handled by different transport services so that devices can handle both transports if needed. In your scenario above the two services are disjoint and appear to be non-interoperable. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 02:38:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28086 for ; Thu, 23 May 2002 02:38:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA27563 for enum-archive@odin.ietf.org; Thu, 23 May 2002 02:39:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26556; Thu, 23 May 2002 02:29:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26527 for ; Thu, 23 May 2002 02:29:19 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27836 for ; Thu, 23 May 2002 02:28:57 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4N6S9bF021879; Thu, 23 May 2002 08:28:10 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 08:28:45 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 08:28:44 +0200 Date: Thu, 23 May 2002 08:28:35 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Michael Mealling cc: Michael Mealling , Lawrence Conroy , enum@ietf.org, zmolek@avaya.com, jon.peterson@neustar.biz Subject: Re: [Enum] enumservice names Message-ID: <388396.1022142515@localhost> In-Reply-To: <20020523022238.M21856@bailey.dscga.com> References: <276076.1022140643@localhost> <20020523020953.L21856@bailey.dscga.com> <341396.1022141732@localhost> <20020523022238.M21856@bailey.dscga.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 23 May 2002 06:28:45.0606 (UTC) FILETIME=[17320460:01C20223] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-23 02.22 -0400 Michael Mealling wrote: > I want to be able to define > telvoice and sipvoice to be the same class of service (voice) but > just handled by different transport services so that devices can handle > both transports if needed. In your scenario above the two services > are disjoint and appear to be non-interoperable. Yes, they are disjoint, but different URI schemes (only). They might not use different transport services for the voice call. It is only two different URI schemes which are used to set up the call. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 02:52:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28499 for ; Thu, 23 May 2002 02:52:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28069 for enum-archive@odin.ietf.org; Thu, 23 May 2002 02:52:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27674; Thu, 23 May 2002 02:43:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27645 for ; Thu, 23 May 2002 02:42:59 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28186 for ; Thu, 23 May 2002 02:42:36 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g4N6fCV3000616; Thu, 23 May 2002 02:41:12 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g4N6fBNx000615; Thu, 23 May 2002 02:41:11 -0400 (EDT) Date: Thu, 23 May 2002 02:41:11 -0400 From: Michael Mealling To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: Michael Mealling , Lawrence Conroy , enum@ietf.org, zmolek@avaya.com, jon.peterson@neustar.biz Subject: Re: [Enum] enumservice names Message-ID: <20020523024111.N21856@bailey.dscga.com> Reply-To: Michael Mealling References: <276076.1022140643@localhost> <20020523020953.L21856@bailey.dscga.com> <341396.1022141732@localhost> <20020523022238.M21856@bailey.dscga.com> <388396.1022142515@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <388396.1022142515@localhost> User-Agent: Mutt/1.3.22.1i Content-Transfer-Encoding: 8bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit On Thu, May 23, 2002 at 08:28:35AM +0200, Patrik Fältström wrote: > --On 2002-05-23 02.22 -0400 Michael Mealling wrote: > > I want to be able to define > > telvoice and sipvoice to be the same class of service (voice) but > > just handled by different transport services so that devices can handle > > both transports if needed. In your scenario above the two services > > are disjoint and appear to be non-interoperable. > > Yes, they are disjoint, but different URI schemes (only). > > They might not use different transport services for the voice call. It is > only two different URI schemes which are used to set up the call. Ok, sorry. I wasn't precise enough: From your scenario it seems that telvoice and sipvoice both have different URI schemes. You are using this as a method of allowing selection of a specific URI during the DDDS Services examination phase of the algorithm. This is fine if that's what you are after. What I'm after is an enum service that defines 'voice' as allowing multiple URI schemes (sip, tel, h323, etc). This still leaves you with the inability to select which URI scheme you want during the algorithm which means you would need to add that back into the Service field (i.e. "voice+sip", or something like that). My issue is that I want to specify a higher level of intereoperability between what you're calling enumservices but still allow you to select the appropriate URI scheme in which to do it. That's why I'm still suggesting that "E2U+enumservice" isn't sufficient. I personally would prefer: "E2U-enumservice+scheme" or something like that. That gives us the ability to say something like this: "E2U-inquire+sip" for a SIP based service where you have to inquire in order to do anything else. But also "E2U-inquire+ldap" that can do the same thing but with another URI scheme. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 02:58:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28650 for ; Thu, 23 May 2002 02:58:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28212 for enum-archive@odin.ietf.org; Thu, 23 May 2002 02:59:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27969; Thu, 23 May 2002 02:49:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27938 for ; Thu, 23 May 2002 02:49:23 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28406 for ; Thu, 23 May 2002 02:49:01 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4N6mDB8023442; Thu, 23 May 2002 08:48:13 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 08:48:49 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 08:48:47 +0200 Date: Thu, 23 May 2002 08:48:32 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Michael Mealling cc: Michael Mealling , Lawrence Conroy , enum@ietf.org, zmolek@avaya.com, jon.peterson@neustar.biz Subject: Re: [Enum] enumservice names Message-ID: <460222.1022143712@localhost> In-Reply-To: <20020523024111.N21856@bailey.dscga.com> References: <276076.1022140643@localhost> <20020523020953.L21856@bailey.dscga.com> <341396.1022141732@localhost> <20020523022238.M21856@bailey.dscga.com> <388396.1022142515@localhost> <20020523024111.N21856@bailey.dscga.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 23 May 2002 06:48:48.0511 (UTC) FILETIME=[E42EC0F0:01C20225] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-23 02.41 -0400 Michael Mealling wrote: > From your scenario it seems that telvoice and sipvoice both have different > URI schemes. You are using this as a method of allowing selection of > a specific URI during the DDDS Services examination phase of the > algorithm. Yes. > What I'm after is > an enum service that defines 'voice' as allowing multiple URI schemes > (sip, tel, h323, etc). This still leaves you with the inability to select > which URI scheme you want during the algorithm which means you would need > to add that back into the Service field (i.e. "voice+sip", or something > like that). Ok. > My issue is that I want to specify a higher level of intereoperability > between what you're calling enumservices but still allow you to select > the appropriate URI scheme in which to do it. That's why I'm still > suggesting that "E2U+enumservice" isn't sufficient. I personally would > prefer: "E2U-enumservice+scheme" or something like that. That gives us the > ability to say something like this: > > "E2U-inquire+sip" for a SIP based service where you have to inquire in > order to do anything else. But also "E2U-inquire+ldap" that can do the > same thing but with another URI scheme. Let me then take a step back. I think one can solve the problem you (and I) are after by registering three different enumservices: - sipvoice - telvoice - voice For each one of them it is defined what it does. sipvoice might be "voice using Sip for negotiation, and the outcome will be rtp based voice channel using codec from gips". telvoice can be something else, and voice might be "voice call, random codec, random transpot, random URI scheme". The NAPTR records then can have: E2U+sipvoice+voice E2U+telvoice+voice paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 04:07:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29778 for ; Thu, 23 May 2002 04:07:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA01339 for enum-archive@odin.ietf.org; Thu, 23 May 2002 04:07:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00554; Thu, 23 May 2002 03:57:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00456 for ; Thu, 23 May 2002 03:56:58 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29559 for ; Thu, 23 May 2002 03:56:39 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 23 May 2002 09:43:49 +0200 Message-ID: From: "Stastny, Richard" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Michael Mealling Cc: Michael Mealling , Lawrence Conroy , enum@ietf.org, zmolek@avaya.com, jon.peterson@neustar.biz Subject: RE: [Enum] enumservice names Date: Thu, 23 May 2002 09:43:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA00457 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Hi all, I am following this discussion with a blank stare. When it started of, I thought there was some consensus on generic enumservices like talk, srs, message (or deliver) etc. The only discussion was about the naming. Then Patrik stated: No, that is not ok. The enumservice together with the domainname itself MUST be enough for selecting what record you want. You can not belive the party looking up a record is to parse and apply the rewrite rules before selecting the record. So, this described above is not acceptable. Voicecalls via tel URI and voicecalls via sip URI need to have different enumservices. If this is really the case, there is a severe problem in RFC2916bis. Even if this may be obvious to Patrik, it seems not to be obvious to others, as the discussion shows. Further, it is not feasible to create enough enumservices to deal with any possible combination. So I fully agree with Michael, that we need at least the following definition in RFC2916bis: E2U-enumservice+scheme where scheme is the URI used 1:1 (e.g. tel or sip). In this case only ONE enemservice shall be possible. I am still not sure, if this is sufficient, because the URI may have additional parameters and if I am not allowed to peek at the URI in advance, I still may have a problem: Example: E2U-message+tel with URI tel:+4317978013;svc=fax E2U-message+tel with URI tel:+436644204100;svc=sms So we may need something like "E2U-enumservice+scheme?svc" E.g: E2U-message+tel?sms The only other way is to define any possible service as ENUM service: E.g. Voice, video, fax, mail, sms, mms, ... (a never ending story) Best regards Richard > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Thursday, May 23, 2002 8:49 AM > To: Michael Mealling > Cc: Michael Mealling; Lawrence Conroy; enum@ietf.org; > zmolek@avaya.com; jon.peterson@neustar.biz > Subject: Re: [Enum] enumservice names > > > --On 2002-05-23 02.41 -0400 Michael Mealling > wrote: > > > From your scenario it seems that telvoice and sipvoice both have > > different URI schemes. You are using this as a method of allowing > > selection of a specific URI during the DDDS Services > examination phase > > of the algorithm. > > Yes. > > > What I'm after is > > an enum service that defines 'voice' as allowing multiple > URI schemes > > (sip, tel, h323, etc). This still leaves you with the inability to > > select which URI scheme you want during the algorithm which > means you > > would need to add that back into the Service field (i.e. > "voice+sip", > > or something like that). > > Ok. > > > My issue is that I want to specify a higher level of > intereoperability > > between what you're calling enumservices but still allow you to > > select the appropriate URI scheme in which to do it. > That's why I'm > > still suggesting that "E2U+enumservice" isn't sufficient. I > personally > > would > > prefer: "E2U-enumservice+scheme" or something like that. > That gives us the > > ability to say something like this: > > > > "E2U-inquire+sip" for a SIP based service where you have to > inquire in > > order to do anything else. But also "E2U-inquire+ldap" that > can do the > > same thing but with another URI scheme. > > Let me then take a step back. > > I think one can solve the problem you (and I) are after by > registering three different enumservices: > > - sipvoice > - telvoice > - voice > > For each one of them it is defined what it does. sipvoice > might be "voice using Sip for negotiation, and the outcome > will be rtp based voice channel using codec from gips". > telvoice can be something else, and voice might be "voice > call, random codec, random transpot, random URI scheme". > > The NAPTR records then can have: > > E2U+sipvoice+voice > E2U+telvoice+voice > > paf > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 11:12:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14024 for ; Thu, 23 May 2002 11:12:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25805 for enum-archive@odin.ietf.org; Thu, 23 May 2002 11:12:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24807; Thu, 23 May 2002 11:03:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24777 for ; Thu, 23 May 2002 11:03:04 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13499 for ; Thu, 23 May 2002 11:02:44 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4NF2Xc29338 for ; Thu, 23 May 2002 11:02:34 -0400 Message-Id: <5.1.0.14.2.20020523104930.04674ec8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 May 2002 10:50:03 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] REMINDER: Fwd: Internet-Draft Cutoff Dates for Yokohama, Japan Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >To: IETF-Announce: ; >From: Internet-Drafts Administrator >Subject: Internet-Draft Cutoff Dates for Yokohama, Japan >Date: Wed, 22 May 2002 15:01:20 -0400 >Sender: nsyracus@cnri.reston.va.us > > >NOTE: There are two (2) Internet-Draft Cutoff dates > >June 24th: Cutoff for Initial Submissions (new documents) > >All initial submissions(-00) must be submitted by Monday, >June 24th, at 09:00 US-EST. Initial submissions received after this time >will NOT be made available in the Internet-Drafts directory, and will have >to be resubmitted. > >As before, all initial submissions (-00.txt) with a filename beginning >with a draft-ietf MUST be approved by the appropriate WG Chair prior to >processing and announcing. WG Chair approval must be received by >Monday, June 24th. > > Please do NOT wait until the last minute to submit. > >Be advised: NO placeholders. Updates to initial submissions received > the week of June 24th will NOT be accepted. > >July 1st: FINAL Internet-Draft Cutoff > >All revised Internet-Draft submissions must be submitted by Monday, >July 1st, 2002 at 09:00 US-EST. Internet-Drafts received after this time >will NOT be announced NOR made available in the Internet-Drafts >Directories. > >We will begin accepting Internet-Draft submissions the week of the >meeting, though announcements will NOT be sent until the IETF meeting >is over. > >Thank you for your understanding and cooperation. Please do not hesitate >to contact us if you have any questions or concenrs. > >FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_54.html >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 11:15:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14213 for ; Thu, 23 May 2002 11:15:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26197 for enum-archive@odin.ietf.org; Thu, 23 May 2002 11:16:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25234; Thu, 23 May 2002 11:07:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25201 for ; Thu, 23 May 2002 11:07:19 -0400 (EDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13680 for ; Thu, 23 May 2002 11:06:59 -0400 (EDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id g4NF7Cd02445; Thu, 23 May 2002 15:07:12 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.35 #1) id 17AuBJ-000AB6-00; Thu, 23 May 2002 16:07:09 +0100 Date: Thu, 23 May 2002 16:07:09 +0100 From: "Clive D.W. Feather" To: "Zmolek, Andrew (Andrew)" Cc: Lawrence Conroy , Jon , enum@ietf.org, michael@neonym.net, paf@cisco.com Subject: Re: [Enum] enumservice names Message-ID: <20020523150709.GB27526@finch-staff-1.demon.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Zmolek, Andrew (Andrew) said: > IM and other session-oriented text could be 'chat' though that might be confusing with talk (would need something that is text-centric without being a page-delivery service) "texttalk" ? This could then also cover the things that deaf people use whose name I've forgotten, with a "tel:" URI. -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 11:19:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14335 for ; Thu, 23 May 2002 11:19:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26415 for enum-archive@odin.ietf.org; Thu, 23 May 2002 11:19:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25725; Thu, 23 May 2002 11:11:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25690 for ; Thu, 23 May 2002 11:10:59 -0400 (EDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13919 for ; Thu, 23 May 2002 11:10:39 -0400 (EDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id g4NFAVd03227; Thu, 23 May 2002 15:10:31 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.35 #1) id 17AuEX-000AI4-00; Thu, 23 May 2002 16:10:29 +0100 Date: Thu, 23 May 2002 16:10:29 +0100 From: "Clive D.W. Feather" To: "Stastny, Richard" Cc: "'Patrik =?iso-8859-1?Q?F=E4ltstr=F6m'?=" , Michael Mealling , Lawrence Conroy , enum@ietf.org, zmolek@avaya.com, jon.peterson@neustar.biz Subject: Re: [Enum] enumservice names Message-ID: <20020523151029.GC27526@finch-staff-1.demon.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Stastny, Richard said: > So we may need something like "E2U-enumservice+scheme?svc" > > E.g: > E2U-message+tel?sms By which time I've duplicated half of the NAPTR record. And what if I *don't* duplicate it accurately ? Which wins ? Far better to parse the NAPTR record for these fields. Come on: this is basic software engineering. Don't duplicate data without good reason. -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 11:43:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15171 for ; Thu, 23 May 2002 11:43:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28418 for enum-archive@odin.ietf.org; Thu, 23 May 2002 11:43:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27828; Thu, 23 May 2002 11:34:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27801 for ; Thu, 23 May 2002 11:34:31 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14837 for ; Thu, 23 May 2002 11:34:11 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 23 May 2002 17:21:21 +0200 Message-ID: From: "Stastny, Richard" To: "'Clive D.W. Feather'" Cc: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Michael Mealling , Lawrence Conroy , enum@ietf.org, zmolek@avaya.com, jon.peterson@neustar.biz Subject: RE: [Enum] enumservice names Date: Thu, 23 May 2002 17:21:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA27802 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net] > Sent: Thursday, May 23, 2002 5:10 PM > To: Stastny, Richard > Cc: 'Patrik Fältström'; Michael Mealling; Lawrence Conroy; > enum@ietf.org; zmolek@avaya.com; jon.peterson@neustar.biz > Subject: Re: [Enum] enumservice names > > > Stastny, Richard said: > > So we may need something like "E2U-enumservice+scheme?svc" > > > > E.g: > > E2U-message+tel?sms > > By which time I've duplicated half of the NAPTR record. And what if I > *don't* duplicate it accurately ? Which wins ? Far better to > parse the NAPTR record for these fields. > > Come on: this is basic software engineering. Don't duplicate > data without good reason. > Fully agree! That was originally my understanding. I also have not seen any feasable use of the regexp, so in most cases it will be "Throw away and replace by" anyway. Please lets keep it simple (at least for the trials). Regards Richard -- > Clive D.W. Feather | Work: | Tel: +44 > 20 8371 1138 > Internet Expert | Home: | Fax: +44 > 870 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: > +44 7973 377646 > Thus plc | | NOTE: fax > number change > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 11:57:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15737 for ; Thu, 23 May 2002 11:57:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29219 for enum-archive@odin.ietf.org; Thu, 23 May 2002 11:58:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28827; Thu, 23 May 2002 11:49:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28796 for ; Thu, 23 May 2002 11:49:17 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15439 for ; Thu, 23 May 2002 11:48:52 -0400 (EDT) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090189; Thu, 23 May 2002 16:48:41 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <5.1.0.14.2.20020523105702.04686ec0@popd.ix.netcom.com> References: <341396.1022141732@localhost> <276076.1022140643@localhost> <20020523020953.L21856@bailey.dscga.com> <341396.1022141732@localhost> <5.1.0.14.2.20020523105702.04686ec0@popd.ix.netcom.com> Date: Thu, 23 May 2002 16:48:31 +0100 To: Richard Shockey From: Lawrence Conroy Subject: Re: [Enum] enumservice names Cc: enum@ietf.org, zmolek@avaya.com, jon.peterson@neustar.biz, michael@neonym.net, paf@cisco.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:06 am -0400 23/5/02, Richard Shockey wrote: >A >> > If voice with tel is called telvoice and voice with sip is >>called sipvoice, >>> then the application pick the two NAPTR which have those enumservices. I.e. >>> the records have the same owner, so you still get back all of them when you >>> issue the DNS query. >>> >>> I.e. you query for NAPTR records for an E.164. Then out of that set of >>> records, you select records based on the enumservice field. Then, as third >>> step you start applying the rewrite rules. >>> >>> You are the one which have tought me this! :-) >> >>Yes. But I'm after something different. I want to be able to define >>telvoice and sipvoice to be the same class of service (voice) but >>just handled by different transport services so that devices can handle >>both transports if needed. In your scenario above the two services >>are disjoint and appear to be non-interoperable. > >AND .. I might add .. here we go again going into granularity in >enumservice definitions. This is a very very slippery slope that I >thought we had over come. > >I dont like this and frankly I never will, except in those unique >cases such as SMTP where due to the store and forward nature of the >protocol it is impossible to determine end point capability in >advance of session creation. This covers the email vs voice mail vs >fax mail issue. > >I think there is common agreement that upon query first process the >NAPTR records based on the enumservice field ... then and only then >once the C/UA or whatever finds what it wants, if there are more >than one enumservice field matching the requirements then use >preference to sort them out then apply the rewrite rules. > >I think there is still going to be a huge problem convincing the SIP >community that there needs to be multiple definitions of SIP based >on the capabilities of the endpoint. Negotiation or discovery of >capability should occur during the INVITE and not potentially >exposed in the global DNS. > Hi Rich, folks, OK, so the last meeting was not successful in clearing out why we have URI *and* enumservice *and* D3S application, or we wouldn't be here. The steps as listed above - [implied D3S application process], winnow NAPTR RRset returned based on enumservice sub-field (and preference for tie breaking), Then process re-write. I don't think anyone disagrees with these steps. But... In addition to the above items, some URIs have parameters or qualifiers - e.g. tel: has phone-context to act as a filter on the origination context within which it is valid. So there may be some post filtering AFTER the re-write has constructed a URI (or URIs). Now, if the enumservice sub-field is merely reflecting the URI scheme "out" into the NAPTR service field, then life is easy. I don't need to write an enumservice registration as some kind folk have already registered the URIs with which I'm going to populate my DNS. I can just put in references to the URI scheme as defined in some RFC - in fact, I don't even need to put the references in any document - it's just the scheme tag copied from the URI. It doesn't even get obsolete with new URI schemes. Works for me, even if it does make the NAPTR larger. However...If the enumservice sub-field is supposed to be used for something else, then what? all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 23 11:58:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14019 for ; Thu, 23 May 2002 11:12:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25791 for enum-archive@odin.ietf.org; Thu, 23 May 2002 11:12:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24850; Thu, 23 May 2002 11:03:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24816 for ; Thu, 23 May 2002 11:03:18 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13504 for ; Thu, 23 May 2002 11:02:58 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4NF2Yc29341; Thu, 23 May 2002 11:02:34 -0400 Message-Id: <5.1.0.14.2.20020523105702.04686ec0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 May 2002 11:06:05 -0400 To: Michael Mealling , Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Richard Shockey Subject: Re: [Enum] enumservice names Cc: enum@ietf.org, zmolek@avaya.com, jon.peterson@neustar.biz In-Reply-To: <20020523022238.M21856@bailey.dscga.com> References: <341396.1022141732@localhost> <276076.1022140643@localhost> <20020523020953.L21856@bailey.dscga.com> <341396.1022141732@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org A > > If voice with tel is called telvoice and voice with sip is called sipvoice, > > then the application pick the two NAPTR which have those enumservices. I.e. > > the records have the same owner, so you still get back all of them when you > > issue the DNS query. > > > > I.e. you query for NAPTR records for an E.164. Then out of that set of > > records, you select records based on the enumservice field. Then, as third > > step you start applying the rewrite rules. > > > > You are the one which have tought me this! :-) > >Yes. But I'm after something different. I want to be able to define >telvoice and sipvoice to be the same class of service (voice) but >just handled by different transport services so that devices can handle >both transports if needed. In your scenario above the two services >are disjoint and appear to be non-interoperable. AND .. I might add .. here we go again going into granularity in enumservice definitions. This is a very very slippery slope that I thought we had over come. I dont like this and frankly I never will, except in those unique cases such as SMTP where due to the store and forward nature of the protocol it is impossible to determine end point capability in advance of session creation. This covers the email vs voice mail vs fax mail issue. I think there is common agreement that upon query first process the NAPTR records based on the enumservice field ... then and only then once the C/UA or whatever finds what it wants, if there are more than one enumservice field matching the requirements then use preference to sort them out then apply the rewrite rules. I think there is still going to be a huge problem convincing the SIP community that there needs to be multiple definitions of SIP based on the capabilities of the endpoint. Negotiation or discovery of capability should occur during the INVITE and not potentially exposed in the global DNS. >-MM > >-- >-------------------------------------------------------------------------------- >Michael Mealling | Vote Libertarian! | urn:pin:1 >michael@neonym.net | | http://www.neonym.net > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 23 12:24:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17026 for ; Thu, 23 May 2002 12:24:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA02604 for enum-archive@odin.ietf.org; Thu, 23 May 2002 12:24:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01951; Thu, 23 May 2002 12:15:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01922 for ; Thu, 23 May 2002 12:15:27 -0400 (EDT) Received: from rainier.illuminet.com ([63.116.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16618 for ; Thu, 23 May 2002 12:15:06 -0400 (EDT) Received: from olwinexsmtp01.corp.illuminet.com (olwinexsmtp01.corp.illuminet.com [172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id JAA05540; Thu, 23 May 2002 09:14:55 -0700 (PDT) Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 09:14:55 -0700 Message-ID: <1C1EEC765F843E44996971A80682118B014B1427@opwinex02.corp.illuminet.com> From: Kevin McCandless To: "'enum@ietf.org'" Cc: "'shollenbeck@verisign.com'" Date: Thu, 23 May 2002 09:14:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20274.F8530F10" Subject: [Enum] EPP for E.164 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20274.F8530F10 Content-Type: text/plain; charset="iso-8859-1" We want to bring to everyone's attention to the draft for provisioning E.164 numbers using EPP in a registry environment. http://search.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-00.txt . This draft was accepted as an ENUM working group item at the 53rd IETF. We would like to solicit comments for this draft so we can make changes, if necessary, to the draft before the June 24th cut off date for the 54th IETF in Japan. We would like to move forward, as expediently as possible, because the ENUM forum is very interested in having this draft move to RFC before they adopt it into their provisioning process. Please note we have not received any comments from the ENUM list on this draft. So, speak up please! Thank you! Kevin McCandless Senior Network Planner Illuminet (A VeriSign Company) 913-814-6397 kmccandless@verisign.com ------_=_NextPart_001_01C20274.F8530F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We want to=20 bring to everyone's attention to the draft for provisioning E.164 = numbers using=20 EPP in a registry environment.   http://search.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-= 00.txt.=20 This draft was accepted as an ENUM working group item at the 53rd = IETF.  We=20 would like to solicit comments for this draft so we can make changes, = if=20 necessary, to the draft before the June 24th cut off date for the = 54th IETF=20 in Japan.  We would like to move forward, as expediently as = possible,=20 because the ENUM forum is very interested in having this draft move to = RFC=20 before they adopt it into their provisioning process.  =
 
Please note we have=20 not received any comments from the ENUM list on this draft.  So, = speak up=20 please!
 
Thank = you!

Kevin McCandless
Senior Network Planner
Illuminet (A VeriSign=20 Company)
913-814-6397 =
kmccandless@verisign.com 

 

 
------_=_NextPart_001_01C20274.F8530F10-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 23 13:13:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18708 for ; Thu, 23 May 2002 13:13:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05576 for enum-archive@odin.ietf.org; Thu, 23 May 2002 13:13:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05231; Thu, 23 May 2002 13:04:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05199 for ; Thu, 23 May 2002 13:04:30 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18220 for ; Thu, 23 May 2002 13:04:10 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09505 for ; Thu, 23 May 2002 13:02:48 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09487 for ; Thu, 23 May 2002 13:02:47 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Enum] enumservice names Date: Thu, 23 May 2002 11:05:16 -0600 Message-ID: Thread-Topic: [Enum] enumservice names Thread-Index: AcICcXHrYciY/tYPSO+ezOrAEQyc1QACJiGA From: "Zmolek, Andrew (Andrew)" To: "Lawrence Conroy" , "Richard Shockey" Cc: , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA05200 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Lawrence wrote: > So there may be some post filtering AFTER the re-write has > constructed a URI (or URIs). This does seem to be the crux of the dispute. I agree with Lawrence here. And I assert that not only will there be post-filtering on the *protocol* side of the URI, but some uses may even look for capability "hints" in the URI *path* and other parameters. If so, then the use of the enumservice field should be one that is not fundamentally representable by the URI path itself. In selection of a schema for the enumservice field, what strikes me as fundamentally not represented in the URI is the intent of the parties involved. This is why service resolution is different from call completion even though both may occur via the same basic URI. And this is why classes of communication like 'talk' vs. 'tty' or 'texttalk' make sense. Moreover, if I have a means of invoking transcription services for an arbitrary number of protocols, I can't use the enumservice to derive at this question of intent when I don't know my protocol capabilities in advance. For instance, if a new protocol appeared under an entry the 'talk' enumservice, I could attempt to invoke a transcription service knowing that the class of communication for the call was compatible with talking (as opposed to typing, for instance). Of course, there may be ways to transcribe between the two, but if my list of possibilities has no such hint regarding the basic intent (or model or interface, whatever), then the enumservice field will be only marginally useful. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 sip:zmolek@avaya.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 23 13:39:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19616 for ; Thu, 23 May 2002 13:39:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07554 for enum-archive@odin.ietf.org; Thu, 23 May 2002 13:40:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06511; Thu, 23 May 2002 13:29:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06480 for ; Thu, 23 May 2002 13:29:56 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19311 for ; Thu, 23 May 2002 13:29:35 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4NHTHc32548 for ; Thu, 23 May 2002 13:29:18 -0400 Message-Id: <5.1.0.14.2.20020523120012.046354c0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 May 2002 13:34:25 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] EPP for E.164 numbers Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org With the kind permission of Scott Hollenbeck I'm copying some details from a private conversation I had with him over his draft... draft-ietf-enum-epp-e164-00.txt As many of you know there has been substantial activity on the Global ENUM front with several National Regulatory Administrations discussing trial activities ( a small list is below and if you have any other URI's please feel free to add them) . Clearly beyond the trial phases there is going to have to be discussions on provisioning issues where there are multiple entities exchanging data and that was the principal reason the WG elected to add this draft to our work. I have a number of questions related to the bulk upload, but I'm also interested in what additional fields are needed given various requirements and relationships between ENUM Registrants - Registrars - Registry Service Provider of Record etc. Clearly some requirements would be national implementation specific but the proposed data object is quite extensible. Comment and thoughts would be most welcome so we can continue to advance this draft along. > > I'm certainly guilty of not making comments ..even though I > > have one big comment question feature set enhancement and > > that has to deal with bulk up load of registrations. > > > > Scott if you can find the time to take a look at the problem > > I'm wondering how you feel about the case of multiple > > registrations under one admin tech contact ..aka the > > enterprise issue where a organization needs to register all > > of its numbers at once but the classical contact tech data is > > the same for all. I'm wondering from a transaction basis what > > is the best method for doing this ... this is not really TLD > > registrations after all. > >One of the significant problems in trying to do "bulk" operations at the >protocol level involves error recovery. With each E.164 number mapping to a >single domain name, the transactional consequences of an error 499 names in >to a block of 500 is problematic - does the whole transaction fail? Does >some part of the transaction succeed, and another part fail? With EPP I >took the approach that the protocol's transactional behavior is best managed >at the most basic level - transactions are easiest to implement and manage >if they deal with only one object (in this case domain names) at a time. > >Having said that, I think the best place to implement some sort of bulk >operations service is in a layer above the basic protocol client. An API >that understands ranges of E.164 numbers on the front end can easily produce >multiple back-end protocol transactions. Errors can be easily managed in >this abstract layer, with reporting and recovery behavior specified as part >of the API. > >I guess what I'm saying is that the complexity of bulk processing can be >addressed in either the server or in some abstract client layer, and my >personal feeling is that an abstract client layer is the better place. > > > In addition I'm wondering what extensible fields might be > > necessary ..such as carrier of record ..who issued the TN in > > the first place etc.. Kevin you could certainly give that > > some thought. > > > > I could go on and on ... > >Sure, this is why the document is out for comment in the first place. I'm >hoping that folks who have been active in places like the ENUM Forum can >provide insights into the practical info that might be needed. Yes . if you or any of your colleagues have been active in the national ENUM Forums and can add some insight here to the problem statement that would be a "good thing" tm. United States ENUM Forum http://www.enum-forum.org Australia Communications Authority page on ENUM http://www.aca.gov.au/committee/nsg2/enum.htm UK Department of Trade and Industry ENUM page http://www.dti.gov.uk/cii/regulatory/enum/index.shtml Austria Regulator ENUM page http://www.tkc.at/web.nsf/deutsch/Telekommunikation~Nummerierung~ENUM SWISS OFFCOM ENUM home page http://www.num2002.ch/de/telekommunikation/nummerierung/enum/ >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 23 16:36:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26273 for ; Thu, 23 May 2002 16:36:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16970 for enum-archive@odin.ietf.org; Thu, 23 May 2002 16:36:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16132; Thu, 23 May 2002 16:27:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16012 for ; Thu, 23 May 2002 16:27:22 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25903 for ; Thu, 23 May 2002 16:27:01 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4NKOpZn002678; Thu, 23 May 2002 22:25:07 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 22:25:38 +0200 Received: from [192.168.1.5] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 23 May 2002 22:25:33 +0200 Date: Thu, 23 May 2002 22:11:22 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , Richard Shockey cc: enum@ietf.org, zmolek@avaya.com, jon.peterson@neustar.biz, michael@neonym.net Subject: Re: [Enum] enumservice names Message-ID: <1098768.1022191882@localhost> In-Reply-To: References: <341396.1022141732@localhost> <276076.1022140643@localhost><20020523020953.L21856@bailey.dscga.com> <341396.1022141732@localhost> <5.1.0.14.2.20020523105702.04686ec0@popd.ix.netcom.com> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 23 May 2002 20:25:33.0351 (UTC) FILETIME=[FD57EB70:01C20297] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-23 16.48 +0100 Lawrence Conroy wrote: > However...If the enumservice sub-field is supposed to be used > for something else, then what? Up to the one registering an enumservice being different from the URI scheme. I.e. 2916bis doesn't prohibit people from writing documents about enumservicefields which are "foo", "bar" and "baz". In 2916, it could only be the URI scheme, and only one such scheme per NAPTR. I heard that that was not enough, so 2916bis is more flexible. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 23 16:36:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26274 for ; Thu, 23 May 2002 16:36:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16971 for enum-archive@odin.ietf.org; Thu, 23 May 2002 16:36:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16098; Thu, 23 May 2002 16:27:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16010 for ; Thu, 23 May 2002 16:27:22 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25904 for ; Thu, 23 May 2002 16:27:01 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4NKOpZp002678; Thu, 23 May 2002 22:25:12 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 22:25:38 +0200 Received: from [192.168.1.5] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 23 May 2002 22:25:34 +0200 Date: Thu, 23 May 2002 22:14:19 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Zmolek, Andrew (Andrew)" , Lawrence Conroy , Richard Shockey cc: enum@ietf.org, jon.peterson@neustar.biz, michael@neonym.net Subject: RE: [Enum] enumservice names Message-ID: <1109397.1022192059@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 23 May 2002 20:25:35.0492 (UTC) FILETIME=[FE9E9C40:01C20297] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-23 11.05 -0600 "Zmolek, Andrew (Andrew)" wrote: > If so, then the use of the enumservice field should be one that is not > fundamentally representable by the URI path itself. It depends. In some cases you need to do a lookup of NAPTR RRs several times and apply the rewrite rule to get the full URI, so, I would like to say that an enumservicefield is to give hints which are enough so a client resolving the E2U NAPTR chains doesn't have to do too much unnessecary work. This is _exactly_ why I suggested separate documents which specify each one of the enumservices. In those documents it can be written exactly what the client can expect given a specific enumservicefield. Regardless of if it is "sip" or "voice". paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 23 16:51:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26845 for ; Thu, 23 May 2002 16:51:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17634 for enum-archive@odin.ietf.org; Thu, 23 May 2002 16:51:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17231; Thu, 23 May 2002 16:42:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17206 for ; Thu, 23 May 2002 16:42:32 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26512 for ; Thu, 23 May 2002 16:42:12 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4NKei206813 for ; Thu, 23 May 2002 16:40:44 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4NKeiC06800 for ; Thu, 23 May 2002 16:40:44 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Enum] enumservice names Date: Thu, 23 May 2002 14:43:18 -0600 Message-ID: Thread-Topic: [Enum] enumservice names Thread-Index: AcICmCRyMXTbDxb8Qfa6K+RCfHA7RgAAa+vg From: "Zmolek, Andrew (Andrew)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Lawrence Conroy" , "Richard Shockey" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA17207 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik wrote: > I.e. 2916bis doesn't prohibit people from writing documents about > enumservicefields which are "foo", "bar" and "baz". In 2916, > it could only > be the URI scheme, and only one such scheme per NAPTR. > > I heard that that was not enough, so 2916bis is more flexible. So are you suggesting, Patrik, that *no* attempt should be made to limit the number of valid enumservices accepted as RFC standards-track documents? If not, what will the process be for evaluation? And what will ensure that the overall schema of the enumservice field is preserved? --Andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 23 16:58:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27015 for ; Thu, 23 May 2002 16:58:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17837 for enum-archive@odin.ietf.org; Thu, 23 May 2002 16:58:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17559; Thu, 23 May 2002 16:50:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA17534 for ; Thu, 23 May 2002 16:50:12 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26788 for ; Thu, 23 May 2002 16:49:51 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4NKmlJu003835; Thu, 23 May 2002 22:49:02 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Thu, 23 May 2002 22:49:34 +0200 Received: from [192.168.1.5] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 23 May 2002 22:49:33 +0200 Date: Thu, 23 May 2002 22:48:19 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Zmolek, Andrew (Andrew)" , Lawrence Conroy , Richard Shockey cc: enum@ietf.org, jon.peterson@neustar.biz, michael@neonym.net Subject: RE: [Enum] enumservice names Message-ID: <1231804.1022194099@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 23 May 2002 20:49:33.0576 (UTC) FILETIME=[57C8D080:01C2029B] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-23 14.43 -0600 "Zmolek, Andrew (Andrew)" wrote: > So are you suggesting, Patrik, that *no* attempt should be made to limit > the number of valid enumservices accepted as RFC standards-track > documents? No. I think your idea of lining up the first 10-12 so we have something to talk about is a good proposal. 2916bis says that enumservices needs to be documented in RFC's and we do have a policy for reviewing RFC's in the IETF. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 23 17:14:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27455 for ; Thu, 23 May 2002 17:14:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19561 for enum-archive@odin.ietf.org; Thu, 23 May 2002 17:14:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19138; Thu, 23 May 2002 17:05:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19107 for ; Thu, 23 May 2002 17:05:22 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27201 for ; Thu, 23 May 2002 17:05:02 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4NKb7203934 for ; Thu, 23 May 2002 16:37:07 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4NKb7C03916 for ; Thu, 23 May 2002 16:37:07 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Enum] enumservice names Date: Thu, 23 May 2002 14:39:41 -0600 Message-ID: Thread-Topic: [Enum] enumservice names Thread-Index: AcICmCS7yr1b0myHTSaufideT2hawAAANFkw From: "Zmolek, Andrew (Andrew)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "Lawrence Conroy" , "Richard Shockey" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA19108 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik wrote: > This is _exactly_ why I suggested separate documents which > specify each one of the enumservices. In those documents > it can be written exactly what the client can expect given > a specific enumservicefield. Regardless of if it is > "sip" or "voice". And I support this decision 100% because it makes the most sense. My *only* worry is that the overall enumservice schema is still sufficiently cloudy that we will end up with both 'voice' and 'sipgipstotexttranscoding' enumservices in the same schema. Perhaps a strawman of what the 10-12 enumservices might be would help immensely to that end. --Andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 23 17:15:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27539 for ; Thu, 23 May 2002 17:15:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19662 for enum-archive@odin.ietf.org; Thu, 23 May 2002 17:15:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19231; Thu, 23 May 2002 17:07:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19200 for ; Thu, 23 May 2002 17:07:09 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27228 for ; Thu, 23 May 2002 17:06:49 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4NL6Kc04780; Thu, 23 May 2002 17:06:20 -0400 Message-Id: <5.1.0.14.2.20020523165745.028ba5d0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 May 2002 17:11:29 -0400 To: "Zmolek, Andrew (Andrew)" , Patrik =?iso-8859-1?Q?Fältström?= , "Lawrence Conroy" From: Richard Shockey Subject: RE: [Enum] enumservice names Cc: , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 02:39 PM 5/23/2002 -0600, Zmolek, Andrew (Andrew) wrote: >Patrik wrote: > > > This is _exactly_ why I suggested separate documents which > > specify each one of the enumservices. In those documents > > it can be written exactly what the client can expect given > > a specific enumservicefield. Regardless of if it is > > "sip" or "voice". > >And I support this decision 100% because it makes the most sense. My >*only* worry is that the overall enumservice schema is still sufficiently >cloudy that we will end up with both 'voice' and >'sipgipstotexttranscoding' enumservices in the same schema. Perhaps a >strawman of what the 10-12 enumservices might be would help immensely to >that end. and I totally concur ... Patrik will be writing the rules in 2916bis for the appropriate documentation that constitute a request for a IANA registration which will include what we had noted before. > It could be foofoo for all it matters so long as the applicability > statement in requesting the appropriate enumservice registration defines > 1. the reason for the registration 2. defines the service 3. the URI > scheme 4. anticipated context/behavior that the C/UA needs to understand. 5. Appropriate security considerations section but rather than 10 -12 maybe 5-6 to start with ... well I can almost see E2U+protocol+service as a general syntax ...but only in very very specific cases such as SMTP where E2U+SMPT+FAX might seem reasonable. but I continue to submit that in the case of SIP it looks like E2U+SIP .. and that is it. In the sprit of a tired old scratchy broken record, I continue to insist there are real dangers in exposing too much information in the global DNS ..especially when it is clearly linked to personal communications capabilities and preferences. I continue to submit we should take a very minimalist approach to this and that the justification for exposing the capability of an enumservice endpoint should meet a very stringent test of applicability. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 23 20:32:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01702 for ; Thu, 23 May 2002 20:32:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28735 for enum-archive@odin.ietf.org; Thu, 23 May 2002 20:33:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28031; Thu, 23 May 2002 20:23:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28000 for ; Thu, 23 May 2002 20:23:52 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01509 for ; Thu, 23 May 2002 20:23:30 -0400 (EDT) Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090201 for ; Fri, 24 May 2002 01:23:27 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Fri, 24 May 2002 01:22:52 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] enumservices - the story so far Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi folks, to check that I have understood where we are right now, I've been trying to summarize this thread. As I read it... From Patrik's message (of Wednesday at 2110Z) he believes that the service field should include the URI scheme plus the enumservice (such, I guess, as the ones above), in addition to the E2U DDDS application tag. This is reinforced by his message (of Thursday at 0600Z). I'm not quite sure what Patrik's message (of Thursday at 0648Z) is suggesting - I think that the is sipvoice or telvoice, and this is followed by another tag, voice, in both cases. In his message (of Thursday at 0641Z) Michael suggests -+ Richard agrees with Michael in his message (of Thursday at 0743Z) but points out that there may also be service differentiators (e.g. svc=fax, svc=sms, ...). Rich is concerned (in message of Thursday at 1506Z) about different NAPTRs based on the capability of endpoint. This is reinforced in his message (of Thursday at 1911Z) in which he restates his concern that too much data may be exposed in DNS indicating personal communications capabilities and preferences Clive (message of Thursday at 1510Z) suggests that carrying all of this data in the services field is a duplication and that it is far better to parse the NAPTR. Richard reminds us (in his message of Thursday at 1521Z) that it should be simple for trials, and that need for regexp in first phase is not clear I (in my message of Thursday at 1548Z) reiterated my concern over the real use for the enumservice sub-field, and agreed that there would be a post regexp filtering step. Andrew suggests (in message on Thursday at 1705Z) that filtering may even include URI path parsing for capability hints, and that the enumservice sub-field should NOT be representative of the URI scheme. Patrik responded to my question on use of enumservice sub-field (in first message on Thursday at 2025Z) by pointing out that this is up to the author of the enumservice registration - this flexibility is one change from 2916 Patrik then sent another message (also on Thursday at 2025Z) that I don't understand but discusses ENUM chains. In his message (on Thursday at 2039Z) Andrew agrees, but is concerned that we need to crystallise the enumservice schemas Andrew (in message on Thursday at 2043Z) raises concerns over the enumservice RFC process, whether or not there should be an unlimited number of such RFCs, and how one ensures that the schema is valid for a NAPTR Patrik responds (in message on Thursday at 2049Z) that these must be RFCs and that there is a defined review process for RFCs in the IETF, and that the idea of 10-12 entries in a strawman schema set is a good one Rich (in message on Thursday at 2111Z) also highlights the enumservice registration procedure in 2916bis, and suggests 5-6 entries is better for the strawman schemas Have I got the salient points so far? (If so we can get on to the schema set proposals). all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 01:45:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08880 for ; Fri, 24 May 2002 01:45:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18704 for enum-archive@odin.ietf.org; Fri, 24 May 2002 01:45:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18480; Fri, 24 May 2002 01:36:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18448 for ; Fri, 24 May 2002 01:36:53 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08784; Fri, 24 May 2002 01:36:33 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4O5Z7a27158; Fri, 24 May 2002 01:35:07 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4O5Z6f27149; Fri, 24 May 2002 01:35:06 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 23 May 2002 23:37:40 -0600 Message-ID: Thread-Topic: [Sipping] "E2U+sip" vs "sip+E2U" Thread-Index: AcIC4vNEBRzF/ZbJRcuQZ8PyFpZsygAAc0CQ From: "Zmolek, Andrew (Andrew)" To: , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA18450 Subject: [Enum] RE: [Sipping] "E2U+sip" vs "sip+E2U" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit This was changed starting in the enum bis. Yes, it's a bit confusing :-) --Andy > -----Original Message----- > From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] > Sent: Thursday, May 23, 2002 11:17 PM > To: sipping@ietf.org > Cc: enum@ietf.org > Subject: [Sipping] "E2U+sip" vs "sip+E2U" > > > draft-ietf-enum-rfc2916bis-00.txt specifies that in enum naprt > records the service field for sip has the format > > "E2U+sip" > > whereas draft-ietf-sipping-e164-01.txt specifies > > "sip+E2U" > > this is VERY confusing. which working group has got it right or is > there a competition going on? > > -- juha > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 01:59:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09346 for ; Fri, 24 May 2002 01:59:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA19432 for enum-archive@odin.ietf.org; Fri, 24 May 2002 01:59:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19071; Fri, 24 May 2002 01:50:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19042 for ; Fri, 24 May 2002 01:50:52 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09029 for ; Fri, 24 May 2002 01:50:32 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4O5ngDO020106; Fri, 24 May 2002 07:49:46 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Fri, 24 May 2002 07:50:19 +0200 Received: from [192.168.1.5] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 24 May 2002 07:50:18 +0200 Date: Fri, 24 May 2002 07:48:50 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] enumservices - the story so far Message-ID: <1398498.1022226530@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 24 May 2002 05:50:18.0851 (UTC) FILETIME=[E2ACE330:01C202E6] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-24 01.22 +0100 Lawrence Conroy wrote: > From Patrik's message (of Wednesday at 2110Z) he believes that the > service field should include the URI scheme plus the enumservice (such, I > guess, as the ones above), in addition to the E2U DDDS application tag. No, that was not what I wrote. I wrote: > Note that the enumservice must specify a function + a URI scheme. I.e. > given that you know what URI schemes you can take care of, and what > "function" you want to handle, you should be able to (as application) to > know what enumservices you can handle and not. > > So, "talk" with the help of a tel: URI scheme should most certainly be a > different enumservicefield than "talk" with the help of a sip: URI scheme. You continue: > I (in my message of Thursday at 1548Z) reiterated my concern over the > real use for the enumservice sub-field, and agreed that there would be a > post regexp filtering step. Of course it will be, at least in the cases when you have more than one URI in the list of possibilities. You have to choose one. > Patrik responded to my question on use of enumservice sub-field (in first > message on Thursday at 2025Z) by pointing out that this is up to the > author of the enumservice registration - this flexibility is one change > from 2916 Yes. > Patrik then sent another message (also on Thursday at 2025Z) that I don't > understand but discusses ENUM chains. I don't understand where you get the timestamps from, but guess you talk about this message sent on 2014Z: > It depends. In some cases you need to do a lookup of NAPTR RRs several > times and apply the rewrite rule to get the full URI, so, I would like to > say that an enumservicefield is to give hints which are enough so a client > resolving the E2U NAPTR chains doesn't have to do too much unnessecary > work. You might get back an NAPTR which is non terminal when looking it up. The enumservice then should give you enough information so you know whether you should chase the chain of NAPTR. > Patrik responds (in message on Thursday at 2049Z) that these must be RFCs > and that there is a defined review process for RFCs in the IETF, and that > the idea of 10-12 entries in a strawman schema set is a good one > > Rich (in message on Thursday at 2111Z) also highlights the enumservice > registration procedure in 2916bis, and suggests 5-6 entries is better for > the strawman schemas > > Have I got the salient points so far? (If so we can get on to the schema > set proposals). Yes, modulo that I actually have posted a proposal. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 02:15:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18244 for ; Fri, 24 May 2002 02:15:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA20592 for enum-archive@odin.ietf.org; Fri, 24 May 2002 02:16:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20296; Fri, 24 May 2002 02:07:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20161 for ; Fri, 24 May 2002 02:07:21 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18008; Fri, 24 May 2002 02:07:01 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4O66E5Z021021; Fri, 24 May 2002 08:06:14 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Fri, 24 May 2002 08:06:50 +0200 Received: from [192.168.1.5] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 24 May 2002 08:06:49 +0200 Date: Fri, 24 May 2002 08:05:45 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Zmolek, Andrew (Andrew)" , jh@lohi.eng.song.fi, sipping@ietf.org cc: enum@ietf.org Subject: Re: [Enum] RE: [Sipping] "E2U+sip" vs "sip+E2U" Message-ID: <1459423.1022227545@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-OriginalArrivalTime: 24 May 2002 06:06:49.0652 (UTC) FILETIME=[313D1F40:01C202E9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA20162 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit RFC 2916 specifies sip+E2U. the sipping draft follows that RFC. The replacement for RFC 2916, 2916bis-draft, talks about E2U+sip, and that because it must be possible to: - Have more than one servicefield on the same NAPTR - Have a different syntax between 2916bis (which require separat registrations for the services) and 2916 (which uses URI scheme as service) I suggest you follow what is written in 2916bis. paf --On 2002-05-23 23.37 -0600 "Zmolek, Andrew (Andrew)" wrote: > This was changed starting in the enum bis. > > Yes, it's a bit confusing :-) > > --Andy > >> -----Original Message----- >> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi] >> Sent: Thursday, May 23, 2002 11:17 PM >> To: sipping@ietf.org >> Cc: enum@ietf.org >> Subject: [Sipping] "E2U+sip" vs "sip+E2U" >> >> >> draft-ietf-enum-rfc2916bis-00.txt specifies that in enum naprt >> records the service field for sip has the format >> >> "E2U+sip" >> >> whereas draft-ietf-sipping-e164-01.txt specifies >> >> "sip+E2U" >> >> this is VERY confusing. which working group has got it right or is >> there a competition going on? >> >> -- juha >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum > Patrik Fältström Cisco Systems Consulting Engineer Office of the CSO Phone: (Stockholm) +46-8-6859131 (San Jose) +1-408-525-8509 PGP: 2DFC AAF6 16F0 F276 7843 2DC1 BC79 51D9 7D25 B8DC _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 05:25:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21235 for ; Fri, 24 May 2002 05:25:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA28582 for enum-archive@odin.ietf.org; Fri, 24 May 2002 05:26:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28375; Fri, 24 May 2002 05:16:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28346 for ; Fri, 24 May 2002 05:16:50 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21118 for ; Fri, 24 May 2002 05:16:29 -0400 (EDT) Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090203; Fri, 24 May 2002 10:16:27 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <1398498.1022226530@localhost> References: <1398498.1022226530@localhost> Date: Fri, 24 May 2002 10:15:51 +0100 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Lawrence Conroy Subject: Re: [Enum] enumservices - the story so far Cc: enum@ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA28347 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 7:48 am +0200 24/5/02, Patrik Fältström wrote: >--On 2002-05-24 01.22 +0100 Lawrence Conroy wrote: > >> From Patrik's message (of Wednesday at 2110Z) he believes that the >> service field should include the URI scheme plus the enumservice (such, I >> guess, as the ones above), in addition to the E2U DDDS application tag. > >No, that was not what I wrote. > >I wrote: >> Note that the enumservice must specify a function + a URI scheme. I.e. >> given that you know what URI schemes you can take care of, and what >> "function" you want to handle, you should be able to (as application) to >> know what enumservices you can handle and not. >> >> So, "talk" with the help of a tel: URI scheme should most certainly be a >> different enumservicefield than "talk" with the help of a sip: URI scheme. Apologies for this - my misunderstanding. Function != enumservice always. >You continue: >> I (in my message of Thursday at 1548Z) reiterated my concern over the >> real use for the enumservice sub-field, and agreed that there would be a >> post regexp filtering step. > >Of course it will be, at least in the cases when you have more than one URI >in the list of possibilities. You have to choose one. > >> Patrik responded to my question on use of enumservice sub-field (in first >> message on Thursday at 2025Z) by pointing out that this is up to the >> author of the enumservice registration - this flexibility is one change >> from 2916 > >Yes. > >> Patrik then sent another message (also on Thursday at 2025Z) that I don't >> understand but discusses ENUM chains. > >I don't understand where you get the timestamps from, but guess you talk >about this message sent on 2014Z: Sorry - must have missed a Date: header in the email. Yes. exactly. > > It depends. In some cases you need to do a lookup of NAPTR RRs several >> times and apply the rewrite rule to get the full URI, so, I would like to >> say that an enumservicefield is to give hints which are enough so a client >> resolving the E2U NAPTR chains doesn't have to do too much unnessecary >> work. > >You might get back an NAPTR which is non terminal when looking it up. The >enumservice then should give you enough information so you know whether you >should chase the chain of NAPTR. Many thanks for this. The light dawns. You mean we must have the services field even for non-terminals, and that's all the D3S-application has to make its selection. > > Patrik responds (in message on Thursday at 2049Z) that these must be RFCs >> and that there is a defined review process for RFCs in the IETF, and that >> the idea of 10-12 entries in a strawman schema set is a good one >> >> Rich (in message on Thursday at 2111Z) also highlights the enumservice >> registration procedure in 2916bis, and suggests 5-6 entries is better for >> the strawman schemas >> >> Have I got the salient points so far? (If so we can get on to the schema >> set proposals). > >Yes, modulo that I actually have posted a proposal. Understood. Now for these. > paf Apologies for the misrepresentation. Forwards. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 05:31:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21335 for ; Fri, 24 May 2002 05:31:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA29157 for enum-archive@odin.ietf.org; Fri, 24 May 2002 05:31:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28526; Fri, 24 May 2002 05:22:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28495 for ; Fri, 24 May 2002 05:22:46 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21195 for ; Fri, 24 May 2002 05:22:26 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4O9LZ4x014019; Fri, 24 May 2002 11:21:39 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Fri, 24 May 2002 11:22:12 +0200 Received: from host-n22-183.homerun.telia.com ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 24 May 2002 11:22:11 +0200 Date: Fri, 24 May 2002 11:21:56 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy cc: enum@ietf.org Subject: Re: [Enum] enumservices - the story so far Message-ID: <1902152.1022239316@localhost> In-Reply-To: References: <1398498.1022226530@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 24 May 2002 09:22:11.0804 (UTC) FILETIME=[7C2F91C0:01C20304] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-24 10.15 +0100 Lawrence Conroy wrote: > You mean we must have the services field even for non-terminals, and > that's all the D3S-application has to make its selection. Exactly! Michael of course know the details better than myself, but this is where my mind is. Note though to everyone: This is more a NAPTR education issue (how NAPTR work) than ENUM, but very very relevant and important because of implications. > Apologies for the misrepresentation. Forwards. No problem. As wg chair, and as document editor I really appreciate the extremely useful discussion, which includes your summaries of course. Now when SG2 meeting in ITU-T I will create a new version of the I-D of 2916bis, so I am very interested in conclusions on what should be written in 2916bis. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 14:20:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08544 for ; Fri, 24 May 2002 14:20:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10260 for enum-archive@odin.ietf.org; Fri, 24 May 2002 14:20:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09537; Fri, 24 May 2002 14:10:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09507 for ; Fri, 24 May 2002 14:10:47 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08149 for ; Fri, 24 May 2002 14:10:25 -0400 (EDT) Received: from [193.118.205.14] (HELO [193.118.205.13]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090207 for ; Fri, 24 May 2002 19:10:15 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 (Unverified) Message-Id: Date: Fri, 24 May 2002 19:09:53 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] ENUM non-terminals Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi folks, I have a question for the people who understand non-terminal processing within ENUM (i.e. not me :). As I get it, a D3S application is selected by some user program with a D3S application tag. In the case of ENUM, this is 'E2U'. The D3S application has a key (by some means) and submits a query of its database (the ENUM portion of DNS space) using this key, receiving a set of NAPTRs in response. Some or all of these may have an empty flags field (i.e. are non-terminal). I guess that the D3S application will be looking for its D3S application tag within the service field of the NAPTRs. I had assumed that it would discard any NAPTRs that did not have this tag, but I'm no longer sure. For now, let's assume that it does only consider those NAPTRs that have its tag in their service field - anything else is in the process of exiting ENUM and doing something else, and so is out of scope for this group. If there is a "tie" for order and preference, the D3S application can use the rest of the service field to help it select which path to follow (i.e. which NAPTR to use). It could run parallel or sequential processing on each of them (follow all paths), or some, or just one, or reject them all and abort. Now, each of these NAPTRs will have at least one enumservice sub-field (it could have more). Given that the enumservice is supposed to indicate the likely outcome of further processing it should (I guess from prior threads) include an indication of the URI scheme that will occur at the "end of this path". Patrik's examples were "telvoice" and/or "sipvoice", implying tel: or sip: URIs will result. I'm quite possibly losing it in the recursion, but: how does one ensure that a non-terminal NAPTR has an honest enumservice value? Given that a non-terminal, by definition, will (after regexp translation) result in a new key, and that that key will be used to query the ENUM DNS space, then there could be a set of NAPTRs at the domain queried as a result of the non-terminal regexp processing. Any one of these could be selected "in the next round", and the result could actually be a different path with a different enumservice. It seems to me that this is at best an administrative nightmare, and at worst an impossibility. Thus, help please - what am I missing here? all the best from a spinlocked Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 14:37:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09605 for ; Fri, 24 May 2002 14:37:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12322 for enum-archive@odin.ietf.org; Fri, 24 May 2002 14:37:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAB10906; Fri, 24 May 2002 14:29:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10715 for ; Fri, 24 May 2002 14:29:00 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05094 for ; Fri, 24 May 2002 12:39:36 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4OGdKc23043; Fri, 24 May 2002 12:39:25 -0400 Message-Id: <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 May 2002 12:44:31 -0400 To: Lawrence Conroy , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] enumservices - the story so far In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > >This is reinforced by his message (of Thursday at 0600Z). > >I'm not quite sure what Patrik's message (of Thursday at 0648Z) is >suggesting - I think that the is sipvoice or telvoice, and >this is followed by another tag, voice, in both cases. Broken Record Speaking IMHO E2U+SIP is the complete enum service field for sip ... now tel could be E2U+tel+SMS or E2U+tel+voice or E2U+tel+TDD this is another example of the case wher exposing endpoint data that cannot be derived in advance or during the creation of a session such as in SIP. IMHO such enumservice fields might IMHO pass muster. >This is reinforced in his message (of Thursday at 1911Z) in which he >restates his concern that too much data may be exposed in DNS indicating >personal communications capabilities and preferences Yes you can go down the path of service granularity but I hope you'll enjoy spending a great deal of time in London, Geneva, Brussels or Washington DC in a suit and tie explaining the privacy implications of this to regulators. >Clive (message of Thursday at 1510Z) suggests that carrying all of this >data in the services field is a duplication and that it is far better to >parse the NAPTR. I dont agree .. once the set of records is returned it makes more sense to sort on the services field first ..even if similar data is contained in the URI within in the regexp >Richard reminds us (in his message of Thursday at 1521Z) that it should be >simple for trials, and that need for regexp in first phase is not clear > >I (in my message of Thursday at 1548Z) reiterated my concern over the real >use for the enumservice sub-field, and agreed that there would be a post >regexp filtering step. in the case where you might have two identical service fields >In his message (on Thursday at 2039Z) Andrew agrees, but is concerned that >we need to crystallise the enumservice schemas again a limited subset ... I think SIP, hopefully we'll see some drafts on H.323 before Yokahama tel and SMTP are a pretty reasonable starting point...after that I trust our VPIM colleagues will chime in. >Andrew (in message on Thursday at 2043Z) raises concerns over the >enumservice RFC process, whether or not there should be an unlimited >number of such RFCs, and how one ensures that the schema is valid for a NAPTR Again this is why each registration will require a separate RFC to permit the IESG stringent review. I'm not worried about this. >Patrik responds (in message on Thursday at 2049Z) that these must be RFCs >and that there is a defined review process for RFCs in the IETF, and that >the idea of 10-12 entries in a strawman schema set is a good one > > >Have I got the salient points so far? (If so we can get on to the schema >set proposals). please do ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 14:50:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10310 for ; Fri, 24 May 2002 14:50:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA13668 for enum-archive@odin.ietf.org; Fri, 24 May 2002 14:51:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12571; Fri, 24 May 2002 14:42:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12538 for ; Fri, 24 May 2002 14:42:17 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09922 for ; Fri, 24 May 2002 14:41:55 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g4OIefV3005682; Fri, 24 May 2002 14:40:41 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g4OIeejV005681; Fri, 24 May 2002 14:40:40 -0400 (EDT) Date: Fri, 24 May 2002 14:40:40 -0400 From: Michael Mealling To: Richard Shockey Cc: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] enumservices - the story so far Message-ID: <20020524144040.E3554@bailey.dscga.com> Reply-To: Michael Mealling References: <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Fri, May 24, 2002 at 12:44:31PM -0400, Richard Shockey wrote: > >This is reinforced by his message (of Thursday at 0600Z). > > > >I'm not quite sure what Patrik's message (of Thursday at 0648Z) is > >suggesting - I think that the is sipvoice or telvoice, and > >this is followed by another tag, voice, in both cases. > > Broken Record Speaking IMHO E2U+SIP is the complete enum service field > for sip ... now tel could be E2U+tel+SMS or E2U+tel+voice or > E2U+tel+TDD this is another example of the case wher exposing endpoint > data that cannot be derived in advance or during the creation of a session > such as in SIP. IMHO such enumservice fields might IMHO pass muster. Ok, I'll ask the question I asked before. Are you suggesting making it illegal to use SIP in any other enumservice? (I don't think you are but I'm just checking). If you aren't then what you are describing is a service where the protocol tells you what the services are. You're confusing the service with the protocol. The question is this: Do you want an enumservice that gaurantees that you never see anything but SIP from beginning to end? Then that's valid. (Limiting, but valid.) But don't call it 'SIP'. Its just to confusing. I would prefer an enumservice called 'inquire' that has a protocol attached to it like this: "inquire+sip" so that other protocols can be used with that service (e.g. LDAP). It still gives you the ability to gaurantee that you never see non-SIP stuff (which is what I think you are after) without creating an enumservice that never allows anything else latter.... > >This is reinforced in his message (of Thursday at 1911Z) in which he > >restates his concern that too much data may be exposed in DNS indicating > >personal communications capabilities and preferences > > Yes you can go down the path of service granularity but I hope you'll > enjoy spending a great deal of time in London, Geneva, Brussels or > Washington DC in a suit and tie explaining the privacy implications of this > to regulators. That may be the case but that's for them to decide. > >Clive (message of Thursday at 1510Z) suggests that carrying all of this > >data in the services field is a duplication and that it is far better to > >parse the NAPTR. > > I dont agree .. > > once the set of records is returned it makes more sense to sort on the > services field first ..even if similar data is contained in the URI within > in the regexp Yep. The URI is just the address of the endpoint and that needs to be divorced from the actual ENUM service description. This is the problem with many URL schemes these days: they're used as service descriptors when there really isn't any direct correlation between the address and the service offered at that address. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 15:34:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11662 for ; Fri, 24 May 2002 15:34:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA16317 for enum-archive@odin.ietf.org; Fri, 24 May 2002 15:34:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15284; Fri, 24 May 2002 15:25:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15259 for ; Fri, 24 May 2002 15:25:31 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11326 for ; Fri, 24 May 2002 15:25:08 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4OJOrc26250; Fri, 24 May 2002 15:24:53 -0400 Message-Id: <5.1.0.14.2.20020524150806.028bd000@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 May 2002 15:30:04 -0400 To: Michael Mealling From: Richard Shockey Subject: Re: [Enum] enumservices - the story so far Cc: Lawrence Conroy , enum@ietf.org In-Reply-To: <20020524144040.E3554@bailey.dscga.com> References: <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > > >I'm not quite sure what Patrik's message (of Thursday at 0648Z) is > > >suggesting - I think that the is sipvoice or telvoice, and > > >this is followed by another tag, voice, in both cases. > > > > Broken Record Speaking IMHO E2U+SIP is the complete enum service field > > for sip ... now tel could be E2U+tel+SMS or E2U+tel+voice or > > E2U+tel+TDD this is another example of the case wher exposing endpoint > > data that cannot be derived in advance or during the creation of a session > > such as in SIP. IMHO such enumservice fields might IMHO pass muster. > >Ok, I'll ask the question I asked before. Are you suggesting making it >illegal to use SIP in any other enumservice? (I don't think you are >but I'm just checking). If you aren't then what you are describing is >a service where the protocol tells you what the services are. You're >confusing the service with the protocol. The question is this: now I am getting confused ... this all seemed so simple to me ..you need to give me a more concrete example here of what you mean ... what I am saying that SIP is SIP and the protocol itself defines "on the wire" what services / capability can be offered. >Do you want an enumservice that gaurantees that you never see anything >but SIP from beginning to end? Then that's valid. (Limiting, but valid.) >But don't call it 'SIP'. Its just to confusing. duh ... that is what I want, a enumservice that is SIP period and not broken up into E2U+SIP+voice / E2U+SIP+voice+IM etc etc and why wouldnt I want call the NAPTR enumservice field for SIP , SIP? I think this is what I mean and no I dont necessarily think its limiting. It is a view based on a pretty strong understanding of what SIP does and what it does not do. I might say exactly the same thing about H.323 as well . >I would prefer an enumservice called 'inquire' that has a protocol >attached to it like this: "inquire+sip" so that other protocols can >be used with that service (e.g. LDAP). It still gives you the ability >to gaurantee that you never see non-SIP stuff (which is what I think >you are after) without creating an enumservice that never allows anything >else latter.... well inquire+sip is not SIP No ... once the INVITE is sent the response will indicate its willingness to begin a session immediately or describe what is capable of accepting SIP is SIP > > >This is reinforced in his message (of Thursday at 1911Z) in which he > > >restates his concern that too much data may be exposed in DNS indicating > > >personal communications capabilities and preferences > > > > Yes you can go down the path of service granularity but I hope you'll > > enjoy spending a great deal of time in London, Geneva, Brussels or > > Washington DC in a suit and tie explaining the privacy implications of > this > > to regulators. > >That may be the case but that's for them to decide. NO .... I prefer not to have ENUM killed after the fact. Just as we are cognizant of security considerations in IETF protocols we, in this case, should be equally vigilant about privacy. Its there it is increasingly codified in law and it is in our best interest to > > >Clive (message of Thursday at 1510Z) suggests that carrying all of this > > >data in the services field is a duplication and that it is far better to > > >parse the NAPTR. > > > > I dont agree .. > > > > once the set of records is returned it makes more sense to sort on the > > services field first ..even if similar data is contained in the URI within > > in the regexp > >Yep. The URI is just the address of the endpoint and that needs to be >divorced from the actual ENUM service description. This is the problem >with many URL schemes these days: they're used as service descriptors when >there really isn't any direct correlation between the address and the service >offered at that address. good .. I was sure this is what we all understood to be the case. >-MM > >-- >-------------------------------------------------------------------------------- >Michael Mealling | Vote Libertarian! | urn:pin:1 >michael@neonym.net | | >http://www.neonym.net >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 15:50:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12260 for ; Fri, 24 May 2002 15:50:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17285 for enum-archive@odin.ietf.org; Fri, 24 May 2002 15:50:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16752; Fri, 24 May 2002 15:42:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16721 for ; Fri, 24 May 2002 15:42:00 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11978 for ; Fri, 24 May 2002 15:41:37 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g4OJeNV3005819; Fri, 24 May 2002 15:40:23 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g4OJeNqC005818; Fri, 24 May 2002 15:40:23 -0400 (EDT) Date: Fri, 24 May 2002 15:40:22 -0400 From: Michael Mealling To: Richard Shockey Cc: Michael Mealling , Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] enumservices - the story so far Message-ID: <20020524154022.F3554@bailey.dscga.com> Reply-To: Michael Mealling References: <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020524150806.028bd000@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020524150806.028bd000@popd.ix.netcom.com> User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Fri, May 24, 2002 at 03:30:04PM -0400, Richard Shockey wrote: > >> >I'm not quite sure what Patrik's message (of Thursday at 0648Z) is > >> >suggesting - I think that the is sipvoice or telvoice, and > >> >this is followed by another tag, voice, in both cases. > >> > >> Broken Record Speaking IMHO E2U+SIP is the complete enum service > >field > >> for sip ... now tel could be E2U+tel+SMS or E2U+tel+voice or > >> E2U+tel+TDD this is another example of the case wher exposing endpoint > >> data that cannot be derived in advance or during the creation of a > >session > >> such as in SIP. IMHO such enumservice fields might IMHO pass muster. > > > >Ok, I'll ask the question I asked before. Are you suggesting making it > >illegal to use SIP in any other enumservice? (I don't think you are > >but I'm just checking). If you aren't then what you are describing is > >a service where the protocol tells you what the services are. You're > >confusing the service with the protocol. The question is this: > > now I am getting confused ... this all seemed so simple to me ..you need to > give me a more concrete example here of what you mean ... what I am saying > that SIP is SIP and the protocol itself defines "on the wire" what services > / capability can be offered. But I might not want to use SIP that way. I might not be using all of SIPs features or my client may be so dumb as to only be able to blast out hardwired SIP packets. You are assuming a full SIP client and I'm just suggesting that may not be the case. > >Do you want an enumservice that gaurantees that you never see anything > >but SIP from beginning to end? Then that's valid. (Limiting, but valid.) > >But don't call it 'SIP'. Its just to confusing. > > duh ... that is what I want, a enumservice that is SIP period and not > broken up into E2U+SIP+voice / E2U+SIP+voice+IM etc etc Ok, no problem there... But again, are you suggesting that it be illegal to use SIP in any other way? > and why wouldnt I want call the NAPTR enumservice field for SIP , SIP? I > think this is what I mean and no I dont necessarily think its limiting. It > is a view based on a pretty strong understanding of what SIP does and what > it does not do. > > I might say exactly the same thing about H.323 as well . But that's a _protocol_ view, not a _functional_ view. I know SIP does all and that no one should ever use anything else for any reason but I've also heard the same things about HTTP. What I'm trying to get is that the function "you have to go ask via the protocol" is a valid service that multiple protocols will offer (H323, SIP and even LDAP). Here's an example: let's say someone is running an H323 service and provides a SIP gateway to it but for contractual/market share reasons they want to make the H323 service run better or have more features. Both interfaces provide the "we'll tell you everything there is to know" service but a client application may want to know that for that service there is an H323 interface and a SIP interface for that function. > >I would prefer an enumservice called 'inquire' that has a protocol > >attached to it like this: "inquire+sip" so that other protocols can > >be used with that service (e.g. LDAP). It still gives you the ability > >to gaurantee that you never see non-SIP stuff (which is what I think > >you are after) without creating an enumservice that never allows anything > >else latter.... > > well inquire+sip is not SIP > > No ... once the INVITE is sent the response will indicate its willingness > to begin a session immediately or describe what is capable of > accepting SIP is SIP Ok, how 'bout this: "invite+sip"? SIP maybe SIP but is SIP _everything_? Is SIP the only protocol to ever be allowed to work this way? It really sounds like you're suggesting that SIP is the only thing anyone should be using and that you're willing to enforce that with ENUM. > >> >This is reinforced in his message (of Thursday at 1911Z) in which he > >> >restates his concern that too much data may be exposed in DNS indicating > >> >personal communications capabilities and preferences > >> > >> Yes you can go down the path of service granularity but I hope you'll > >> enjoy spending a great deal of time in London, Geneva, Brussels or > >> Washington DC in a suit and tie explaining the privacy implications of > >this > >> to regulators. > > > >That may be the case but that's for them to decide. > > NO .... I prefer not to have ENUM killed after the fact. Just as we are > cognizant of security considerations in IETF protocols we, in this case, > should be equally vigilant about privacy. Its there it is increasingly > codified in law and it is in our best interest to Sure. But you're _still_ looking at this in terms of your services and policiess. Others may have other solutions and ENUM should be modular enough so that those things are solved in the correct places, not mandated by 2916bis itself. -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 16:39:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13680 for ; Fri, 24 May 2002 16:39:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20372 for enum-archive@odin.ietf.org; Fri, 24 May 2002 16:40:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20192; Fri, 24 May 2002 16:31:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20161 for ; Fri, 24 May 2002 16:31:06 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13344 for ; Fri, 24 May 2002 16:30:38 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4OKUJc27383; Fri, 24 May 2002 16:30:19 -0400 Message-Id: <5.1.0.14.2.20020524160444.028cd9b0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 24 May 2002 16:35:30 -0400 To: Michael Mealling From: Richard Shockey Subject: Re: [Enum] enumservices - the story so far Cc: enum@ietf.org In-Reply-To: <20020524154022.F3554@bailey.dscga.com> References: <5.1.0.14.2.20020524150806.028bd000@popd.ix.netcom.com> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020524150806.028bd000@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > > now I am getting confused ... this all seemed so simple to me ..you > need to > > give me a more concrete example here of what you mean ... what I am saying > > that SIP is SIP and the protocol itself defines "on the wire" what > services > > / capability can be offered. > >But I might not want to use SIP that way. I might not be using all of >SIPs features or my client may be so dumb as to only be able to blast >out hardwired SIP packets. You are assuming a full SIP client and I'm >just suggesting that may not be the case. I'm not willing to totally dismiss your point its just that , I guess, I really need to see a specific application requirement here for what you suggest. > > >Do you want an enumservice that gaurantees that you never see anything > > >but SIP from beginning to end? Then that's valid. (Limiting, but valid.) > > >But don't call it 'SIP'. Its just to confusing. > > > > duh ... that is what I want, a enumservice that is SIP period and not > > broken up into E2U+SIP+voice / E2U+SIP+voice+IM etc etc > >Ok, no problem there... But again, are you suggesting that it be illegal >to use SIP in any other way? No .. but you are thinking about something that I'm having serious trouble visualizing in my mind. > > and why wouldnt I want call the NAPTR enumservice field for SIP , SIP? I > > think this is what I mean and no I dont necessarily think its limiting. It > > is a view based on a pretty strong understanding of what SIP does and what > > it does not do. > > > > I might say exactly the same thing about H.323 as well . > >But that's a _protocol_ view, not a _functional_ view. I know SIP does >all and that no one should ever use anything else for any reason but I've >also heard the same things about HTTP. What I'm trying to get is that >the function "you have to go ask via the protocol" is a valid service >that multiple protocols will offer (H323, SIP and even LDAP). Here's >an example: let's say someone is running an H323 service and provides >a SIP gateway to it but for contractual/market share reasons they want >to make the H323 service run better or have more features. Both interfaces >provide the "we'll tell you everything there is to know" service but >a client application may want to know that for that service there is >an H323 interface and a SIP interface for that function. Im not sure this is the best example since there are issues of who and what actually writes NAPTR records for a specific FQDN ..but I sense the direction you want to go but I'm still not convinced of its applicability without some other kinds of examples. > > >I would prefer an enumservice called 'inquire' that has a protocol > > >attached to it like this: "inquire+sip" so that other protocols can > > >be used with that service (e.g. LDAP). It still gives you the ability > > >to gaurantee that you never see non-SIP stuff (which is what I think > > >you are after) without creating an enumservice that never allows anything > > >else latter.... how would you express this function? > > > > well inquire+sip is not SIP > > > > No ... once the INVITE is sent the response will indicate its willingness > > to begin a session immediately or describe what is capable of > > accepting SIP is SIP > >Ok, how 'bout this: "invite+sip"? SIP maybe SIP but is SIP _everything_? OK E2U+SIP+invite or just E2U+SIP being the general case, plain vanilla, one stop SIP shopping. Can you elaborate more on what other options you propose. You see my point about capabilities right? I don't want SIP+voice SIP+video+IM etc. You seem to be suggesting bonding several protocols and services in a single write of a enumservice field that may need multiple URI's in the regexp to parse? I can be open minded ...but I think you are going to have a lot up hill work convincing the SIP community of what you are proposing. And as you may know they are not shy about voicing their opinions... :-) > > > > > >That may be the case but that's for them to decide. > > > > NO .... I prefer not to have ENUM killed after the fact. Just as we are > > cognizant of security considerations in IETF protocols we, in this case, > > should be equally vigilant about privacy. Its there it is increasingly > > codified in law and it is in our best interest to > >Sure. But you're _still_ looking at this in terms of your services and >policiess. Others may have other solutions and ENUM should be modular >enough so that those things are solved in the correct places, not >mandated by 2916bis itself. Well of course ... not in 2916bis but I would hope both you and Patrik add Privacy Considerations to Security Considerations as requirements for enumservice field IANA registration process. I totally agree that the IANA registration process is the place for the IESG to review and enforce that type of requirement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri May 24 19:21:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19392 for ; Fri, 24 May 2002 19:21:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA27388 for enum-archive@odin.ietf.org; Fri, 24 May 2002 19:21:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27158; Fri, 24 May 2002 19:12:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27070 for ; Fri, 24 May 2002 19:12:31 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19010 for ; Fri, 24 May 2002 19:12:04 -0400 (EDT) Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090208; Sat, 25 May 2002 00:12:03 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Sat, 25 May 2002 00:11:47 +0100 To: enum@ietf.org From: Lawrence Conroy Cc: rich.shockey@NeuStar.biz, michael@neonym.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] enumservice role Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Rich, Michael, Everyone, OK...I think I can see a certain divergence of views here. The original 2916 view was that we use together with 'E2U' in the NAPTR service field. The expanded view as expressed in 2916bis has together with a set of sub-fields. (plus the process has been formalised in the baroque magnificence of D3S). The move that a number of folks (myself included) have been taking is towards a functional model rather than just a URI-scheme (or "protocol") model. Rich is concerned about leakage of personal preference/capabilities information. A vision of "years more suiting it around in expensive but anodyne International Hotels, trying to avoid cirrhosis from the boredom and frustration" appears before the eyes....and all to explain privacy concerns? Now, Andrew comes in with what I think is a generalisation of the neat negotiation/redirection feature of SIP; SRS. No folks, it's not an airbag - it's what SIP does and has always done. It's a Service Resolution Service. It's also, potentially, what LPAP (& some glue) does, so the generalisation is fine by me. OK - Michael calls it by the Swahili term "inquire", but it seems to be similar to Andrew's 'srs'. This is a ->function<- that uses URI-schemes sip: or ldap: or ??? Yes, one can suffice with separate tokens 'sip', 'ldap', ???, each of which identifies the URI-scheme to be used. This is exactly what was in 2916. However, it does not capture the general ->function<- that is available at this resource identifier. More generally, I think it quite likely that a certain Washington State company will have a lot of IM users. I bet that a certain ISP/Telco with a Sun logo will expect to get shedloads of Voice users via its SIP service. I also expect there to be ructions if either one or the other try to seal a business relationship that hides one of the identity/contact addresses behind the other. I fully expect people to have at least two 'sip:' addresses, not because it makes any sense technically, but because a unified non-technical solution is just too hard, and is going to be too hard to explain to the generality of users. Now to the specific... I want to get the schema sets nailed down. I want this done now, and as Richard points out, please keep it simple, folks, as there are several trials people would rather like to get going. Trials means that we need something that some poor sods can implement. That means something syntactically unambiguous, with a defined state machine, and preferably not too processor or memory intensive. Oh, I'd also like it maintainable by mere mortals and possible to cross check so that the information stored is consistent. Here's the kicker - I'd like this to happen Real Soon Now, so the collected poor sods get a chance to program it and test it before it hits the trials users. If not, then all that grief within the IETF and then in the ITU was a waste of brain power, livers, and handling some contribs from all over (including the US :) that has pushed stress into life-shortening levels - for what? All this, just to get some URIs into a domain name space so I can map from an assigned E.164 number to a set of URIs. C'mon guys...either we have schema sets with functions, or we stick with 2916. I understand if we tag on the URI-scheme as well so that the program doesn't have to process the regexp to find out if it's interested in the NAPTR result, but the essential question sees to be simple - either we include the generalised function within the schema or we don't. Now, if there's a privacy problem with this ->Opt-In<- service, then we need to find a way that a registrant can avoid putting in over-detailed capabilities information into the (public) DNS. I'm happy to have an enumservice called 'ImFeelingLucky' or 'undefined' for that. However, if Joe Registrant decides that they want to tell potential callers that the only contact they will get using this address-of-record is IM, they should be able to do this, IMHO. Thanks - I feel sooo much better now. Seriously, folks, let's see if we can get the "function-based" schema set strawman out in black and white electrons. I understand the concerns over the role of enumservices, but let's split that off into a separate thread from refining the strawman. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Sat May 25 10:20:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22913 for ; Sat, 25 May 2002 10:20:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10889 for enum-archive@odin.ietf.org; Sat, 25 May 2002 10:20:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10585; Sat, 25 May 2002 10:10:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10548 for ; Sat, 25 May 2002 10:10:51 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22572 for ; Sat, 25 May 2002 10:10:29 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4PE9XHt024619; Sat, 25 May 2002 16:09:43 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Sat, 25 May 2002 16:10:09 +0200 Received: from [192.168.1.5] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sat, 25 May 2002 16:10:09 +0200 Date: Sat, 25 May 2002 16:04:45 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , enum@ietf.org cc: rich.shockey@NeuStar.biz, michael@neonym.net Subject: Re: [Enum] enumservice role Message-ID: <7460049.1022342685@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 25 May 2002 14:10:09.0248 (UTC) FILETIME=[E0C20E00:01C203F5] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-25 00.11 +0100 Lawrence Conroy wrote: > I want to get the schema sets nailed down. I want this done now, and as > Richard points out, please keep it simple, folks, as there are several > trials people would rather like to get going. As long as people don't write don't examples, there is no reason arguing. We need examples. I can not make sense out of the last 5-6 messages on this list, because I don't understand what people talk about. If you have E2U+sip+voice, you use two enumservices, sip and voice. That is fine, but, people which suggest such things needs to describe what is meant by "sip" and what is defined by "voice". Without that description, there is no way we can move this discussion forward. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Sat May 25 13:51:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27604 for ; Sat, 25 May 2002 13:51:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA20248 for enum-archive@odin.ietf.org; Sat, 25 May 2002 13:51:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20034; Sat, 25 May 2002 13:42:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20003 for ; Sat, 25 May 2002 13:42:30 -0400 (EDT) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27357 for ; Sat, 25 May 2002 13:42:08 -0400 (EDT) Received: from user-2ivelb4.dialup.mindspring.com ([165.247.85.100] helo=dick.ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17BfYc-0000pX-00 for enum@ietf.org; Sat, 25 May 2002 13:42:23 -0400 Message-Id: <5.1.0.14.2.20020525134533.021be100@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 25 May 2002 13:47:35 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Internet Society Press Release on ITU - IAB interum agreement on RFC2916 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org http://www.isoc.org/isoc/media/releases/020524pr.shtml FOR IMMEDIATE RELEASE: 24 May 2002 Interim Approval for Internet Telephone Numbering System (ENUM) Provisioning -- Countries wishing to implement ENUM system may now do so. -- System offers promise of standardized international Voice and Video on IP services. Washington, DC - May 24, 2002 - The International Telecommunication Union (ITU) and the Internet Architecture Board (IAB) announce interim approval for a single domain for ENUM, a technology that builds a bridge between the public switched telephone network and the Internet. Voice on IP networks today operate by translating telephone numbers to IP addresses and placing an H.323 or SIP call to the device. The interchange format and translation record has not heretofore been standardized, limiting the possibility of deployment of multi- corporate and international Voice on IP services. Under the ENUM proposal, E.164 numbers can be represented as Internet Domain Names,providing a scalable and standard way to translate the numbers, and opening the way to such services. ITU has begun approving delegations for the purposes of trials. "The lack of an interoperable standard way to turn a telephone number into an IP Address has been one factor limiting the deployment of Voice on IP services internationally", said Leslie Daigle, Chair of the Internet Architecture Board. If desk-mounted computers or servers are given telephone numbers as well as mnemonic names, this system further enables common telephone handsets to place Voice or Video on IP calls to such computers. This is a significant step towards integrating Internet-based services with the global telephone network, and the current agreements between IAB and ITU will allow trials to take place. Patrik Faltstrom, member of the Internet Engineering Steering Group (IESG), said that "the integration of the desktop telephone and computer allows corporations to simplify their internal networks." Roy Blane, Chair of ITU-T's Study Group 2, concurred, saying that "In the long term this protocol may facilitate many new internet services. In the short term, countries wishing to trial the system can begin work on developing it." This interim approval is made possible due to cooperation between ITU, IAB and the Internet Engineering Task Force (IETF). As outlined in the ENUM specification document, RFC 2916, sub-domains from a single domain will be delegated after acceptance by the registries according to the existing assignment of country codes in the telephone address space. Information on how the ENUM registration requests will be processed can be found at http://www.ripe.net/enum/ About ISOC The Internet Society is a non-profit, non-governmental, open membership organization whose worldwide individual and organization members make up a veritable "who's who" of the Internet industry. It provides leadership in technical and operational standards, policy issues, and education. ISOC is the organizational home of the International Engineering Task Force, the Internet Architecture Board, the Internet Engineering Steering Group, and the Internet Research Task Force - the standards setting and research arms of the Internet community. About the IETF The Internet Engineering Task Force is an international community of network designers, operators,vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. The definition of the ENUM protocol, as proposed by the IETF can be found at http://www.ietf.org/rfc/rfc2916.txt. The IETF is an organized activity of the Internet Society. About ITU The International Telecommunication Union (ITU) is a global organization where the public and private sectors cooperate for the development of telecommunications and the harmonization of national telecommunications policies. Study Group 2 of the ITU Telecommunication Standardization Sector (ITU-T), where work on ENUM is being carried out, is the Lead Study Group on Service definition, Numbering, Routing and Global Mobility and is responsible for the operational aspects of service provision, networks and performance. More information on the ENUM protocol, and the issues related to it, can be found at http://www.itu.int/ITU-T/worksem/enum/index.html. POC: Patrik Fltstrm Leslie Daigle Scott Bradner Roy Blane Richard Hill Lynn St.Amour >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun May 26 10:42:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24469 for ; Sun, 26 May 2002 10:42:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13021 for enum-archive@odin.ietf.org; Sun, 26 May 2002 10:43:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12646; Sun, 26 May 2002 10:33:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12615 for ; Sun, 26 May 2002 10:33:09 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24288 for ; Sun, 26 May 2002 10:32:44 -0400 (EDT) Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090209 for ; Sun, 26 May 2002 15:32:34 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Sun, 26 May 2002 15:32:04 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] SchemaSet strawman Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi folks, as promised... summary of the outline schemas. I'll describe the URI-schemes to go with these in another post. Andrew suggests: talk -- intention is to engage in an interactive telephony communication srs/inquire/(enquire) -- intention is to act as a service resolution service deliver -- intention is to deliver a message (deposit a page or snippet of media) chat -- intention is to engage in a session-oriented text exchange video or see - [I'm not clear about this one - clarification?] share -- intention is to engage in workflow or whiteboard Clive suggests 'texttalk' instead of chat, to allow tdd phone usage. From some other discussions I had in mind: talk/phone -- interactive telephony communication here (Note that this doesn't mean exclusively audio - it could be videotelephony) srs -- intention is to act as a service resolution service (e.g. sip: or maybe ldap:) message -- intention is to deliver a message (this could be SMS, or fax, or email of its many kinds, or non-session oriented IM, or ..) streaming -- intention is that there is a streaming resource here (e.g. rtsp:). Note that a streaming service is not bi-directional. Thus it differs from the interactive telephony service implied by 'talk' file/info -- intention is that there is a resource here to get information (e.g. http:, https:, ftp:, ...) ... Patrik suggests: 'sip' -- I think this has the same goal as the existing sip-e164 draft, modulo syntax changes to fit with 2916bis. It is similar to the 'srs' function. 'voice' -- I think that this is similar to the 'talk' function described above, but seems to specify that the result will be voice only (i.e. not video & voice) and it might also allow VPIM messages - I hope not, but this would need to be clarified. Rich suggests that a registrant should be able to provide a NAPTR without specifying the capabilities or preference policies associated with a resource identified within the (global) DNS. Thus, given that there is at least one enumservice sub-field in each NAPTR, I'd suggest that we add an "any" enumservice ("unspecified" works too, but "any" is shorter :). In this way, a NAPTR with this enumservice does not expose its applicability to DNS requesters. Also, given that there may be more than one enumservice sub-field within a single NAPTR (and given that this may be abnormal), the presence of "any" together with one or more other enumservices within a single NAPTR means that it can be considered not only for the other specified functions, but for all functions - if the registrant does not wish to specify anything further, I'd suggest that then any other enumservice sub-fields present should be ignored. Although this seems to be a bizarre usage (having "any" plus some specific enumservice), I think it MAY be used in some obscure non-terminal processing cases. Any clarification here would be greatly appreciated. As an aside, this point on privacy is well taken. Any definition of "tel:" URI parameter "svc" as proposed by Richard should specify "svc=any" as an acceptable value; of course, in this case one may choose not to insert the URI parameter at all. additions/mods/outrage welcomed. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun May 26 10:47:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24515 for ; Sun, 26 May 2002 10:47:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13091 for enum-archive@odin.ietf.org; Sun, 26 May 2002 10:47:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12899; Sun, 26 May 2002 10:38:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12870 for ; Sun, 26 May 2002 10:38:40 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24411 for ; Sun, 26 May 2002 10:38:15 -0400 (EDT) Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090210 for ; Sun, 26 May 2002 15:38:18 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Sun, 26 May 2002 15:38:03 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] enumservices & URI-scheme Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi again folks, Now for the URI-schemes that can be used with the functions of the SchemaSet strawman. First, note that these URI-schemes must be specified at least for the non-terminal case; if a non-terminal is received, the service field is all that the application has. That means, as filtering cannot be done on the URI-scheme (there *is* no URI with a non-terminal) the enumservice alone must allow the application to know whether or not the outcome of following this path is going to be useful. The application has to be able to answer the question "does it have support for the URIs that may result from 'following' this non-terminal to the end"? A good example of this occurs where a non-terminal NAPTR has the enumservice 'talk' and the client only supports the "mailto:" URI. As "mailto:" is not in the list of URI-schemes that 'talk' can use, the client can discard the NAPTR immediately (I tend to think that a VPIM feature is a message rather than a talk function). So... 'talk'/'phone' can use "sip:", "tel:", or "h323:". 'voice' might use "sip:", "tel:", or "h323:". This may be a pure subset of 'talk' 'video'/'see' can use "h323:" or "sip:" and might, I guess, use "tel:". Again, this may be a pure subset of 'talk' 'message'/'deliver' can use "mailto:", "tel:" with "svc=fax" or "svc=sms" or "svc=mms", or "sip:" (where this leads to a non-session-oriented IM message) 'file'/'info' can use "http:" or "ftp:" or "https:" or "sftp:" to indicate the address of the information in question. (I strongly expect this to be used mostly with "http:" to indicate the "home page" of the registrant). 'srs'/'inquire'/'enquire' can be used with "sip:" or with "ldap:". At present, we have the "sip-e164" draft to cover this one; someone needs to add thought to how "ldap:" or any other srs protocol might be used. 'chat'/'textchat' can use "sip:" (where this leads to a session-oriented IM exchange), "tel:" with "svc=tdd" 'streaming' can use "rtsp:" 'share' can use, I guess, "h323:" or "wb:" or possibly "sip:" ---- ---- Given the discussion so far on enumservices, I wonder what the service field syntax should be? Michael has suggested that we go for: -+ As Patrik points out, one of the changes in 2916bis is to allow more than one enumservice sub-field per NAPTR. Thus, the syntax gets a little tricky here. I guess that something like: - 1*( + ) is better - i.e. have the URI scheme immediately after the 'E2U' D3S application tag, and before any enumservice list. It also covers the case where there IS no URI-scheme, as would occur with a non-terminal. (e.g. E2U-+talk). again, comments gratefully received. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun May 26 11:44:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24938 for ; Sun, 26 May 2002 11:44:47 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA14952 for enum-archive@odin.ietf.org; Sun, 26 May 2002 11:45:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14843; Sun, 26 May 2002 11:36:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14811 for ; Sun, 26 May 2002 11:36:18 -0400 (EDT) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24880 for ; Sun, 26 May 2002 11:35:53 -0400 (EDT) Received: from user-uivenll.dsl.mindspring.com ([165.247.94.181] helo=dick.ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 17C03z-0000Cr-00; Sun, 26 May 2002 11:36:09 -0400 Message-Id: <5.1.0.14.2.20020526112321.022b5a78@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 26 May 2002 11:39:23 -0400 To: Lawrence Conroy , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] SchemaSet strawman In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org >Clive suggests 'texttalk' instead of chat, to allow tdd phone usage. > > > From some other discussions I had in mind: >talk/phone -- interactive telephony communication here (Note that this >doesn't mean exclusively audio - it could be videotelephony) >srs -- intention is to act as a service resolution service (e.g. sip: or >maybe ldap:) >message -- intention is to deliver a message (this could be SMS, or fax, >or email of its many kinds, or non-session oriented IM, or ..) >streaming -- intention is that there is a streaming resource here (e.g. >rtsp:). Note that a streaming service is not bi-directional. Thus it >differs from the interactive telephony service implied by 'talk' >file/info -- intention is that there is a resource here to get information >(e.g. http:, https:, ftp:, ...) this looks increasingly ugly to me ... I just dont like it at all. but if you feel you must my general feeling is that the NAPTR field probably should follow some general convention such as ++ with the assumption that some protocols can provide different types of services such as SMTP or tel etc . >'voice' -- I think that this is similar to the 'talk' function described >above, but seems to specify that the result will be voice only (i.e. not >video & voice) and it might also allow VPIM messages - I hope not, but >this would need to be clarified. Please can we let the VPIM people define how they wish to create enumservice fields. I've yet to hear a rational argument ..that in the case of the protocol SIP ..you need any of this ...WHY WHY do you need to say anything about talk or voice or video or IM or .. or anything ... If you have 2 NAPTR records that are SIP and one can only to text and the other one can only do voice ..then simply contact both if either proxy are properly configured it will define rules for each service type and reinvite the session. >Rich suggests that a registrant should be able to provide a NAPTR without >specifying the capabilities or preference policies associated with a >resource identified within the (global) DNS. Yes thank you ... I would prefer not to help create the greatest spamming database in the known world. >Thus, given that there is at least one enumservice sub-field in each NAPTR, >I'd suggest that we add an "any" enumservice ("unspecified" works too, but >"any" is shorter :). In this way, a NAPTR with this enumservice does not >expose its applicability to DNS requesters. NO ..just leave it blank ... E2U+SIP E2U+SMTP the use of "any" itself is an exposure of capability. your whole service field should be optional... >Also, given that there may be more than one enumservice sub-field within a >single NAPTR (and given that this may be abnormal), the presence of "any" >together with one or more other enumservices within a single NAPTR means >that it can be considered not only for the other specified functions, but >for all functions - if the registrant does not wish to specify anything >further, I'd suggest that then any other enumservice sub-fields present >should be ignored. >Although this seems to be a bizarre usage (having "any" plus some specific >enumservice), I think it MAY be used in some obscure non-terminal >processing cases. Any clarification here would be greatly appreciated. all forms of service in the following structure should be optional PERIOD ..++ >As an aside, this point on privacy is well taken. Any definition of "tel:" >URI parameter "svc" as proposed by Richard should specify "svc=any" as an >acceptable value; of course, in this case one may choose not to insert the >URI parameter at all. > >additions/mods/outrage welcomed. tel is presumably the PSTN but again ... it might be useful to have E2U+tel+TDD orto find a terminal that is capable of text messaging for the hearing impared or something like that or E2U+tel+fax for PSTN fax terminal.. >all the best, > Lawrence >-- >lwc@roke.co.uk: +44 1794 833666::: > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun May 26 13:09:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26418 for ; Sun, 26 May 2002 13:09:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19155 for enum-archive@odin.ietf.org; Sun, 26 May 2002 13:09:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18727; Sun, 26 May 2002 13:00:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18666 for ; Sun, 26 May 2002 13:00:44 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26337 for ; Sun, 26 May 2002 13:00:22 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4QGxVoe028387; Sun, 26 May 2002 18:59:36 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Sun, 26 May 2002 19:00:11 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 26 May 2002 19:00:10 +0200 Date: Sun, 26 May 2002 18:55:02 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] enumservices & URI-scheme Message-ID: <11179530.1022439302@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 26 May 2002 17:00:11.0620 (UTC) FILETIME=[CC423A40:01C204D6] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-26 15.38 +0100 Lawrence Conroy wrote: > So... > > 'talk'/'phone' can use "sip:", "tel:", or "h323:". Note that with sip, the negotiation of functionality happens inside the sip protocol, and what you can do (talk/see/chat etc) might depend on authentication, access rights, time of day, availability etc etc. So, I don't understand how you can promise in a static NAPTR record that a sip URI scheme might lead to talk. I.e. what function you can get from a given URI is not very often (as I understand it) known before you start using the URI. I have from for example SIP community heard very strong opposition to have enumservices specify a function. So, I need more meat from people really defining enumservices before I continue mentally down this path. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun May 26 13:09:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26435 for ; Sun, 26 May 2002 13:09:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19169 for enum-archive@odin.ietf.org; Sun, 26 May 2002 13:10:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18732; Sun, 26 May 2002 13:00:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18663 for ; Sun, 26 May 2002 13:00:44 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26336 for ; Sun, 26 May 2002 13:00:21 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4QGxVoc028387; Sun, 26 May 2002 18:59:35 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Sun, 26 May 2002 19:00:08 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 26 May 2002 19:00:07 +0200 Date: Sun, 26 May 2002 18:50:23 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] SchemaSet strawman Message-ID: <11162815.1022439023@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 26 May 2002 17:00:07.0839 (UTC) FILETIME=[CA014AF0:01C204D6] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit What people have written is definitly not enough for saying anything of what it all is about. People which suggest enumservices must write down what the selection critera is. Your summary is correct, but, it is also dangerous to draw too many conclusions of what other people write. I for example, and not suggested any services at all. As I am not a person writing a client which might handle the TEL URI scheme, I don't know whether I need to know more than the fact that TEL is used. I.e. we need more text from the ones which want enumservices. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun May 26 14:03:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27081 for ; Sun, 26 May 2002 14:03:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21083 for enum-archive@odin.ietf.org; Sun, 26 May 2002 14:03:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20322; Sun, 26 May 2002 13:54:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20291 for ; Sun, 26 May 2002 13:54:44 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26992 for ; Sun, 26 May 2002 13:54:21 -0400 (EDT) Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090211; Sun, 26 May 2002 18:54:22 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20020526112321.022b5a78@popd.ix.netcom.com> References: <5.1.0.14.2.20020526112321.022b5a78@popd.ix.netcom.com> Date: Sun, 26 May 2002 18:42:41 +0100 To: Richard Shockey From: Lawrence Conroy Subject: Re: [Enum] SchemaSet strawman Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org (Redirecting to other thread on role of service field and enumservices):: At 11:39 am -0400 26/5/02, Richard Shockey wrote: (as comments on the schema set strawman) >>Clive suggests 'texttalk' instead of chat, to allow tdd phone usage. >> >> >>From some other discussions I had in mind: >>talk/phone -- interactive telephony communication here (Note that >>this doesn't mean exclusively audio - it could be videotelephony) >>srs -- intention is to act as a service resolution service (e.g. >>sip: or maybe ldap:) >>message -- intention is to deliver a message (this could be SMS, or >>fax, or email of its many kinds, or non-session oriented IM, or ..) >>streaming -- intention is that there is a streaming resource here >>(e.g. rtsp:). Note that a streaming service is not bi-directional. >>Thus it differs from the interactive telephony service implied by >>'talk' >>file/info -- intention is that there is a resource here to get >>information (e.g. http:, https:, ftp:, ...) > > >this looks increasingly ugly to me ... I just dont like it at all. > >but if you feel you must my general feeling is that the NAPTR >field probably should follow some general convention such as scheme>++ with the assumption that some >protocols can provide different types of services such as SMTP or >tel etc . > >>'voice' -- I think that this is similar to the 'talk' function >>described above, but seems to specify that the result will be voice >>only (i.e. not video & voice) and it might also allow VPIM messages >>- I hope not, but this would need to be clarified. > > >Please can we let the VPIM people define how they wish to create >enumservice fields. > > >I've yet to hear a rational argument ..that in the case of the >protocol SIP ..you need any of this ...WHY WHY do you need to say >anything about talk or voice or video or IM or .. or anything ... If >you have 2 NAPTR records that are SIP and one can only to text and >the other one can only do voice ..then simply contact both if either >proxy are properly configured it will define rules for each service >type and reinvite the session. > > >>Rich suggests that a registrant should be able to provide a NAPTR >>without specifying the capabilities or preference policies >>associated with a resource identified within the (global) DNS. > >Yes thank you ... I would prefer not to help create the greatest >spamming database in the known world. > >>Thus, given that there is at least one enumservice sub-field in each NAPTR, >>I'd suggest that we add an "any" enumservice ("unspecified" works >>too, but "any" is shorter :). In this way, a NAPTR with this >>enumservice does not expose its applicability to DNS requesters. > >NO ..just leave it blank ... E2U+SIP E2U+SMTP the use of >"any" itself is an exposure of capability. your whole service field >should be optional... > >>Also, given that there may be more than one enumservice sub-field >>within a single NAPTR (and given that this may be abnormal), the >>presence of "any" together with one or more other enumservices >>within a single NAPTR means that it can be considered not only for >>the other specified functions, but for all functions - if the >>registrant does not wish to specify anything further, I'd suggest >>that then any other enumservice sub-fields present should be >>ignored. >>Although this seems to be a bizarre usage (having "any" plus some >>specific enumservice), I think it MAY be used in some obscure >>non-terminal processing cases. Any clarification here would be >>greatly appreciated. > >all forms of service in the following structure should be optional >PERIOD ..++ > >>As an aside, this point on privacy is well taken. Any definition of >>"tel:" URI parameter "svc" as proposed by Richard should specify >>"svc=any" as an acceptable value; of course, in this case one may >>choose not to insert the URI parameter at all. >> >>additions/mods/outrage welcomed. > > >tel is presumably the PSTN but again ... it might be useful to have >E2U+tel+TDD orto find a terminal that is capable of text messaging >for the hearing impared or something like that or E2U+tel+fax for >PSTN fax terminal.. > To which I reply: Hi Rich, folks, I thought that protocol is as defined for registered URI-schemes, so protocol proximates to URI-scheme. Is this incorrect? Follow ups on syntax please to "enumservices & URI-scheme" thread. See the proposal I collected/made in the "enumservices & URI-scheme" thread. In short: Using a "-" rather than a "+" to distinguish the URI-scheme sub-field from subsequent enumservice sub-fields is intended to make parsing easier. The URI-scheme sub-field may be missing (in the case of non-terminals). IMHO, optional (or null) sub-fields make parsing more of a challenge. I clarify - the "any" means unspecified or any - it's exactly the same as (blank / missing) sub-field value. It does not expose anything more or less than leaving the field blank. ---- Follow ups on role of enumservice to "enumservice role" thread, please. I absolutely do not intend to do anything on VPIM services - I'm no expert on this arcana (Is anyone ?). Your comment that this is not needed with SIP - hey, 99% of the whole shebang is not needed if all you want is to populate the DNS with *a* SIP URL associated with the E164 number. Hmm..this could be registered with the SIP proxy/registrar anyway, so why do I need... That way lies the universe where the US is +666. If the registrant doesn't want to put this information in to indicate that their .net account is going to be IM whilst their siptest account is going to be for voice, they don't have to do this. Absolutely agree that you can try both. Assuming that the proxy/registrar for each of the accounts is aware of the other one it will work fine. However, IF the information is available then I'd like to use this in the client to short-circuit this. I'd sure like to display it in the UI (as you work in Washington D.C. rather than Washington State, I expect that you were thinking of displaying this before the client program went off and did something ?). Question: From your comments, you think that at least the enumservice sub-field(s) is ugly/not useful. Is this correct? If so, then why do we need to update 2916 at all; there's already a URI-scheme/"resolution protocol" sub-field in that? Taking a more radical approach, you say that the whole of the services field content should be optional (I guess you mean except for the "E2U" tag, as this is needed to delineate ENUM from some other D3S application). Is this a proposal for a re-cast of 2916, making the "resolution protocol" sub-field optional? It's a bit late in the day, but ... And finally, folks, am I alone in having twats waste the paper in my fax machine suggesting I phone their premium rate number to express my views/...? ENUM may be potentially the greatest spamming database in the whole world, but some folks seem to have such a database already...and, yes, I do hope their other one falls off. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun May 26 14:09:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27162 for ; Sun, 26 May 2002 14:09:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21363 for enum-archive@odin.ietf.org; Sun, 26 May 2002 14:10:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21035; Sun, 26 May 2002 14:01:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21004 for ; Sun, 26 May 2002 14:01:07 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27040 for ; Sun, 26 May 2002 14:00:44 -0400 (EDT) Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090212; Sun, 26 May 2002 19:00:43 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <11162815.1022439023@localhost> References: <11162815.1022439023@localhost> Date: Sun, 26 May 2002 19:00:25 +0100 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , enum@ietf.org From: Lawrence Conroy Subject: Re: [Enum] SchemaSet strawman Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA21005 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 6:50 pm +0200 26/5/02, Patrik Fältström wrote: >What people have written is definitly not enough for saying anything of >what it all is about. People which suggest enumservices must write down >what the selection critera is. > >Your summary is correct, but, it is also dangerous to draw too many >conclusions of what other people write. > >I for example, and not suggested any services at all. As I am not a person >writing a client which might handle the TEL URI scheme, I don't know >whether I need to know more than the fact that TEL is used. > >I.e. we need more text from the ones which want enumservices. > > paf Hi Patrik, folks, I apologies for any mis-attribution - in an earlier post you said that you had made a proposal. I looked and the only ones I could see where telvoice and sipvoice, and then sip+voice, which I incorrectly assumed were potential enumservices "sip" and "voice". In an attempt to be inclusive for the strawman, I included these. Agreed, there needs to be more text before any client could fathom out what to do with any of these enumservices. I hope others will join in. One question - what do you mean by "selection criteria"? all the best Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun May 26 15:11:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27696 for ; Sun, 26 May 2002 15:11:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA23569 for enum-archive@odin.ietf.org; Sun, 26 May 2002 15:12:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23488; Sun, 26 May 2002 15:01:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23457 for ; Sun, 26 May 2002 15:01:53 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27636 for ; Sun, 26 May 2002 15:01:29 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4QJ0h1X003111; Sun, 26 May 2002 21:00:44 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Sun, 26 May 2002 21:01:21 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 26 May 2002 21:01:20 +0200 Date: Sun, 26 May 2002 21:01:01 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] SchemaSet strawman Message-ID: <11633049.1022446861@localhost> In-Reply-To: References: <11162815.1022439023@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 26 May 2002 19:01:20.0793 (UTC) FILETIME=[B9060090:01C204E7] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-26 19.00 +0100 Lawrence Conroy wrote: > One question - what do you mean by "selection criteria"? When a client see two NAPTR records, with two different enumservices, what is the difference between the two? How is the client to know which one to pick? paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 05:56:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15579 for ; Mon, 27 May 2002 05:56:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA04629 for enum-archive@odin.ietf.org; Mon, 27 May 2002 05:57:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04098; Mon, 27 May 2002 05:48:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04026 for ; Mon, 27 May 2002 05:48:27 -0400 (EDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15460 for ; Mon, 27 May 2002 05:48:04 -0400 (EDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id g4R9mMd11895; Mon, 27 May 2002 09:48:22 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.35 #1) id 17CH6x-000NZf-00; Mon, 27 May 2002 10:48:19 +0100 Date: Mon, 27 May 2002 10:48:19 +0100 From: "Clive D.W. Feather" To: Richard Shockey Cc: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] enumservices - the story so far Message-ID: <20020527094819.GF84064@finch-staff-1.demon.net> References: <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> User-Agent: Mutt/1.3.27i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Richard Shockey said: >> Clive (message of Thursday at 1510Z) suggests that carrying all of this >> data in the services field is a duplication and that it is far better to >> parse the NAPTR. This over-summarises my position. > once the set of records is returned it makes more sense to sort on the > services field first ..even if similar data is contained in the URI within > in the regexp What if the NAPTR *doesn't* agree with the services field ? For example, if services is E2U+tel+SMS but the NAPTR ends up generating a mailto: URL ? I'm not seeing a clear explanation of what is in the services field and what is in the URL, why the same information needs to be in both, and what happens if they disagree. As such, it feels like bad design. -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 05:57:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15596 for ; Mon, 27 May 2002 05:57:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA04644 for enum-archive@odin.ietf.org; Mon, 27 May 2002 05:57:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04007; Mon, 27 May 2002 05:48:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03978 for ; Mon, 27 May 2002 05:48:05 -0400 (EDT) Received: from oefeg-mail.oefeg.at ([62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15452 for ; Mon, 27 May 2002 05:47:41 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Mon, 27 May 2002 11:34:50 +0200 Message-ID: From: "Stastny, Richard" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Lawrence Conroy , enum@ietf.org Cc: rich.shockey@neustar.com Subject: RE: [Enum] SchemaSet strawman Date: Mon, 27 May 2002 11:34:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Folks, I am a bit confused with this discussion: Patrik and Rich request more information from people which want enumservices, and also they want to see a (draft) RFC for each enumservice, but on the other hand each proposal coming in is either not fitting into the D3S scheme or to ugly or to complicated;-) As far as the proposals are concerned, we have on one extreme side the "sip" group, which only needs "E2U+sip" and do not see any further need for other enumservices, on the other side the "other URIs and services also group", which see the thing more differentiated, thus ending up with every potential service listed (and a lot of people between the two extremes). If I add Patriks request, that an application needs to have all information required to select a NAPTR in the enumservices field, the latter group seems to be correct. The problem I see here is, that we cannot use the service parameters as proposed in section 2.4.2 of RFC2916bis: service_field = [ "E2U" 1*("+" enumservice)] because we have different flavors of "enumservice"s. If we use a scheme similar the one proposed by Michael: -+ Or - 1*( + ) from Lawrence this generic scheme NEED to be defined in RFC2916bis. As long a this question has not been clarified, it does not make sense to make any concrete proposals: IMHO opinion we should first try to get the whole picture, like a common consensus on how all currently envisaged service fit in this picture. A good starter for this is the proposal from Lawrence: 'talk'/'phone' can use "sip:", "tel:", or "h323:". 'voice' might use "sip:", "tel:", or "h323:". This may be a pure subset of 'talk' 'video'/'see' can use "h323:" or "sip:" and might, I guess, use "tel:". Again, this may be a pure subset of 'talk' 'message'/'deliver' can use "mailto:", "tel:" with "svc=fax" or "svc=sms" or "svc=mms", or "sip:" (where this leads to a non-session-oriented IM message) 'file'/'info' can use "http:" or "ftp:" or "https:" or "sftp:" to indicate the address of the information in question. (I strongly expect this to be used mostly with "http:" to indicate the "home page" of the registrant). 'srs'/'inquire'/'enquire' can be used with "sip:" or with "ldap:". At present, we have the "sip-e164" draft to cover this one; someone needs to add thought to how "ldap:" or any other srs protocol might be used. 'chat'/'textchat' can use "sip:" (where this leads to a session-oriented IM exchange), "tel:" with "svc=tdd" 'streaming' can use "rtsp:" 'share' can use, I guess, "h323:" or "wb:" or possibly "sip:" Plus the also proposed 'any' To clarify: what is important here is not the names (chat or textchat), ii is the semantic. I also agree with the statement, that we should avoid duplicate names for enumservices, services and URIs, so no enumservice should be named mailto or sip. So I propose that we first agree on these generic enumservices scheme, and than specific proposals may be forwarded by the specialists of the services themselves. Any proposed scheme must solve for example my problem: I want to announce 3 services in ENUM: a phone, a fax and an sms enabled number. There may be the two extremes and any combination between: 1. All services are on one E.164 number (e.g. a sms-enabled fixed number) 2. The services are all on differnt E.164 numbers, all with tel: URIs Question: How does the one? NAPTR record look like in the first case, and how does the three NAPTR records look the second case. I a scheme does not solve this problem, it is useless. I also want to forward another problem we detected with defining the trials: The definition of the enumservices is not only important for the client applications resolving the NAPTR records, it is also important for the user-interface for entering data to the DNS. This issue has never been discussed, but we should keep in mind, that there has to be a web-portal provided by the Tier 2 Name Service providers, which enables "normal" users to enter their data to the DNS. Since we cannot expect the normal users to be D3S and NAPTR experts, we also have to provide some "translation". How does e.g. a user friendly webpage look for the above mentioned example. Does the user have to know, how many NAPTR records have to be created for a give combination? Best regards Richard Richard STASTNY OeFEG/Telekom Austria Box 147, A-1103 Vienna, Austria tel:+43 664 420 4100 fax:+43 1 797 80 13 mailto:richard.stastny@oefeg.at _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 06:19:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15767 for ; Mon, 27 May 2002 06:19:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA05845 for enum-archive@odin.ietf.org; Mon, 27 May 2002 06:19:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05591; Mon, 27 May 2002 06:11:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA05560 for ; Mon, 27 May 2002 06:11:11 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15694 for ; Mon, 27 May 2002 06:10:46 -0400 (EDT) Received: from [193.118.205.14] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090227; Mon, 27 May 2002 11:10:47 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <20020527094819.GF84064@finch-staff-1.demon.net> References: <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <20020527094819.GF84064@finch-staff-1.demon.net> Date: Mon, 27 May 2002 11:10:30 +0100 To: "Clive D.W. Feather" From: Lawrence Conroy Subject: Re: [Enum] enumservices - the story so far Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10:48 am +0100 27/5/02, Clive D.W. Feather wrote: >Richard Shockey said: >>> Clive (message of Thursday at 1510Z) suggests that carrying all of this >>> data in the services field is a duplication and that it is far better to >>> parse the NAPTR. > >This over-summarises my position. > >> once the set of records is returned it makes more sense to sort on the >> services field first ..even if similar data is contained in the URI within >> in the regexp > >What if the NAPTR *doesn't* agree with the services field ? For example, if >services is E2U+tel+SMS but the NAPTR ends up generating a mailto: URL ? > >I'm not seeing a clear explanation of what is in the services field and >what is in the URL, why the same information needs to be in both, and what >happens if they disagree. As such, it feels like bad design. > To which I reply: Hi Clive, folks, first, sorry about over-summarising you position. Further to your point above, it gets better if we have non-terminals. What if one round of non-terminal processing reports one URI-scheme and/or enumservice, and the next round of D3S lookup gives a NAPTR set with different (disjoint) URI-schemes and/or enumservices? How the heck do I run the admin system (to check on consistency of URI or enumservice data in non-terminal NAPTRs), so that a mere mortal will understand the error messages it sends them (Ignoring the performance requirements for chasing D3S "links" when doing this)? That's the case even if we only have enumservice sub-fields (leaving the regexp-reconstructed URI to hold its own data). all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 08:07:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17031 for ; Mon, 27 May 2002 08:07:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA11165 for enum-archive@odin.ietf.org; Mon, 27 May 2002 08:07:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10348; Mon, 27 May 2002 07:59:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10317 for ; Mon, 27 May 2002 07:59:01 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16843 for ; Mon, 27 May 2002 07:58:37 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4RBvp6x017496; Mon, 27 May 2002 13:57:52 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Mon, 27 May 2002 13:58:28 +0200 Received: from [10.0.1.4] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 27 May 2002 13:58:26 +0200 Date: Mon, 27 May 2002 13:32:27 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , Lawrence Conroy , enum@ietf.org cc: rich.shockey@neustar.com Subject: RE: [Enum] SchemaSet strawman Message-ID: <12807779.1022506347@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 27 May 2002 11:58:28.0252 (UTC) FILETIME=[D0393DC0:01C20575] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-27 11.34 +0200 "Stastny, Richard" wrote: > I want to announce 3 services in ENUM: a phone, a fax and an sms enabled > number. There may be the two extremes and any combination between: > > 1. All services are on one E.164 number (e.g. a sms-enabled fixed number) > 2. The services are all on differnt E.164 numbers, all with tel: URIs You use tel uri and nothing else. Then you probably need one enumservice for the phone where you do voice, one for the tel uri where you do fax and one for the tel uri where you do sms. Especially as they use different E.164 numbers. So, for each number, you have one NAPTR which specify whatever enumservice you define. If people need to differentiate between tel uri for voice and tel uri for fax, then that needs to be in the enumservicefield. This is by the way I have heard. If you used SIP instead, the sip people say that one URI is enough, and negotiation is done inside the sip negotiation phase, so only one NAPTR is enough which have one enumservice regardless of whether it is phone, fax or pager. I.e. we need MUCH more information from people which actually will use the NAPTR. Technical information. > Question: > How does the one? NAPTR record look like in the first case, and how does > the three NAPTR records look the second case. I a scheme does not solve > this problem, it is useless. As you have three different E.164, there will be three different NAPTR. If you have one number which you publish which will lead to the three different services, then you have three NAPTR aswell, each one of them via the rewrite lead to a different tel URI. I.e. the final URI's people get will be different. Have to be different. > I also want to forward another problem we detected with defining the > trials: The definition of the enumservices is not only important for the > client applications resolving the NAPTR records, it is also important for > the user-interface for entering data to the DNS. This issue has never been > discussed, but we should keep in mind, that there has to be a web-portal > provided by the Tier 2 Name Service providers, which enables "normal" > users to enter their data to the DNS. I would never ever have "web" interface to a DNS I run! For security reasons if nothing else. > Since we cannot expect the normal > users to be D3S and NAPTR experts, we also have to provide some > "translation". How does e.g. a user friendly webpage look for the above > mentioned example. Does the user have to know, how many NAPTR records > have to be created for a give combination? How the translation is to be done is up to the "enumserviceproviders". An excellent for _NON_ standardization and instead competition can work. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 08:52:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17643 for ; Mon, 27 May 2002 08:52:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA12918 for enum-archive@odin.ietf.org; Mon, 27 May 2002 08:51:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12602; Mon, 27 May 2002 08:42:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12573 for ; Mon, 27 May 2002 08:42:27 -0400 (EDT) Received: from oefeg-mail.oefeg.at ([62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17380 for ; Mon, 27 May 2002 08:41:52 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Mon, 27 May 2002 14:28:46 +0200 Message-ID: From: "Stastny, Richard" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "Stastny, Richard" , Lawrence Conroy , enum@ietf.org Cc: rich.shockey@neustar.com Subject: RE: [Enum] SchemaSet strawman Date: Mon, 27 May 2002 14:28:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA12574 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik wrote, to which I respond: > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Monday, May 27, 2002 1:32 PM > To: Stastny, Richard; Lawrence Conroy; enum@ietf.org > Cc: rich.shockey@neustar.com > Subject: RE: [Enum] SchemaSet strawman > > > --On 2002-05-27 11.34 +0200 "Stastny, Richard" > > wrote: > > > I want to announce 3 services in ENUM: a phone, a fax and an sms > > enabled number. There may be the two extremes and any combination > > between: > > > > 1. All services are on one E.164 number (e.g. a sms-enabled fixed > > number) 2. The services are all on differnt E.164 numbers, all with > > tel: URIs > > You use tel uri and nothing else. Then you probably need one > enumservice for the phone where you do voice, one for the tel > uri where you do fax and one for the tel uri where you do > sms. Especially as they use different E.164 numbers. So, for > each number, you have one NAPTR which specify whatever > enumservice you define. If people need to differentiate > between tel uri for voice and tel uri for fax, then that > needs to be in the enumservicefield. > > This is by the way I have heard. Ok, the "simplfied" NAPTR records will then either look like: NAPTR blabla "E2U+tel+voice+fax+sms" blabla tel:+43179780;svc=voice;svc=fax;svc=sms Or NAPTR blabla "E2U+tel+voice" blabla tel:+4317978032;svc=voice NAPTR blabla "E2U+tel+fax" blabla tel:+4317978013;svc=fax NAPTR blabla "E2U+tel+sms" blabla tel:+436644204100;sms=sms > If you used SIP instead, the sip people say that one URI is > enough, and negotiation is done inside the sip negotiation > phase, so only one NAPTR is enough which have one enumservice > regardless of whether it is phone, fax or pager. > > I.e. we need MUCH more information from people which actually > will use the NAPTR. Technical information. > > > Question: > > How does the one? NAPTR record look like in the first case, and how > > does the three NAPTR records look the second case. I a > scheme does not > > solve this problem, it is useless. > > As you have three different E.164, there will be three > different NAPTR. > > If you have one number which you publish which will lead to > the three different services, then you have three NAPTR > aswell, each one of them via the rewrite lead to a different > tel URI. I.e. the final URI's people get will be different. > Have to be different. This I do not understand. So do I have now three times the same number, so the first of my examples is invalid? I have to write instead: NAPTR blabla "E2U+tel+voice" blabla tel:+4317978032;svc=voice NAPTR blabla "E2U+tel+fax" blabla tel:+4317978032;svc=fax NAPTR blabla "E2U+tel+sms" blabla tel:+4317978032;sms=sms Please clarify. > > > I also want to forward another problem we detected with defining the > > trials: The definition of the enumservices is not only > important for > > the client applications resolving the NAPTR records, it is also > > important for the user-interface for entering data to the DNS. This > > issue has never been discussed, but we should keep in mind, > that there > > has to be a web-portal provided by the Tier 2 Name Service > providers, > > which enables "normal" users to enter their data to the DNS. > > I would never ever have "web" interface to a DNS I run! For > security reasons if nothing else. > > > Since we cannot expect the normal > > users to be D3S and NAPTR experts, we also have to provide some > > "translation". How does e.g. a user friendly webpage look for the > > above mentioned example. Does the user have to know, how many NAPTR > > records have to be created for a give combination? > > How the translation is to be done is up to the > "enumserviceproviders". An excellent for _NON_ > standardization and instead competition can work. Agree, but there is a minor misunderstanding: I definitely do NOT want the "web" interface standardized, I only wanted to remember, that we should not only think about how clients are evaluating or parsing the NAPTRs, but also keep in mind, that on the other side the NAPTRs have to be generated by some software. And BTW, I do not really see a problem for a piece of SW to read in the complete set of NAPTRs and do some kind of calculation on it, e.g. peeking ahead in the URLs, if we can avoid some duplication of obvious information like in the examples above. Anyway, I do not really care, as long as we come to a conclusion a.s.a.p. Regards Richard > > paf > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 09:03:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18094 for ; Mon, 27 May 2002 09:03:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14334 for enum-archive@odin.ietf.org; Mon, 27 May 2002 09:04:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13193; Mon, 27 May 2002 08:55:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13108 for ; Mon, 27 May 2002 08:55:14 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17734 for ; Mon, 27 May 2002 08:54:50 -0400 (EDT) Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090230; Mon, 27 May 2002 13:54:51 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <12807779.1022506347@localhost> References: <12807779.1022506347@localhost> Date: Mon, 27 May 2002 13:54:32 +0100 To: Patrik , Richard From: Lawrence Conroy Subject: RE: [Enum] SchemaSet strawman Cc: enum@ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA13109 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 1:32 pm +0200 27/5/02, Patrik Fältström wrote: >--On 2002-05-27 11.34 +0200 "Stastny, Richard" >wrote: > >> I want to announce 3 services in ENUM: a phone, a fax and an sms enabled >> number. There may be the two extremes and any combination between: >> >> 1. All services are on one E.164 number (e.g. a sms-enabled fixed number) > > 2. The services are all on differnt E.164 numbers, all with tel: URIs >As you have three different E.164, there will be three different NAPTR. > >If you have one number which you publish which will lead to the three >different services, then you have three NAPTR aswell, each one of them via >the rewrite lead to a different tel URI. I.e. the final URI's people get >will be different. Have to be different. > >> I also want to forward another problem we detected with defining the >> trials: The definition of the enumservices is not only important for the >> client applications resolving the NAPTR records, it is also important for >> the user-interface for entering data to the DNS. This issue has never been >> discussed, but we should keep in mind, that there has to be a web-portal >> provided by the Tier 2 Name Service providers, which enables "normal" > > users to enter their data to the DNS. To which I reply: Hi Patrik, Richard, folks, To clarify, in case (2), there will be three NAPTRs as there will be three domains (or CNAMEs plus a NAPTR). Each of the discrete (terminal) NAPTRs will include a (regexp that will generate a) URI. The content of the URIs can be the same. (p.s. Re. security - 'web portal' includes https: I assume). all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 11:51:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20920 for ; Mon, 27 May 2002 11:51:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23265 for enum-archive@odin.ietf.org; Mon, 27 May 2002 11:52:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22898; Mon, 27 May 2002 11:38:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22870 for ; Mon, 27 May 2002 11:38:42 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20722 for ; Mon, 27 May 2002 11:38:19 -0400 (EDT) Received: from user-2ivel9t.dialup.mindspring.com ([165.247.85.61] helo=dick.ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17CMZy-0002IN-00; Mon, 27 May 2002 11:38:39 -0400 Message-Id: <5.1.0.14.2.20020527111808.02302f78@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 May 2002 11:22:06 -0400 To: "Clive D.W. Feather" From: Richard Shockey Subject: Re: [Enum] enumservices - the story so far Cc: enum@ietf.org In-Reply-To: <20020527094819.GF84064@finch-staff-1.demon.net> References: <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 10:48 AM 5/27/2002 +0100, Clive D.W. Feather wrote: >Richard Shockey said: > >> Clive (message of Thursday at 1510Z) suggests that carrying all of this > >> data in the services field is a duplication and that it is far better to > >> parse the NAPTR. > >This over-summarises my position. > > > once the set of records is returned it makes more sense to sort on the > > services field first ..even if similar data is contained in the URI within > > in the regexp > >What if the NAPTR *doesn't* agree with the services field ? For example, if >services is E2U+tel+SMS but the NAPTR ends up generating a mailto: URL ? What is the conflict with this .. this is actually a really good example of a very creative service !! The only way I prefer you to reach my mobile SMS end point is to use a SMTP gateway where I could a apply a spam filter ...I like this one !! I'll buy this!!! >I'm not seeing a clear explanation of what is in the services field and >what is in the URL, why the same information needs to be in both, and what >happens if they disagree. As such, it feels like bad design. >-- >Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 >Internet Expert | Home: | Fax: +44 870 051 9937 >Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 >Thus plc | | NOTE: fax number change >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 11:51:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20937 for ; Mon, 27 May 2002 11:51:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23279 for enum-archive@odin.ietf.org; Mon, 27 May 2002 11:52:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22943; Mon, 27 May 2002 11:39:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22911 for ; Mon, 27 May 2002 11:39:02 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20725 for ; Mon, 27 May 2002 11:38:39 -0400 (EDT) Received: from user-2ivel9t.dialup.mindspring.com ([165.247.85.61] helo=dick.ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17CMa2-0002IN-00; Mon, 27 May 2002 11:38:43 -0400 Message-Id: <5.1.0.14.2.20020527112404.03ef8960@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 May 2002 11:42:19 -0400 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Stastny, Richard" , Lawrence Conroy , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] SchemaSet strawman In-Reply-To: <12807779.1022506347@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA22912 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 01:32 PM 5/27/2002 +0200, Patrik Fältström wrote: >--On 2002-05-27 11.34 +0200 "Stastny, Richard" >wrote: > > > I want to announce 3 services in ENUM: a phone, a fax and an sms enabled > > number. There may be the two extremes and any combination between: > > > > 1. All services are on one E.164 number (e.g. a sms-enabled fixed number) > > 2. The services are all on differnt E.164 numbers, all with tel: URIs > >You use tel uri and nothing else. Then you probably need one enumservice >for the phone where you do voice, one for the tel uri where you do fax and >one for the tel uri where you do sms. Especially as they use different >E.164 numbers. So, for each number, you have one NAPTR which specify >whatever enumservice you define. If people need to differentiate between >tel uri for voice and tel uri for fax, then that needs to be in the >enumservicefield. Ah thank you Patrik ...yes tel+fax , tel+voice , tel+sms , tel+tdd ,etc. This is clearly a case for differentiation or "granularity" in the description of endpoint PSTN services that for lack of a better label is defined as [ tel ]. Plus I think the argument could be made that the needs and requirements for this form of differentiation justify the exposure of the data in the global DNS. I dont like it ...but if it is necessary then so be it. >This is by the way I have heard. > >If you used SIP instead, the sip people say that one URI is enough, and >negotiation is done inside the sip negotiation phase, so only one NAPTR is >enough which have one enumservice regardless of whether it is phone, fax or >pager. yes ... and the analogy to this is PSTN fax itself where negotiation of capabilities [T.30] is "on the wire" and does not require user preselection > > I also want to forward another problem we detected with defining the > > trials: The definition of the enumservices is not only important for the > > client applications resolving the NAPTR records, it is also important for > > the user-interface for entering data to the DNS. This issue has never been > > discussed, but we should keep in mind, that there has to be a web-portal > > provided by the Tier 2 Name Service providers, which enables "normal" > > users to enter their data to the DNS. > >I would never ever have "web" interface to a DNS I run! For security >reasons if nothing else. Patrik I know what he means a user interface and a script that would ultimately through some security and validation means actually write the NAPTR record for the FQDN. The desire is for users to actually create and control their ENUM services. Frankly I think its power user stuff since the vast majority of users IMHO will want some else (the service provider ) to do all of this dirty work and jsut make sure it works. A similar problem statement would be changing preference profiles is SIP through a mechanism that takes customer input and then writes the CPL script file at the egress proxy. > > Since we cannot expect the normal > > users to be D3S and NAPTR experts, we also have to provide some > > "translation". How does e.g. a user friendly webpage look for the above > > mentioned example. Does the user have to know, how many NAPTR records > > have to be created for a give combination? > >How the translation is to be done is up to the "enumserviceproviders". An >excellent for _NON_ standardization and instead competition can work. ditto exactly ... and N* has a couple of Perl script files that we've use on our web site to take user input apply some validation tests and then it generates the DNS entries for our test site. Patrik is absolutely correct this is a fertile area for experimentation and competition. > paf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 12:50:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21779 for ; Mon, 27 May 2002 12:50:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27207 for enum-archive@odin.ietf.org; Mon, 27 May 2002 12:50:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26928; Mon, 27 May 2002 12:41:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26897 for ; Mon, 27 May 2002 12:41:55 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21637 for ; Mon, 27 May 2002 12:41:31 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4RGeiQE012494; Mon, 27 May 2002 18:40:44 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Mon, 27 May 2002 18:41:17 +0200 Received: from [10.0.1.14] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 27 May 2002 18:41:15 +0200 Date: Mon, 27 May 2002 18:13:52 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , "Stastny, Richard" , Lawrence Conroy , enum@ietf.org cc: rich.shockey@neustar.com Subject: RE: [Enum] SchemaSet strawman Message-ID: <13820896.1022523232@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 27 May 2002 16:41:17.0447 (UTC) FILETIME=[52A6E970:01C2059D] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-27 14.28 +0200 "Stastny, Richard" wrote: > Ok, the "simplfied" NAPTR records will then either look like: > > NAPTR blabla "E2U+tel+voice+fax+sms" blabla > tel:+43179780;svc=voice;svc=fax;svc=sms > > Or > > NAPTR blabla "E2U+tel+voice" blabla tel:+4317978032;svc=voice > NAPTR blabla "E2U+tel+fax" blabla tel:+4317978013;svc=fax > NAPTR blabla "E2U+tel+sms" blabla tel:+436644204100;sms=sms What I have heard is more like: NAPTR blabla "E2U+telvoice" blabla tel:+4317978032;svc=voice NAPTR blabla "E2U+telfax" blabla tel:+4317978013;svc=fax NAPTR blabla "E2U+telsms" blabla tel:+436644204100;sms=sms I.e. in your first example, what is the meaning of "tel"? What is the registration of "voice"? What if only "tel" exists and not "voice"? What if "voice" exists and not "tel"? The '+' sign is to separate enumservices alltogether. If we are going down the path of "subservices" then we need to use a different separator, like '-'. I would like to NOT go down that path if not really really needed. And I really mean needed from a technical standpoint and not only "because the design looks nice". >> If you have one number which you publish which will lead to >> the three different services, then you have three NAPTR >> aswell, each one of them via the rewrite lead to a different >> tel URI. I.e. the final URI's people get will be different. >> Have to be different. > > This I do not understand. So do I have now three times the same number, so > the first of my examples is invalid? I have to write instead: > > NAPTR blabla "E2U+tel+voice" blabla tel:+4317978032;svc=voice > NAPTR blabla "E2U+tel+fax" blabla tel:+4317978032;svc=fax > NAPTR blabla "E2U+tel+sms" blabla tel:+4317978032;sms=sms > > Please clarify. Yes. One NAPTR can only give back one URI. If you have three different URI's (as you have above) you need three NAPTR. >> How the translation is to be done is up to the >> "enumserviceproviders". An excellent for _NON_ >> standardization and instead competition can work. > > Agree, but there is a minor misunderstanding: I definitely do NOT want the > "web" interface standardized, I only wanted to remember, that we should > not only think about how clients are evaluating or parsing the NAPTRs, > but also keep in mind, that on the other side the NAPTRs have to be > generated by some software. Agreed. > And BTW, I do not really see a problem for a piece of SW to read in the > complete set of NAPTRs and do some kind of calculation on it, e.g. peeking > ahead in the URLs, if we can avoid some duplication of obvious information > like in the examples above. There will be problems if you have non-terminal NAPTR records. And, applying the regular expressions in the NAPTR might be non-trivial. Or rather, think about how much calculations you have to do. I think we should try (I don't claim we can succeed) to minimize the amount of false positives (and of course see that we don't get any positives we miss) we get after the client only look at the enumservices, and choose/discard records accordingly. With that I mean that a client which get back M NAPTR records after doing a lookup first of all of course select the X out of M which have a servicefield which start with E2U. Then out of the X, by looking at the rest of the servicefield Y will be selected. If among the Y records, only N can be used by the client, of course a selection will be done after looking at the URI's, but, I want Y to be as close to N as possible. M >= X >= Y >= N Where M - The total number of NAPTR for a given owner X - The number of NAPTR were service field start with "E2U" Y - The number of NAPTR where the whole service field is ok N - The number of URI's which are actually usable by the client paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 13:14:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22199 for ; Mon, 27 May 2002 13:14:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28552 for enum-archive@odin.ietf.org; Mon, 27 May 2002 13:14:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27987; Mon, 27 May 2002 13:05:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27958 for ; Mon, 27 May 2002 13:05:25 -0400 (EDT) Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21913 for ; Mon, 27 May 2002 13:05:01 -0400 (EDT) Received: from user-2ivel9t.dialup.mindspring.com ([165.247.85.61] helo=dick.ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17CNvc-0006Ji-00; Mon, 27 May 2002 13:05:05 -0400 Message-Id: <5.1.0.14.2.20020527125808.021ed588@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 May 2002 13:10:21 -0400 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Stastny, Richard" , "Stastny, Richard" , Lawrence Conroy , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] SchemaSet strawman In-Reply-To: <13820896.1022523232@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > > Ok, the "simplfied" NAPTR records will then either look like: > > > > NAPTR blabla "E2U+tel+voice+fax+sms" blabla > > tel:+43179780;svc=voice;svc=fax;svc=sms > > > > Or > > > > NAPTR blabla "E2U+tel+voice" blabla tel:+4317978032;svc=voice > > NAPTR blabla "E2U+tel+fax" blabla tel:+4317978013;svc=fax > > NAPTR blabla "E2U+tel+sms" blabla tel:+436644204100;sms=sms > >What I have heard is more like: > > NAPTR blabla "E2U+telvoice" blabla tel:+4317978032;svc=voice > NAPTR blabla "E2U+telfax" blabla tel:+4317978013;svc=fax > NAPTR blabla "E2U+telsms" blabla tel:+436644204100;sms=sms > >I.e. in your first example, what is the meaning of "tel"? What is the >registration of "voice"? What if only "tel" exists and not "voice"? What if >"voice" exists and not "tel"? > >The '+' sign is to separate enumservices alltogether. If we are going down >the path of "subservices" then we need to use a different separator, like >'-'. I would like to NOT go down that path if not really really needed. And >I really mean needed from a technical standpoint and not only "because the >design looks nice". On reflection, I stand corrected Patrik ..I think you are right ... the '+' should separate distinct services. So to follow your example in the case of SMTP you would suggest "E2U+smtpfaxs" for possibly designating Simple Mode Fax [RFC2503] and "E2U+smptfaxf" for Full Mode or something like that. A single enumservice designator. > paf >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 13:32:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22713 for ; Mon, 27 May 2002 13:32:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00026 for enum-archive@odin.ietf.org; Mon, 27 May 2002 13:33:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29000; Mon, 27 May 2002 13:24:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28973 for ; Mon, 27 May 2002 13:24:24 -0400 (EDT) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22381 for ; Mon, 27 May 2002 13:24:00 -0400 (EDT) Received: from user-2ivel9t.dialup.mindspring.com ([165.247.85.61] helo=dick.ix.netcom.com) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 17COEH-0004Mk-00; Mon, 27 May 2002 13:24:22 -0400 Message-Id: <5.1.0.14.2.20020527131654.03ee84e0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 May 2002 13:29:43 -0400 To: enum@ietf.org From: Richard Shockey Subject: Re: [Enum] enumservices - the story so far part 2 Cc: Michael Mealling In-Reply-To: <5.1.0.14.2.20020527111808.02302f78@popd.ix.netcom.com> References: <20020527094819.GF84064@finch-staff-1.demon.net> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org So to summarize what I'm beginning to hear is a distinct set of principals governing the definition of the enumservice field. 1. One registration per service. 2. The '+' should only be used to separate distinct services. 3. There is no need to distinguish protocol from service in the enumservice field, by that if you want define 'smptfaxs' there is no need to express that as smtp+fax+s. The registration document for 'smtpfaxs' will in addition to a applicability statement ... a .define the service. b. protocols used (referencing appropriate RFC's etc) c. anticipated behavior d. security concerns e. privacy concerns 4. There is no need to define distinct services in the case of protocols like SIP or FAX where there is "on the wire" negotiation of capabilities or preferences. I'm still waiting to hear exactly what Mike Mealling has in mind here for his specific cases where there might be such a construct as "E2U+SIP+SIPLDAPthing" where the definition of 'SIPLDAPthing' is directly defined as operation to be used in conjunction with or in parallel with SIP itself... ???? Is this what you are saying? am I missing something? >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 13:52:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23071 for ; Mon, 27 May 2002 13:52:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA00359 for enum-archive@odin.ietf.org; Mon, 27 May 2002 13:52:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00233; Mon, 27 May 2002 13:43:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00200 for ; Mon, 27 May 2002 13:43:08 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22897 for ; Mon, 27 May 2002 13:42:45 -0400 (EDT) Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090250; Mon, 27 May 2002 18:42:49 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20020527131654.03ee84e0@popd.ix.netcom.com> References: <20020527094819.GF84064@finch-staff-1.demon.net> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020527131654.03ee84e0@popd.ix.netcom.com> Date: Mon, 27 May 2002 18:42:32 +0100 To: Richard Shockey , enum@ietf.org From: Lawrence Conroy Subject: Re: [Enum] enumservices - the story so far part 2 Cc: Michael Mealling Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 1:29 pm -0400 27/5/02, Richard Shockey wrote: >So to summarize what I'm beginning to hear is a distinct set of >principals governing the definition of the enumservice field. > >1. One registration per service. > >2. The '+' should only be used to separate distinct services. > >3. There is no need to distinguish protocol from service in the >enumservice field, by that if you want define 'smptfaxs' there is >no need to express that as smtp+fax+s. The registration document for >'smtpfaxs' will in addition to a applicability statement ... > a .define the service. > b. protocols used (referencing appropriate RFC's etc) > c. anticipated behavior > d. security concerns > e. privacy concerns > >4. There is no need to define distinct services in the case of >protocols like SIP or FAX where there is "on the wire" negotiation >of capabilities or preferences. > > >I'm still waiting to hear exactly what Mike Mealling has in mind >here for his specific cases where there might be such a construct as >"E2U+SIP+SIPLDAPthing" where the definition of 'SIPLDAPthing' is >directly defined as operation to be used in conjunction with or in >parallel with SIP itself... ???? Is this what you are saying? > >am I missing something? To which I reply: Yes, you are missing something. Yes, you are hearing (3) from Patrik and yourself exactly as you have defined above. No, you are not hearing this from me (or others, AFAICT) - I can re-send the postings from this last week if there was a communications failure. Yes - include the URI-scheme in the services field, if you want this to be available before regexp processing. No - IMHO there should NOT be a conflation of "higher level" function with the URI-scheme. That way lies combinatorial nightmare, and gives NO benefit that anyone has explained. Hence I'm strongly a'gin smtpfaxs or sipvoice or their ilk. Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 14:42:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23673 for ; Mon, 27 May 2002 14:42:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA02383 for enum-archive@odin.ietf.org; Mon, 27 May 2002 14:42:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02105; Mon, 27 May 2002 14:33:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02063 for ; Mon, 27 May 2002 14:32:58 -0400 (EDT) Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23601 for ; Mon, 27 May 2002 14:32:36 -0400 (EDT) Received: from user-2ivel9t.dialup.mindspring.com ([165.247.85.61] helo=dick.ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17CPIR-0005f9-00; Mon, 27 May 2002 14:32:45 -0400 Message-Id: <5.1.0.14.2.20020527142737.021f7830@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 27 May 2002 14:37:57 -0400 To: Lawrence Conroy , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] enumservices - the story so far part 2 Cc: Michael Mealling In-Reply-To: References: <5.1.0.14.2.20020527131654.03ee84e0@popd.ix.netcom.com> <20020527094819.GF84064@finch-staff-1.demon.net> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020524122753.0279d688@popd.ix.netcom.com> <5.1.0.14.2.20020527131654.03ee84e0@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 06:42 PM 5/27/2002 +0100, Lawrence Conroy wrote: >At 1:29 pm -0400 27/5/02, Richard Shockey wrote: >>So to summarize what I'm beginning to hear is a distinct set of >>principals governing the definition of the enumservice field. >> >>1. One registration per service. >> >>2. The '+' should only be used to separate distinct services. >> >>3. There is no need to distinguish protocol from service in the >>enumservice field, by that if you want define 'smptfaxs' there is no >>need to express that as smtp+fax+s. The registration document for >>'smtpfaxs' will in addition to a applicability statement ... >> a .define the service. >> b. protocols used (referencing appropriate RFC's etc) >> c. anticipated behavior >> d. security concerns >> e. privacy concerns >> >>4. There is no need to define distinct services in the case of protocols >>like SIP or FAX where there is "on the wire" negotiation of capabilities >>or preferences. >> >> >>I'm still waiting to hear exactly what Mike Mealling has in mind here for >>his specific cases where there might be such a construct as >>"E2U+SIP+SIPLDAPthing" where the definition of 'SIPLDAPthing' is directly >>defined as operation to be used in conjunction with or in parallel with >>SIP itself... ???? Is this what you are saying? >> >>am I missing something? > >To which I reply: > Yes, you are missing something. >Yes, you are hearing (3) from Patrik and yourself exactly as you have >defined above. >No, you are not hearing this from me (or others, AFAICT) - I can re-send >the postings from >this last week if there was a communications failure. no thank you .. I have read the mail .. >Yes - include the URI-scheme in the services field, if you want this to be >available before regexp processing. I dont think this is absolutely necessary ... so tell me what is the difference between 'smptfax' and 'foofoofax' so long as it is properly defined in a RFC and application programmers read the RFC and understand that foofoofax is defined in RFC2503? I think what Patrik and I are getting at is that the NAPTR enumservice field is really just the [ 'translation technique for the regexp' (E2U)+ 'a _label_ for something defined in a RFC' ] >No - IMHO there should NOT be a conflation of "higher level" function with >the URI-scheme. That way lies combinatorial nightmare, and gives NO >benefit that anyone has explained. Hence I'm strongly a'gin smtpfaxs or >sipvoice or their ilk. OK? > Lawrence > >-- >lwc@roke.co.uk: +44 1794 833666::: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon May 27 15:23:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24009 for ; Mon, 27 May 2002 15:23:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03917 for enum-archive@odin.ietf.org; Mon, 27 May 2002 15:23:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03675; Mon, 27 May 2002 15:12:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03647 for ; Mon, 27 May 2002 15:12:40 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23921 for ; Mon, 27 May 2002 15:12:17 -0400 (EDT) Received: from [193.118.192.111] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090251 for ; Mon, 27 May 2002 20:12:22 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Mon, 27 May 2002 20:12:04 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] ..and I quote Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Rich, folks, Herewith a section from 2916bis (as is): 2.4.2.1 ENUM Services A service MUST be registered with the IANA via a description in an RFC. ENUM Services specifications contain the functional specification (i.e. what it can be used for), the valid protocols, and the URI schemes that may be returned. For example, the Enum Service "presence" would define the various URI schemes ("im:", "mailto:") can be used and what the service can be used for ("Where is the owner of this E.164 number?"). Another example might be "sipvoice" which specifies that the URI must use the 'sip:' URI scheme and use the SIP protocol to make a voice call (as opposed to a voice mail call or fax call). OK, if we need to add URI-scheme to the service field, we add it. If we do this, then the sipvoice in the above extract might become "sip-voice". If people want to tag more than one enumservice, then this could be sip+voice+somethingelse (assuming that the somethingelse RFC included sip: as a valid protocol). The above extract also shows a putative service (presence) that can take more than one URI-scheme. So why is it surprising that the strawman includes these higher level services? They are a direct follow on from 2916bis. We add in the URI-scheme so that the client doesn't need to apply the regexp before finding out if it wants to use the regexp-ed result. Et voila:: Quoting my previous post on URI-schemes: At 3:38 pm +0100 26/5/02, Lawrence wrote: >Thus, the syntax gets a little tricky here. I guess that something like: > - 1*( + ) >is better - i.e. have the URI scheme immediately after the 'E2U' >D3S application tag, and before any enumservice list. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue May 28 02:02:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03634 for ; Tue, 28 May 2002 02:02:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA12113 for enum-archive@odin.ietf.org; Tue, 28 May 2002 02:02:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10878; Tue, 28 May 2002 01:53:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10847 for ; Tue, 28 May 2002 01:53:34 -0400 (EDT) Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00602 for ; Tue, 28 May 2002 01:53:08 -0400 (EDT) Received: by bulls.mei.co.jp (8.12.2/3.7W/jazz) with ESMTP id g4S5qpmP023235; Tue, 28 May 2002 14:52:51 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/bluejays) with SMTP id g4S5qpT23863; Tue, 28 May 2002 14:52:51 +0900 (JST) Received: from no.name.available by m-bb2.mgcs.mei.co.jp via smtpd (for [157.8.1.150]) with SMTP; 28 May 2002 05:52:51 UT Received: from mlsv1.mgcs.mei.co.jp by mlsv0-1.mgcs.mei.co.jp (8.12.2/3.7W-HUB) with ESMTP id g4S5obCW015723; Tue, 28 May 2002 14:50:37 +0900 (JST) Received: from mlsv2.rdmg.mgcs.mei.co.jp by mlsv1.mgcs.mei.co.jp (8.9.3/3.7W-MGCS) with ESMTP id OAA13776; Tue, 28 May 2002 14:52:50 +0900 (JST) Received: from d23n59.rdmg.mgcs.mei.co.jp by mlsv2.rdmg.mgcs.mei.co.jp (8.12.2/3.7W-RDMG) with SMTP id g4S5qWlI027277; Tue, 28 May 2002 14:52:32 +0900 (JST) Message-Id: <200205280600.AA01259@d23n59.rdmg.mgcs.mei.co.jp> From: "Toyoda, Kiyoshi" Date: Tue, 28 May 2002 15:00:00 +0900 To: Richard Shockey Cc: Patrik =?ISO-2022-JP?B?RhskQmdNGyhCdHN0chskQiIuGyhC?= , enum@ietf.org, ietf-fax@imc.org Subject: Re: [Enum] SchemaSet strawman In-Reply-To: <5.1.0.14.2.20020527125808.021ed588@popd.ix.netcom.com> References: <5.1.0.14.2.20020527125808.021ed588@popd.ix.netcom.com> MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.12 Content-Type: text/plain; charset=us-ascii Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Shockey-san, I would like to propose ifax services of ENUM. I comment below. Richard Shockey wrote: >> >>What I have heard is more like: >> >> NAPTR blabla "E2U+telvoice" blabla tel:+4317978032;svc=voice >> NAPTR blabla "E2U+telfax" blabla tel:+4317978013;svc=fax >> NAPTR blabla "E2U+telsms" blabla tel:+436644204100;sms=sms >> >>I.e. in your first example, what is the meaning of "tel"? What is the >>registration of "voice"? What if only "tel" exists and not "voice"? What if >>"voice" exists and not "tel"? >> >>The '+' sign is to separate enumservices alltogether. If we are going down >>the path of "subservices" then we need to use a different separator, like >>'-'. I would like to NOT go down that path if not really really needed. And >>I really mean needed from a technical standpoint and not only "because the >>design looks nice". > >On reflection, I stand corrected Patrik ..I think you are right ... the '+' >should separate distinct services. > >So to follow your example in the case of SMTP you would >suggest "E2U+smtpfaxs" for possibly designating Simple Mode Fax [RFC2503] >and "E2U+smptfaxf" for Full Mode or something like that. A single >enumservice designator. > I want to use ENUM for two services of IFAX. One is a service to get simply e-mail address of destination. Another is a service to get URI of directory server such as LDAP which has the e-mail address and capability of destination IFAX. I think that the former service will be acceptable easier by IFAX WG and ENUM WG than latter. So, I made a simple draft below at first. Please comment. ------------------------------------------------------------------- Network Working Group K. Toyoda, MGCS Internet Draft May 2002 Expires: November 2002 IFAX service of ENUM STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. COPYRIGHT NOTICE Copyright (C) The Internet Society (2001). All Rights Reserved. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. Abstract This document describes the functional specification and the definition of the ENUM NAPTR record, for IFax service. IFax is "Facsimile using Internet Mail". For this use, the DNS returns the email address of the referenced IFax system. 1. Functional Specification An IFax client makes an Enum DNS query with the target system's telephone number. The returned NAPTR record specifies an email address that is to be used for reaching the target system. The email address is then used in accordance with "Simple Mode of Facsimile using Internet Mail" [RFC2305] or "Extended Facsimile using Internet Mail" [RFC2532] 2. Definition of NAPTR record 2.1 Service Name Service Name = "ifax" The scope of this service is facsimile using Internet mail. It includes "Simple Mode of Facsimile using Internet Mail" and "Extended Facsimile using Internet Mail". "Full Mode Fax Profile for Internet Mail" is applied when it is approved as an Internet standards-track specification. 2.2 URI Scheme Scheme = "mailto" The URI Scheme is "mailto" because facsimile using Internet Mail is a profile for standard Internet mail and uses standard Internet mail addressing. Example $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa IN NAPTR 10 10 "u" "E2U+ifax" "!^.*$!mailto:paf@ifax.net!" 2.3 Intended usage COMMON 3 Security Consideration The Security Considerations section of [RFC2305] and [RFC2532] applies to this document. 4. ACKNOWLEDGEMENTS Dave Crocker provided useful suggestions to an earlier draft. 5. REFERENCES [ENUMbis] Falstrom, P., M. Mealling, "The E.164 to URI DDDS Application", draft-ietf-enum-rfc2916bis-00, February 22, 2002 [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. [RFC2532] Masinter, L., D. Wing, "Extended Facsimile Using Internet Mail", March 1999 [FFPIM] Crocker, D., G. Klyne, L. Masinter, "Full-mode Fax Profile for Internet Mail", DRAFT-IETF-FAX-FFPIM-03, March, 2002 6. AUTHORS' ADDRESSES Kiyoshi Toyoda Matsushita Graphic Communication Systems,Inc 2-3-8 Shimomeguro, Meguro-Ku Tokyo 153 JAPAN +81.3.5434.7161 ktoyoda@rdmg.mgcs.mei.co.jp 7. FULL COPYRIGHT STATEMENT Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kiyoshi Toyoda _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue May 28 03:50:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10424 for ; Tue, 28 May 2002 03:50:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18831 for enum-archive@odin.ietf.org; Tue, 28 May 2002 03:51:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18249; Tue, 28 May 2002 03:42:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18217 for ; Tue, 28 May 2002 03:42:02 -0400 (EDT) Received: from oefeg-mail.oefeg.at ([62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10253 for ; Tue, 28 May 2002 03:41:37 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Tue, 28 May 2002 09:28:44 +0200 Message-ID: From: "Stastny, Richard" To: "'Richard Shockey'" , =?iso-8859-1?Q?Patrik_F?= =?iso-8859-1?Q?=E4ltstr=F6m?= , Lawrence Conroy , enum@ietf.org Subject: RE: [Enum] SchemaSet strawman Date: Tue, 28 May 2002 09:28:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA18219 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Rich wrote, to which I reply: > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Monday, May 27, 2002 5:42 PM > To: Patrik Fältström; Stastny, Richard; Lawrence Conroy; enum@ietf.org > Subject: RE: [Enum] SchemaSet strawman > > > >If you used SIP instead, the sip people say that one URI is > enough, and > >negotiation is done inside the sip negotiation phase, so > only one NAPTR > >is enough which have one enumservice regardless of whether > it is phone, > >fax or pager. > > yes ... and the analogy to this is PSTN fax itself where > negotiation of > capabilities [T.30] is "on the wire" and does not require > user preselection As I understood Patrik, you should be able to select the proper NAPTR record from the enumservice alone. So IMHO opinion, if I am not even allowed to peek into the URI to select a service (e.g. I queried ENUM from my fax application), it is even worse if I have to start a negotiation with SIP or T.30 to find out which NAPTR record to take. > Frankly I think its power user > stuff since the > vast majority of users IMHO will want some else (the service > provider ) to > do all of this dirty work and jsut make sure it works. > No, thats not poweruser stuff. I think the vast majority of ENUM users want to subscribe and to modify their ENUM Services via a web portal. So if you subscribe to ENUM on the web (where else? To expect people to go to an office or fax the request?), you have to provide an e-mail anyway. So after subscription (and validation) an delegation is done in Tier 1 and an entry is created in the Tier 2 DNS Name Server with a NAPTR pointing to the e-mail. Next thing the subscriber does is going to the web-portal and filling out a (user-friendly) form entering his voice, fax, sms, presence, info URIs of his choice, and eventually modify his e-mail. This can either be done on a line-by-line basis per service or by providing URI fields to fill out and click the service boxes (this is up to the crativity of the web-designers). It is up to the provider of the Tier 2 Name Server (or the ENUM service provider) to create the proper NAPTR records out of this mess. Third step every user will do, is to query the DNS with a stand-alone client SW to look if the information is entered correctly (at least that what I would do). And he want to have this information displayed in such a way that it somewhat resembles the information he has put in. Regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue May 28 04:07:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10566 for ; Tue, 28 May 2002 04:07:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20228 for enum-archive@odin.ietf.org; Tue, 28 May 2002 04:08:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19366; Tue, 28 May 2002 03:59:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19275 for ; Tue, 28 May 2002 03:59:22 -0400 (EDT) Received: from oefeg-mail.oefeg.at ([62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10507 for ; Tue, 28 May 2002 03:58:57 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Tue, 28 May 2002 09:46:04 +0200 Message-ID: From: "Stastny, Richard" To: "'Richard Shockey'" , =?iso-8859-1?Q?Patrik_F?= =?iso-8859-1?Q?=E4ltstr=F6m?= , Lawrence Conroy , enum@ietf.org Subject: RE: [Enum] SchemaSet strawman Date: Tue, 28 May 2002 09:45:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA19276 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Rich wrote, to which I reply: > -----Original Message----- > From: Richard Shockey [mailto:rshockey@ix.netcom.com] > Sent: Monday, May 27, 2002 7:10 PM > To: Patrik Fältström; Stastny, Richard; Stastny, Richard; > Lawrence Conroy; enum@ietf.org > Subject: RE: [Enum] SchemaSet strawman > > > >The '+' sign is to separate enumservices alltogether. If we > are going > >down the path of "subservices" then we need to use a different > >separator, like '-'. I would like to NOT go down that path if not > >really really needed. And I really mean needed from a technical > >standpoint and not only "because the design looks nice". > > On reflection, I stand corrected Patrik ..I think you are > right ... the '+' > should separate distinct services. > > So to follow your example in the case of SMTP you would > suggest "E2U+smtpfaxs" for possibly designating Simple Mode > Fax [RFC2503] > and "E2U+smptfaxf" for Full Mode or something like that. A single > enumservice designator. > I do not like to go down this path, because the number of combinations is endless, and to register all smptfaxs, telfaxs, sipfaxs, telvoice, sipvoice, h323voice, and sipvideo etc. is a nightmare. If it is really necessary to mention the URI used in the enumservice filed, I would like to go down the path of combinatorics. The service definition is complicated enough (nobody was ever able to explain to me what a service is anyway) So what I propose is either to define the field enumservice as: [ E2U "-" URIused 1*("+" service)] Where service is voice, fax, sms, mms, video etc The templates have to be created not per service, but per URI, it may even contained in the URI definitions, which services can be used (in the svc parameter). Or the enumservices are grouped as proposed by Lawrence and we peek ahead in the URI and svc parameter. Best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue May 28 07:44:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13419 for ; Tue, 28 May 2002 07:44:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03268 for enum-archive@odin.ietf.org; Tue, 28 May 2002 07:45:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02610; Tue, 28 May 2002 07:34:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02579 for ; Tue, 28 May 2002 07:34:32 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12832 for ; Tue, 28 May 2002 07:34:06 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Tue, 28 May 2002 13:21:14 +0200 Message-ID: From: "Stastny, Richard" To: "'Lawrence Conroy'" , enum@ietf.org Subject: RE: [Enum] ..and I quote Date: Tue, 28 May 2002 13:21:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Lawrence wrote, to which I reply: > -----Original Message----- > From: Lawrence Conroy [mailto:lwc@roke.co.uk] > Sent: Monday, May 27, 2002 9:12 PM > To: enum@ietf.org > Subject: [Enum] ..and I quote > >> > OK, if we need to add URI-scheme to the service field, we add > it. If we do this, then the sipvoice in the above extract > might become "sip-voice". > > If people want to tag more than one enumservice, then this > could be sip+voice+somethingelse (assuming that the > somethingelse RFC included sip: as a valid protocol). Agreed, but I would like to suggest (as already proposed in my response to Rich), and as also proposed by Lawrence: At 3:38 pm +0100 26/5/02, Lawrence wrote: > >Thus, the syntax gets a little tricky here. I guess that > something like: > > - 1*( + > ) is > >better - i.e. have the URI scheme immediately after the 'E2U' D3S > >application tag, and before any enumservice list. that we do it the other way round: We take the URI-scheme and add the services. This would resolve also the problem for using one URI (e.g. tel) for multiple services. It may also solve the sip(srs) problem, that you either list all available services with sip, or provide only the sip URI (either with no service or a default (any or *)), meaning that the services should be negotiated. If one has other NAPTRs beside sip with services, this would mean that all other services may be negotiated besides the one listed. It would also allow a "forwarding" of the whole domain with the new URI enum:+431..., meaning, that another ENUM query should be made with the given number, either for all services or only for the service listed. Eg: NAPTR blabla "E2U-enum+*" blabla enum:+431... Or NAPTR blabla "E2U-enum+voice" blabla enum:+431... if the fwd is only for voice One can assume, that normally a user provides in any case only one URI for a given service, and the order and preference fields will not be used. If really a user wants to provide more than one URI for a given, he could use the preference field (and he shall use only one URI and one service: E.g. NAPTR 10 10 "E2U-sip+voice" blabla sip:paf@cisco.net NAPTR 10 20 "E2U-tel+voice" blabla tel:+34... IMHO opinion we should provide templates for registration, but not for the services, but for the URI-schemes used. Each template should list the allowed services for the URI in context with ENUM. This also would be a nice cleanup of the currently (a bit messy) URI definitions. I honestly have currently no complete picture of all of the URIs under discussion with ENUM. I think it is also better practice, if the URI experts provide the basic templates than the service experts. The services experts may than add services to the basic templates. Best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue May 28 11:25:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21894 for ; Tue, 28 May 2002 11:25:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21423 for enum-archive@odin.ietf.org; Tue, 28 May 2002 11:25:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20878; Tue, 28 May 2002 11:16:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20831 for ; Tue, 28 May 2002 11:16:50 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21584 for ; Tue, 28 May 2002 11:16:26 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4SFGIc05901; Tue, 28 May 2002 11:16:18 -0400 Message-Id: <5.1.0.14.2.20020528111047.0292f910@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 May 2002 11:21:34 -0400 To: "Stastny, Richard" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] SchemaSet strawman In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > > >The '+' sign is to separate enumservices alltogether. If we > > are going > > >down the path of "subservices" then we need to use a different > > >separator, like '-'. I would like to NOT go down that path if not > > >really really needed. And I really mean needed from a technical > > >standpoint and not only "because the design looks nice". > > > > On reflection, I stand corrected Patrik ..I think you are > > right ... the '+' > > should separate distinct services. > > > > So to follow your example in the case of SMTP you would > > suggest "E2U+smtpfaxs" for possibly designating Simple Mode > > Fax [RFC2503] > > and "E2U+smptfaxf" for Full Mode or something like that. A single > > enumservice designator. > > > >I do not like to go down this path, because the number of combinations is >endless, and to register all smptfaxs, telfaxs, sipfaxs, telvoice, sipvoice, >h323voice, and sipvideo etc. is a nightmare. Well the combinations you propose are N (squared) .. :-) Well I still submit that SIP is SIP and since negotiation on these protocols occurs on the wire granularizing the service is unnecessary. I feel pretty strong about this and I believe the feeling is shared among the SIP community. >If it is really necessary to mention the URI used in the enumservice filed, >I would like to go down the path of combinatorics. The service definition is >complicated enough (nobody was ever able to explain to me what a service is >anyway) > >So what I propose is either to define the field enumservice as: > >[ E2U "-" URIused 1*("+" service)] > >Where service is voice, fax, sms, mms, video etc and this construct 'E2U-smtp+faxs' is not a nightmare? So the registration procedure would be for SMTP and all service variants of that? >The templates have to be created not per service, but per URI, it may even >contained in the URI definitions, which services can be used (in the svc >parameter). I still do not see the operational difference between the construct 'E2U-smtp+faxs' and 'E2U+smtpfaxs. Why is one easier for devices or user agents to process than the other? Both can define exactly the same thing if they are properly defined and documented. Richard ..I really am trying to understand this ... >Or the enumservices are grouped as proposed by Lawrence and we peek ahead in >the URI and svc parameter. > >Best regards >Richard > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue May 28 11:25:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21912 for ; Tue, 28 May 2002 11:25:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21479 for enum-archive@odin.ietf.org; Tue, 28 May 2002 11:25:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20900; Tue, 28 May 2002 11:16:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20832 for ; Tue, 28 May 2002 11:16:50 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21583 for ; Tue, 28 May 2002 11:16:26 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4SFGHc05898; Tue, 28 May 2002 11:16:17 -0400 Message-Id: <5.1.0.14.2.20020528105910.0470abe8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 28 May 2002 11:10:22 -0400 To: "Stastny, Richard" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] SchemaSet strawman In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > > >fax or pager. > > > > yes ... and the analogy to this is PSTN fax itself where > > negotiation of > > capabilities [T.30] is "on the wire" and does not require > > user preselection > >As I understood Patrik, you should be able to select the proper NAPTR record >from the enumservice alone. So IMHO opinion, if I am not even allowed to >peek into the URI to select a service (e.g. I queried ENUM from my fax >application), it is even worse if I have to start a negotiation with SIP or >T.30 to find out which NAPTR record to take. I am getting confused ... If the device is attempting to send a Internet Fax according to the rules of 2305 the device is going to know know what it is looking for in advance of creating the session ... since I am using the example of fax its imbedded firmware knows what enumservice fields can match to the desired outcome. So long as there are well understoood rules surrounding the particular definition of the enumservice I have trouble understanding what the problem is. If I am attempting to create a voice conversation using SIP the C/UA is simply going to look for the enumservice field 'SIP" from the list of returned NAPTR records...discard everything else .. process the regexp and ultimately send the invite. The enumservice field is just a 'label' or a 'name' What am I missing. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue May 28 12:28:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24038 for ; Tue, 28 May 2002 12:28:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26952 for enum-archive@odin.ietf.org; Tue, 28 May 2002 12:28:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26354; Tue, 28 May 2002 12:19:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26323 for ; Tue, 28 May 2002 12:19:05 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23710 for ; Tue, 28 May 2002 12:18:36 -0400 (EDT) Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090259; Tue, 28 May 2002 17:18:42 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20020528111047.0292f910@popd.ix.netcom.com> References: <5.1.0.14.2.20020528111047.0292f910@popd.ix.netcom.com> Date: Tue, 28 May 2002 17:18:22 +0100 To: Richard Shockey From: Lawrence Conroy Cc: "Stastny, Richard" , enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] RE: enumservice roles (was SchemaSet strawman) Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 11:21 am -0400 28/5/02, Richard Shockey wrote: >>In response to Richard Stastny's comment: >>I do not like to go down this path, because the number of combinations is >>endless, and to register all smptfaxs, telfaxs, sipfaxs, telvoice, sipvoice, >>h323voice, and sipvideo etc. is a nightmare. > >Well the combinations you propose are N (squared) .. :-) - yes, but I don't have to write RFCs for smtp: or http: or sip:. We stand on the shoulders of giants. Thus, I could write an RFC to show what a poor client can expect if it sees this tag (including some idea of the list of URI schemes that can be used with it, and how it should be treated if a particular URI scheme is decoded). > >Well I still submit that SIP is SIP and since negotiation on these >protocols occurs on the wire granularizing the service is >unnecessary. I feel pretty strong about this and I believe the >feeling is shared among the SIP community. Yes, I understand that the "SIP community" believe this. They're right, as well. And yet... As already stated in an earlier post, this is not a technical issue, it's a reality issue. (Not, of course, that I'm suggesting that some of the "SIP community" have lost touch with reality :). I don't even want to think about explaining to Joe XP@home user how to tie their WCOM siptest account behind their .NET account (the one they use to text with their buddies). Technically that's easy, but... > >>If it is really necessary to mention the URI used in the enumservice filed, >>I would like to go down the path of combinatorics. The service definition is >>complicated enough (nobody was ever able to explain to me what a service is >>anyway) >> >>So what I propose is either to define the field enumservice as: >> >>[ E2U "-" URIused 1*("+" service)] >> >>Where service is voice, fax, sms, mms, video etc > > >and this construct 'E2U-smtp+faxs' is not a nightmare? Um...I don't need to do one registration for ('talk' when using a tel: URI) and another for ('talk' when using a SIP URI) and another for ('talk' using putative h323: URI), and ... I do one registration for 'talk', in which it describes any handling for any URI-schemes that it can use, and that's it folks. One draft versus three is good in my book. It also (IMHO) makes it easier for an end user to select a category of communication that they want to have, and then pattern match against any NAPTRs regardless of whether they indicate tel: or SIP: or whatever:. Your mileage may vary, of course. >So the registration procedure would be for SMTP and all service >variants of that? > > >>The templates have to be created not per service, but per URI, it may even >>contained in the URI definitions, which services can be used (in the svc >>parameter). Here's a radical proposal. Instead of having each of these higher level functions (like 'talk') describe how to handle particular URIs to provide the expected function, we have a draft that shows the higher level functions that can be carried out with the URI scheme (I assume that with sip:, the description will include all/any to show that it does SRS as well as more specific services). > >I still do not see the operational difference between the construct >'E2U-smtp+faxs' and 'E2U+smtpfaxs. Why is one easier for devices or >user agents to process than the other? Both can define exactly the >same thing if they are properly defined and documented. see above for 'nightmare' response. >Richard ..I really am trying to understand this ... > (Et moi aussi :) It is a lot closer to the existing 'tel' and 'sip-e164' drafts, I think? all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue May 28 14:16:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27021 for ; Tue, 28 May 2002 14:16:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04629 for enum-archive@odin.ietf.org; Tue, 28 May 2002 14:16:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04353; Tue, 28 May 2002 14:07:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04322 for ; Tue, 28 May 2002 14:07:35 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26869 for ; Tue, 28 May 2002 14:07:10 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SI6MNM020973; Tue, 28 May 2002 20:06:26 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 28 May 2002 20:06:59 +0200 Received: from [10.0.0.5] ([171.68.225.134]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 28 May 2002 20:06:57 +0200 Date: Tue, 28 May 2002 20:04:10 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , "'Richard Shockey'" , Lawrence Conroy , enum@ietf.org Subject: RE: [Enum] SchemaSet strawman Message-ID: <16175011.1022616250@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 28 May 2002 18:06:59.0052 (UTC) FILETIME=[75B352C0:01C20672] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-28 09.28 +0200 "Stastny, Richard" wrote: > As I understood Patrik, you should be able to select the proper NAPTR > record from the enumservice alone. Minimize the number of false positives. I am sure there will not be possible to do a complete selection. See mail about X >= Y etc... paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue May 28 14:16:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27038 for ; Tue, 28 May 2002 14:16:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04645 for enum-archive@odin.ietf.org; Tue, 28 May 2002 14:16:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04316; Tue, 28 May 2002 14:07:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04285 for ; Tue, 28 May 2002 14:07:30 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26866 for ; Tue, 28 May 2002 14:07:00 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SI6He2020965; Tue, 28 May 2002 20:06:17 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 28 May 2002 20:06:54 +0200 Received: from [10.0.0.5] ([171.68.225.134]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 28 May 2002 20:06:52 +0200 Date: Tue, 28 May 2002 20:02:49 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] ..and I quote Message-ID: <16170150.1022616169@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 28 May 2002 18:06:53.0817 (UTC) FILETIME=[72948690:01C20672] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-27 20.12 +0100 Lawrence Conroy wrote: > OK, if we need to add URI-scheme to the service field, we add it. > If we do this, then the sipvoice in the above extract might become > "sip-voice". Please stop using the same characters in the enumservice as in the URI scheme. Call the schemes "foo" and "bar", and try to explain what they are about. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue May 28 16:54:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00929 for ; Tue, 28 May 2002 16:54:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15849 for enum-archive@odin.ietf.org; Tue, 28 May 2002 16:54:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15001; Tue, 28 May 2002 16:40:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14968 for ; Tue, 28 May 2002 16:40:32 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00540 for ; Tue, 28 May 2002 16:40:06 -0400 (EDT) Received: from [193.118.205.14] (HELO [192.168.0.3]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090260; Tue, 28 May 2002 21:40:03 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <16170150.1022616169@localhost> References: <16170150.1022616169@localhost> Date: Tue, 28 May 2002 21:39:48 +0100 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , enum@ietf.org From: Lawrence Conroy Subject: Re: [Enum] ..and I quote Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA14971 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 8:02 pm +0200 28/5/02, Patrik Fältström wrote: >--On 2002-05-27 20.12 +0100 Lawrence Conroy wrote: > >> OK, if we need to add URI-scheme to the service field, we add it. >> If we do this, then the sipvoice in the above extract might become >> "sip-voice". > >Please stop using the same characters in the enumservice as in the URI >scheme. > >Call the schemes "foo" and "bar", and try to explain what they are about. > > paf To which I reply: Hi Patrik, folks, Yes - I do, always. In the above, 'sip' is the URI-scheme, whilst 'voice' is (I assume) an enumservice. If you prefer, this would be foo-bar. bar would be an enumservice that can use the URI-scheme foo; this enumservice might, for example, result in an interactive telephony communication using voice as its medium. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue May 28 17:34:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01777 for ; Tue, 28 May 2002 17:34:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19357 for enum-archive@odin.ietf.org; Tue, 28 May 2002 17:34:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18245; Tue, 28 May 2002 17:25:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18211 for ; Tue, 28 May 2002 17:25:48 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01536 for ; Tue, 28 May 2002 17:25:18 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SLOXGm014835; Tue, 28 May 2002 23:24:34 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Tue, 28 May 2002 23:25:10 +0200 Received: from [10.0.0.5] ([171.68.225.134]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 28 May 2002 23:25:09 +0200 Date: Tue, 28 May 2002 23:23:42 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , enum@ietf.org Subject: Re: [Enum] ..and I quote Message-ID: <16893319.1022628222@localhost> In-Reply-To: References: <16170150.1022616169@localhost> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 28 May 2002 21:25:10.0710 (UTC) FILETIME=[25AE5560:01C2068E] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-28 21.39 +0100 Lawrence Conroy wrote: > In the above, 'sip' is the URI-scheme, whilst 'voice' is (I assume) an > enumservice. > > If you prefer, this would be foo-bar. bar would be an enumservice that > can use the URI-scheme foo; this enumservice might, for example, result > in an interactive telephony communication using voice as its medium. What you have in the servicefield of the NAPTR record are enumservices. The URI scheme is not there. The URI scheme is part of the URI which is the result of applying the rewrite algorithm of the data part of the NAPTR. If you want "foo" to mean that "the result of a rewrite is a URI with the scheme SIP" then say so, and not that "sip" is what should go in the NAPTR as a enumservice. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Tue May 28 23:47:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09054 for ; Tue, 28 May 2002 23:47:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA12447 for enum-archive@odin.ietf.org; Tue, 28 May 2002 23:48:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA11896; Tue, 28 May 2002 23:38:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA11864 for ; Tue, 28 May 2002 23:38:34 -0400 (EDT) Received: from twnic.net.tw (twnic.net.tw [211.72.210.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08795 for ; Tue, 28 May 2002 23:38:09 -0400 (EDT) Received: from abel (pc073.twnic.net.tw [211.72.211.73]) by twnic.net.tw (8.9.3/8.9.3) with SMTP id LAA23261 for ; Wed, 29 May 2002 11:38:31 +0800 Message-ID: <013401c206c3$53ddcf30$49d348d3@abel> From: "abel" To: References: <16170150.1022616169@localhost> <16893319.1022628222@localhost> Date: Wed, 29 May 2002 11:45:51 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit Subject: [Enum] Time considering Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Is it possible for the NAPTR RR TEL TTL IN NAPTR ORDER PRE SERVICE "!RE!URI!" REPLACEMENT we can add TIME field in somewhere . If I would like between 0900-1800+0800 some one can call me start end time zone but NAPTR no such filed for using. ----- Original Message ----- From: "Patrik Fältström" To: "Lawrence Conroy" ; Sent: Wednesday, May 29, 2002 5:23 AM Subject: Re: [Enum] ..and I quote > --On 2002-05-28 21.39 +0100 Lawrence Conroy wrote: > > > In the above, 'sip' is the URI-scheme, whilst 'voice' is (I assume) an > > enumservice. > > > > If you prefer, this would be foo-bar. bar would be an enumservice that > > can use the URI-scheme foo; this enumservice might, for example, result > > in an interactive telephony communication using voice as its medium. > > What you have in the servicefield of the NAPTR record are enumservices. The > URI scheme is not there. The URI scheme is part of the URI which is the > result of applying the rewrite algorithm of the data part of the NAPTR. > > If you want "foo" to mean that "the result of a rewrite is a URI with the > scheme SIP" then say so, and not that "sip" is what should go in the NAPTR > as a enumservice. > > paf > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 29 03:05:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04916 for ; Wed, 29 May 2002 03:05:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA15360 for enum-archive@odin.ietf.org; Wed, 29 May 2002 03:05:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13353; Wed, 29 May 2002 02:53:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA13322 for ; Wed, 29 May 2002 02:53:34 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04579 for ; Wed, 29 May 2002 02:53:09 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4T6qJ4S028503; Wed, 29 May 2002 08:52:20 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 29 May 2002 08:52:56 +0200 Received: from [10.0.0.5] ([171.68.225.134]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 29 May 2002 08:52:55 +0200 Date: Wed, 29 May 2002 08:46:11 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: abel , enum@ietf.org Subject: Re: [Enum] Time considering Message-ID: <18918278.1022661971@localhost> In-Reply-To: <013401c206c3$53ddcf30$49d348d3@abel> References: <16170150.1022616169@localhost> <16893319.1022628222@localhost> <013401c206c3$53ddcf30$49d348d3@abel> X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 29 May 2002 06:52:56.0486 (UTC) FILETIME=[76773C60:01C206DD] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-29 11.45 +0800 abel wrote: > Is it possible for the NAPTR RR > > TEL TTL IN NAPTR ORDER PRE SERVICE "!RE!URI!" > REPLACEMENT > > we can add TIME field in somewhere . > If I would like between 0900-1800+0800 some one can call me > start end time zone > but NAPTR no such filed for using. No. NAPTR have fixed format, defined outside of the ENUM wg. If you want this, it have to be stored in some other system, like a SIP server using some CPL based system. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 29 03:10:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05033 for ; Wed, 29 May 2002 03:10:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA15611 for enum-archive@odin.ietf.org; Wed, 29 May 2002 03:10:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14359; Wed, 29 May 2002 02:59:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14322 for ; Wed, 29 May 2002 02:59:56 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04713 for ; Wed, 29 May 2002 02:59:31 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 29 May 2002 08:46:36 +0200 Message-ID: From: "Stastny, Richard" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , Lawrence Conroy , enum@ietf.org Subject: RE: [Enum] ..and I quote Date: Wed, 29 May 2002 08:46:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA14323 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik wrote: > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Tuesday, May 28, 2002 8:03 PM > To: Lawrence Conroy; enum@ietf.org > Subject: Re: [Enum] ..and I quote > > --On 2002-05-27 20.12 +0100 Lawrence Conroy wrote: > > > OK, if we need to add URI-scheme to the service field, we > add it. If > > we do this, then the sipvoice in the above extract might become > > "sip-voice". > > Please stop using the same characters in the enumservice as > in the URI scheme. > > Call the schemes "foo" and "bar", and try to explain what > they are about. To which I reply: Good Morning. Huh? Now I am totally confused. Aren't you the (co)-author of rfc2916bis? There I find: $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. IN NAPTR 10 10 "u" "E2U+sip" "!^.*$!sip:paf@swip.net!" . IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:paf@swip.net!" . IN NAPTR 102 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . Maybe I missed something in the discussion last week, but then the draft has to be updated substantially. BTW, is now sipvoice or telvoice allowed or not? (provided I try to explain it ;-) Regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 29 03:42:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06207 for ; Wed, 29 May 2002 03:42:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA18357 for enum-archive@odin.ietf.org; Wed, 29 May 2002 03:42:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17805; Wed, 29 May 2002 03:33:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17757 for ; Wed, 29 May 2002 03:33:11 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05847 for ; Wed, 29 May 2002 03:32:45 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4T7S2Rs003890; Wed, 29 May 2002 09:28:08 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 29 May 2002 09:28:35 +0200 Received: from [10.0.0.5] ([171.68.225.134]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 29 May 2002 09:28:34 +0200 Date: Wed, 29 May 2002 09:28:09 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , Lawrence Conroy , enum@ietf.org Subject: RE: [Enum] ..and I quote Message-ID: <19069304.1022664489@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 29 May 2002 07:28:35.0539 (UTC) FILETIME=[7170D230:01C206E2] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-29 08.46 +0200 "Stastny, Richard" wrote: >> Call the schemes "foo" and "bar", and try to explain what >> they are about. > > To which I reply: > Good Morning. > Huh? > Now I am totally confused. > Aren't you the (co)-author of rfc2916bis? > There I find: > $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. > IN NAPTR 10 10 "u" "E2U+sip" "!^.*$!sip:paf@swip.net!" . > IN NAPTR 102 10 "u" "E2U+mailto" "!^.*$!mailto:paf@swip.net!" . > IN NAPTR 102 10 "u" "E2U+tel" "!^(.*$)$!tel:\1!" . Yes, but obviously people do NOT understand that the string "sip" in the servicefield has absolutely NOTHING to do with the string sip in the rewrite rule. The sip enumservice could have been "foo". > BTW, is now sipvoice or telvoice allowed or not? (provided I try to > explain it ;-) _Any_ string is allowed. But you have to explain what it means. A string is a string is a string. Whether it is called sip, telvoice, stockholm or foo does NOT matter. Too many people on this list read some meaning in the set of characters which create the enumservce. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 29 04:04:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06861 for ; Wed, 29 May 2002 04:04:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA20017 for enum-archive@odin.ietf.org; Wed, 29 May 2002 04:05:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19196; Wed, 29 May 2002 03:54:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19089 for ; Wed, 29 May 2002 03:54:29 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06695 for ; Wed, 29 May 2002 03:54:05 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 29 May 2002 09:41:11 +0200 Message-ID: From: "Stastny, Richard" To: "'Richard Shockey'" , "Stastny, Richard" , enum@ietf.org Subject: RE: [Enum] SchemaSet strawman Proposal Date: Wed, 29 May 2002 09:41:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Rich wrote: > -----Original Message----- > From: Richard Shockey [mailto:rich.shockey@NeuStar.com] > Sent: Tuesday, May 28, 2002 5:22 PM > To: Stastny, Richard; enum@ietf.org > Subject: RE: [Enum] SchemaSet strawman > > I still do not see the operational difference between the construct > 'E2U-smtp+faxs' and 'E2U+smtpfaxs. Why is one easier for > devices or user > agents to process than the other? Both can define exactly the > same thing if > they are properly defined and documented. > > Richard ..I really am trying to understand this ... To which I reply: Rich, I think we are at the point now. I also agree, that there is no operational difference, if we use either 'E2U-smtp+faxs' and 'E2U+smtpfaxs ;-) But can we agree, that we both want a combination of URI and "service". I could live with your proposal, if we use only combinations of ONE URI (of course) and ONE "service". That means, that combinations of 'telvoicefaxsms' or 'telvoicefax' or 'telvoicesms' are not used. So my proposed NAPTR for a tel: URI NAPTR blabla "E2U-tel+voice+fax+sms" blabla tel:+4317978032 would now look, according to your proposal: NAPTR blabla "E2U+telvoice+telfax+telsms" blabla tel:+431797832 or (according to Patrik?) be three NAPTRs: NAPTR blabla "E2U+telvoice" blabla tel:+4317978032 NAPTR blabla "E2U+telfax" blabla tel:+4317978032 NAPTR blabla "E2U+telsms" blabla tel:+4317978032 I also propose again, to do the templates per group of services related to one URI, so all valid (and at the time known) combinations of telxxx, sipxxx, h323xxx, mailtoxxx will be defined in a template each. There is still some problems to be discussed: 1. What to do with plain URI enumservices, like sip, mailto, etc. where I do not need an additional service listed. Since (according to Patrik) the same characters should not be used, we are stuck here. Or the other way round, what is the default? Is it sip, sip* or sipany 2. The second problem is concerning your "creative" services, as you stated in your reply to Clive: >What is the conflict with this .. this is actually a really good example >of a very creative service !! The only way I prefer you to reach my mobile >SMS end point is to use a SMTP gateway where I could a apply a spam filter >...I like this one !! I'll buy this!!! I agree, that we may come up here with some nice services, but you should consider here, that if the user wants to send an sms, he has his sms application launched and is entering a phone number +431... in the To: field. So the application is first looking for something like 'foosms' and normally will find something like 'telsms'. If there is an entry 'mailtosms' or 'smtpsms', this would mean, that an e-mail client is needed also. If you now consider all potential new services, we again have a lot of templates to define. Although this well be a nice exercise, I would prefer (keeping the trials in mind), that we first do the basics. Best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 29 05:03:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07909 for ; Wed, 29 May 2002 05:03:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA23940 for enum-archive@odin.ietf.org; Wed, 29 May 2002 05:04:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22814; Wed, 29 May 2002 04:53:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22783 for ; Wed, 29 May 2002 04:53:39 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07659 for ; Wed, 29 May 2002 04:53:15 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4T8qUJM020265; Wed, 29 May 2002 10:52:31 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 29 May 2002 10:52:59 +0200 Received: from [10.0.0.5] ([171.68.225.134]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 29 May 2002 10:52:58 +0200 Date: Wed, 29 May 2002 10:49:33 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , "'Richard Shockey'" , "Stastny, Richard" , enum@ietf.org Subject: RE: [Enum] SchemaSet strawman Proposal Message-ID: <19362380.1022669373@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 29 May 2002 08:52:58.0921 (UTC) FILETIME=[3B739990:01C206EE] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-29 09.41 +0200 "Stastny, Richard" wrote: > Since (according to Patrik) the same > characters should not be used, we are stuck here. Please read my mail again. I said people should in this discussion use different characters, because the name of the enumservice have _nothing_ to do with the characters in the URI scheme. What URI scheme(s) a specific NAPTR is tied to is specified by the specification of the enumservice. Not by what characters are in the enumservice itself. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed May 29 06:05:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09533 for ; Wed, 29 May 2002 06:05:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA28045 for enum-archive@odin.ietf.org; Wed, 29 May 2002 06:06:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27250; Wed, 29 May 2002 05:55:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27219 for ; Wed, 29 May 2002 05:55:01 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09261 for ; Wed, 29 May 2002 05:54:36 -0400 (EDT) Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090263; Wed, 29 May 2002 10:54:37 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <19362380.1022669373@localhost> References: <19362380.1022669373@localhost> Date: Wed, 29 May 2002 10:54:14 +0100 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= From: Lawrence Conroy Subject: RE: [Enum] SchemaSet strawman Proposal Cc: "Stastny, Richard" , "'Richard Shockey'" , enum@ietf.org Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA27220 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit At 10:49 am +0200 29/5/02, Patrik Fältström wrote: >--On 2002-05-29 09.41 +0200 "Stastny, Richard" >wrote: > >> Since (according to Patrik) the same >> characters should not be used, we are stuck here. > >Please read my mail again. > >I said people should in this discussion use different characters, because >the name of the enumservice have _nothing_ to do with the characters in the >URI scheme. > >What URI scheme(s) a specific NAPTR is tied to is specified by the >specification of the enumservice. Not by what characters are in the >enumservice itself. Dear Patrik, I have read your emails. I have looked back through these threads, and don't see any clear pattern. I'm happy putting 'pis' instead of 'sip', or 'tjq', if it's the tag for an enumservice; I would prefer 'srs', but that's in the strawman already. Way back, I (and others) proposed having a set of "enumservices" that would NOT be tied to individual URI-schemes. This is the "high level functions" of the strawman. Each defining draft would include a list of the URIs that could be used with that enumservice, and how these URIs could be used. I understood your position was that this was not acceptable, as the client would not be able to select exactly what they had to do (and the program they had to run) without rexexp-processing to get the URI. I took this to mean that you wanted also to include the URI-scheme (note - completely distinct from the enumservice list) in the NAPTR service field, AS WELL AS the enumservice list, as the service field is all the client has to help select between NAPTRs (at least for non-terminals). Now it appears that we are NOT to put the URI-scheme into the NAPTR service field. Fine. Are we now back to the strawman list, or if not, ->why<- not? all the best Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed May 29 06:36:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09959 for ; Wed, 29 May 2002 06:36:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29870 for enum-archive@odin.ietf.org; Wed, 29 May 2002 06:36:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28945; Wed, 29 May 2002 06:27:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28914 for ; Wed, 29 May 2002 06:27:02 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09831 for ; Wed, 29 May 2002 06:26:37 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 29 May 2002 12:13:43 +0200 Message-ID: From: "Stastny, Richard" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] SchemaSet strawman Proposal Date: Wed, 29 May 2002 12:13:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA28915 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Patrik wrote: > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Wednesday, May 29, 2002 10:50 AM > To: Stastny, Richard; 'Richard Shockey'; Stastny, Richard; > enum@ietf.org > Subject: RE: [Enum] SchemaSet strawman Proposal > > --On 2002-05-29 09.41 +0200 "Stastny, Richard" > > wrote: > > > Since (according to Patrik) the same > > characters should not be used, we are stuck here. > > Please read my mail again. I am reading your e-mails always at least twice anway ;-) > > I said people should in this discussion use different > characters, because the name of the enumservice have > _nothing_ to do with the characters in the URI scheme. I fully agree with you, that the enumservice is something different to the URI used AND also to the services provided with a certain URI. This was also the reason, why Lawrence used in his proposal for the generic enumservices 'names' different from both, e.g. talk for the enumservices related to the URIs sip, tel, h323 and the services voice and video, and 'message' for enumservice related to the URIs mailto: and tel: and the services mail, fax, sms, etc. It took me some time to understand this, and if you consider other people out there not so involved in the details, but interested in ENUM, we should try to avoid such pitfalls by using clearer definitions and giving some more explanations. > > What URI scheme(s) a specific NAPTR is tied to is specified > by the specification of the enumservice. Not by what > characters are in the enumservice itself. Agreed too, but to avoid duplicate work, the ENUM WG should come up with a clear generic scheme how to define enumservices. There should be a common practice and some guidance. One example could be my proposal, as already sent in response to Rich: 1. Group the templates around a URI. 2. Use as a memnonic for the enumservice the URI and one service Note: In this case the memnonoc for the enumservice is in most case selfexpaining. So a basic group of enumservices for tel could be: tel, telvoice, telfax, telsms, telmms, telems, telrn, telcic, teldn, ... Others may be added later, e.g. telmail (you may leave a message and it is sent with voicemail (a Shockey feature) Another enumservice group for mailto could be: mailto, mailtosms, mailtofax (to keep Rich happy, this means: if you want to send a fax, mail it), etc. So for a simple ENUM trial, we may start with: telvoice, telfax, telsms, sipvoice, h323voice, http, https, mailto And I can also explain the functions. The only thing is, I want to have the clients operational in September (2002). Regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed May 29 08:14:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13166 for ; Wed, 29 May 2002 08:14:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05971 for enum-archive@odin.ietf.org; Wed, 29 May 2002 08:14:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05434; Wed, 29 May 2002 08:05:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05405 for ; Wed, 29 May 2002 08:05:46 -0400 (EDT) Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12667 for ; Wed, 29 May 2002 08:05:20 -0400 (EDT) Received: from XCH-AMS-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4TC4PUr027152; Wed, 29 May 2002 14:04:37 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by XCH-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.3712); Wed, 29 May 2002 14:05:03 +0200 Received: from [10.0.0.252] ([171.68.225.134]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 29 May 2002 14:05:02 +0200 Date: Wed, 29 May 2002 14:04:03 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Stastny, Richard" , "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] SchemaSet strawman Proposal Message-ID: <20062589.1022681043@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.0 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 29 May 2002 12:05:03.0640 (UTC) FILETIME=[10B82980:01C20709] Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit --On 2002-05-29 12.13 +0200 "Stastny, Richard" wrote: > I am reading your e-mails always at least twice anway ;-) Sorry about that....my fault for not being able to express myself. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed May 29 12:55:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24522 for ; Wed, 29 May 2002 12:55:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28589 for enum-archive@odin.ietf.org; Wed, 29 May 2002 12:55:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27895; Wed, 29 May 2002 12:44:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27862 for ; Wed, 29 May 2002 12:44:33 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24088 for ; Wed, 29 May 2002 12:44:08 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4TGhoc00929; Wed, 29 May 2002 12:43:50 -0400 Message-Id: <5.1.0.14.2.20020529121102.027a6dd0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 May 2002 12:49:13 -0400 To: "Stastny, Richard" , "'Patrik =?iso-8859-1?Q?F=E4ltstr=F6m=27?=" , "'Richard Shockey'" , enum@ietf.org From: Richard Shockey Subject: RE: [Enum] SchemaSet strawman Proposal In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > > > > > > Since (according to Patrik) the same > > > characters should not be used, we are stuck here. > > > > Please read my mail again. > >I am reading your e-mails always at least twice anway ;-) > > > > I said people should in this discussion use different > > characters, because the name of the enumservice have > > _nothing_ to do with the characters in the URI scheme. > >I fully agree with you, that the enumservice is something different to the >URI used AND also to the services provided with a certain URI. This was also >the reason, why Lawrence used in his proposal for the generic enumservices >'names' different from both, e.g. talk for the enumservices related to the >URIs sip, tel, h323 and the services voice and video, and 'message' for >enumservice related to the URIs mailto: and tel: and the services mail, fax, >sms, etc. > >It took me some time to understand this, and if you consider other people >out there not so involved in the details, but interested in ENUM, we should >try to avoid such pitfalls by using clearer definitions and giving some more >explanations. I certainly see this ..there was a lot of confusion caused mixing and matching URI schemes and definition of services. I can see now that your and Larry's preference was to have a bit more structure to the enumservice label construct that would clearly hint at the URI during the first order processing when all the NAPTR records are returned .... where as I think Patrik and myself were thinking .. well ..so what, the key is properly defining and documenting the enumservice label so when the client application sees E2U+fooservice it knows exactly what URI and application to expect. > > > > What URI scheme(s) a specific NAPTR is tied to is specified > > by the specification of the enumservice. Not by what > > characters are in the enumservice itself. > >Agreed too, but to avoid duplicate work, the ENUM WG should come up with a >clear generic scheme how to define enumservices. There should be a common >practice and some guidance. I would not say "clear generic scheme" ..clear documentation for a specific label. yes ... but the clear difference has been your preference for a "URI hint [some character] service" vs my general theory of a simple 'label' that contains that information in a documented RFC. The label could therefore be anything In my way of thinking you could define a enumservice with the name "bubblebath" for a form of FTP and document that in a RFC and it would have the same meaning as "ftpfoobar" What you want is what you are stating below that there should be some general structure to the label in order for it to be more clearly read and understood. >One example could be my proposal, as already sent in response to Rich: > >1. Group the templates around a URI. >2. Use as a memnonic for the enumservice the URI and one service > >Note: In this case the memnonoc for the enumservice is in most case >selfexpaining. YES this is what I would call a label... creation of a simple mnemonic that can be documented to describe a unique and discrete service(s). >So a basic group of enumservices for tel could be: >tel, telvoice, telfax, telsms, telmms, telems, telrn, telcic, teldn, ... You could certainly bunch these into a single RFC .... >Others may be added later, e.g. telmail (you may leave a message and it is >sent with voicemail (a Shockey feature) > >Another enumservice group for mailto could be: >mailto, mailtosms, mailtofax (to keep Rich happy, this means: if you want to >send a fax, mail it), etc. yep something like a mailtofax would be the kind of label that would be useful and _appropriate_ for T.37/RFC2305 tel (PSTN) and mailto are the key examples where you have to create hints for different types of services since there is no 'on the wire' capability or service negotiation. I continue to suggest that is a key test of when and if you have to create more granular enumservice labels... >So for a simple ENUM trial, we may start with: >telvoice, telfax, telsms, sipvoice, h323voice, http, https, mailto this is a useful list Broken Record Speaking : sip only please. I do'nt see the distinction between sipvoice, sipvideo, simim, sipgame etc ..all I need to know is sip... another analogy/example of my concern here might be the Internet Print Protocol. IPP negotiates the capability of the endpoints during the session, therefore there would be no need to have enumservice mnemonics like ippb&w, ippcolorA10, ippstaple, ipp3holepunch etc. Ok ..maybe this example is a stretch ..but do you see what I mean. Could you map a TN to a printer ... sure. What is fax if not remote printing.... >And I can also explain the functions. The only thing is, I want to have the >clients operational in September (2002). this can be arranged ..... I think we are pretty close to consensus here .. >Regards >Richard >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed May 29 12:58:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24685 for ; Wed, 29 May 2002 12:58:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28761 for enum-archive@odin.ietf.org; Wed, 29 May 2002 12:59:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28131; Wed, 29 May 2002 12:49:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28089 for ; Wed, 29 May 2002 12:49:10 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24270 for ; Wed, 29 May 2002 12:48:45 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA14586; Wed, 29 May 2002 18:48:03 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA10982; Wed, 29 May 2002 18:48:05 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 18:48:04 +0200 Message-ID: From: Brandner Rudolf To: =?ISO-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , rich.shockey@neustar.com, "'Stastny, Richard'" , Conroy Lawrence Cc: enum@ietf.org Date: Wed, 29 May 2002 18:48:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Enum] enumservice field discussion Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi all, I had a bad vacation (only rain) and I'm having a bad e-mail day, too. Just coming back from vacation and digging through the enum mailing list I got more and more confused. In order to be able to start trials we need to sort out what the enumservice field should contain and what not. Then we can put that down into the docs to which the trials can refer. Having read the threads it looks to me that there are two camps: Camp A: proposing high level enumservices like talk, msg, etc. From an end systems view, this is fine with me. If I want to talk to someone, I am interested in URIs enabling me to talk to someone. Or if I want to deposit a message, I am interested in URIs to do so. If my end system gets URIs with protocols my end system is not capable of (false positives), it discards it. Camp B: proposing to have hints on URI schema in the enumservice field for early discard of false positives (see Patriks e-mail about X >= Y etc...). So it looks to me, that the whole discussion is going about when and where in the process of getting the URIs the false positives, if any, should be discarded. With Camp A proposal, this has to be done in the application (it knows what protocols the end system is capable of), with Camp B proposal it can be done within the D3S process (the enumservice field has tags or hints on the URIs it can deal with). Now let's look at the cost side here. The Camp B proposal saves computational resources by discarding false positives before doing the regexp. On the other hand, has higher cost on network traffic. If I have a sophisticated gadget with all kind of protocols in it and I want to send a message to someone, the end system will have to call ENUM several times to collect all possible URIs for the protocols to send a message (i.e. SMS, EMS, MMS, SMTP, FAX, etc.). The Camp A proposal collects all URIs for a given high level enumservice (i.e. talk, msg, etc.) by querying ENUM once, but potentially wasting computational resources by doing regexp on false positives. Now my question here is, how can we solve this situation? I, personally, are in favour on Camp A proposal, because I think (and history has proven it), that computational power of end systems is growing. So even some UMTS mobile gadgets will cope with this. Thinking of those UMTS mobile thingies, network resources are going to be scarce for quite a while in this arena, that's at least what I hear from the mobile guys. I can survive the tel, telvoice, telsms, telfax, telyounameit hell, but would be somehow unhappy (if anyone cares ;^) Patrik, Rich, Lawrence, Richard, your comments, please. Rudi _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed May 29 15:38:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00636 for ; Wed, 29 May 2002 15:38:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12492 for enum-archive@odin.ietf.org; Wed, 29 May 2002 15:39:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11432; Wed, 29 May 2002 15:27:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11401 for ; Wed, 29 May 2002 15:27:31 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00084 for ; Wed, 29 May 2002 15:27:07 -0400 (EDT) Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090285; Wed, 29 May 2002 20:27:14 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20020529121102.027a6dd0@popd.ix.netcom.com> References: <5.1.0.14.2.20020529121102.027a6dd0@popd.ix.netcom.com> Date: Wed, 29 May 2002 20:26:55 +0100 To: Richard Shockey From: Lawrence Conroy Subject: RE: [Enum] SchemaSet strawman Proposal Cc: "Stastny, Richard" , enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 12:49 pm -0400 29/5/02, Richard Shockey wrote: >In response to Richard Stastny's message: >>So a basic group of enumservices for tel could be: >>tel, telvoice, telfax, telsms, telmms, telems, telrn, telcic, teldn, ... > >You could certainly bunch these into a single RFC .... Ok, I can acquiesce in that. We have now moved completely away from the "high level services" of the strawman and towards a whole bunch of similar definitions with a common protocol hint but with different 'telecom service' endings. Hey, if we can put these into a single RFC, then I guess the extra cut-and-paste is tedious but not too hard. I'm not convinced that this is the ideal way of doing things, but if all other roads are blocked then we'll have to settle for where we can go. >>So for a simple ENUM trial, we may start with: >>telvoice, telfax, telsms, sipvoice, h323voice, http, https, mailto > >this is a useful list > >Broken Record Speaking : sip only please. I do'nt see the >distinction between sipvoice, sipvideo, simim, sipgame etc ..all I >need to know is sip... Hot Needle Responding: sipvoice for my WCOM account; sipim for my .NET IM account. Or, if preferred, rhovoice or rhoim, to avoid confusion with the URI-scheme. I have already said that I'll believe that peace breaks out between IM and voice providers when the U.K. elects a Martian (no, I mean a real one) as its President. > >another analogy/example of my concern here might be the Internet >Print Protocol. IPP negotiates the capability of the endpoints >during the session, therefore there would be no need to have >enumservice mnemonics like ippb&w, ippcolorA10, ippstaple, >ipp3holepunch etc. Ok ..maybe this example is a stretch ..but do >you see what I mean. > >Could you map a TN to a printer ... sure. What is fax if not remote >printing.... I believe that the svc tag on a tel: URI will be, for example, fax. I don't think the intent is anything more complex (G2, G3, ...). The difference between mms and sms or ems MAY be too picky and so may not be needed. IMHO, If it can be negotiated then there's no need for discrete tel URI svc tag. Similarly, in this situation there is no need for a separate enumservice. Also, if it is reasonable to expect a client that has a driver for one kind of message service to have a client for the other kind, then again, no separate enumservice. > >>And I can also explain the functions. The only thing is, I want to have the >>clients operational in September (2002). > >this can be arranged ..... I think we are pretty close to consensus here .. Actually, I have yet to see a rationale for this decision so I'm not sure that this dazed feeling of being clubbed into submission is consensus. Hey, I guess that's only semantics and in the end, the trials will clarify what works and what doesn't. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed May 29 16:42:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02572 for ; Wed, 29 May 2002 16:42:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16364 for enum-archive@odin.ietf.org; Wed, 29 May 2002 16:43:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15964; Wed, 29 May 2002 16:32:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15933 for ; Wed, 29 May 2002 16:32:37 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02339 for ; Wed, 29 May 2002 16:32:12 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4TKW4c06763; Wed, 29 May 2002 16:32:04 -0400 Message-Id: <5.1.0.14.2.20020529162503.02865a80@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 May 2002 16:37:29 -0400 To: Brandner Rudolf From: Richard Shockey Subject: Re: [Enum] enumservice field discussion Cc: enum@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org > >Camp B: proposing to have hints on URI schema in the enumservice field for >early discard of false positives (see Patriks e-mail about X >= Y etc...). > >So it looks to me, that the whole discussion is going about when and where >in the process of getting the URIs the false positives, if any, should be >discarded. With Camp A proposal, this has to be done in the application >(it knows what protocols the end system is capable of), with Camp B >proposal it can be done within the D3S process (the enumservice field has >tags or hints on the URIs it can deal with). > >Now let's look at the cost side here. The Camp B proposal saves >computational resources by discarding false positives before doing the >regexp. On the other hand, has higher cost on network traffic. If I have a >sophisticated gadget with all kind of protocols in it and I want to send a >message to someone, the end system will have to call ENUM several times to >collect all possible URIs for the protocols to send a message (i.e. SMS, >EMS, MMS, SMTP, FAX, etc.). >The Camp A proposal collects all URIs for a given high level enumservice >(i.e. talk, msg, etc.) by querying ENUM once, but potentially wasting >computational resources by doing regexp on false positives. Should't you assume that you or your applicaiton knows what enumservice its looking for before it querys DNS? You have preselected fax ? Or are you saying ..oh I want to query DNS BEFORE I send a message create a session to see what my options are? A fax machine is going only for mailtofax or something like that. My sip phone is only going to look for sip ... etc Remember the DNS will give you back ALL NAPTR records on any query. One other reason that I have dislike the discussion of all of these enumservice labels is that at some point you might break the UDP packet limit and force a DNS query via TCP, thus injecting more latency into the response. >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed May 29 16:47:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02755 for ; Wed, 29 May 2002 16:47:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16748 for enum-archive@odin.ietf.org; Wed, 29 May 2002 16:48:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16191; Wed, 29 May 2002 16:38:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16162 for ; Wed, 29 May 2002 16:38:32 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02475 for ; Wed, 29 May 2002 16:38:08 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4TKbic06850; Wed, 29 May 2002 16:37:49 -0400 Message-Id: <5.1.0.14.2.20020529161254.028b1d60@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 May 2002 16:40:20 -0400 To: Lawrence Conroy From: Richard Shockey Subject: RE: [Enum] SchemaSet strawman Proposal Cc: enum@ietf.org In-Reply-To: References: <5.1.0.14.2.20020529121102.027a6dd0@popd.ix.netcom.com> <5.1.0.14.2.20020529121102.027a6dd0@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 08:26 PM 5/29/2002 +0100, Lawrence Conroy wrote: >At 12:49 pm -0400 29/5/02, Richard Shockey wrote: >>In response to Richard Stastny's message: >>>So a basic group of enumservices for tel could be: >>>tel, telvoice, telfax, telsms, telmms, telems, telrn, telcic, teldn, ... >> >>You could certainly bunch these into a single RFC .... > >Ok, I can acquiesce in that. >We have now moved completely away from the "high level services" of the >strawman and towards a whole bunch of similar definitions with a common >protocol hint but with different 'telecom service' endings. I simply see this as what do you want to put in a enumservice label. Any reasonable alpha-numeric string will do so long as it is documented ... as you say this whole discussion has been about semantics . >Hey, if we can put these into a single RFC, then I guess the extra >cut-and-paste is tedious but not too hard. The key is the way the RFC is written and the need to conform to the requirements and tests that 2916bis will insist on. >>>So for a simple ENUM trial, we may start with: >>>telvoice, telfax, telsms, sipvoice, h323voice, http, https, mailto >> >>this is a useful list >> >>Broken Record Speaking : sip only please. I do'nt see the distinction >>between sipvoice, sipvideo, simim, sipgame etc ..all I need to know is sip... > >Hot Needle Responding: sipvoice for my WCOM account; sipim for my .NET IM >account. >Or, if preferred, rhovoice or rhoim, to avoid confusion with the URI-scheme. well we'll just have to wait for Yokohama and the Sumo fest we're going to have over this one. :-) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed May 29 22:08:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11065 for ; Wed, 29 May 2002 22:08:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA07492 for enum-archive@odin.ietf.org; Wed, 29 May 2002 22:09:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06281; Wed, 29 May 2002 21:59:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA06249 for ; Wed, 29 May 2002 21:59:25 -0400 (EDT) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10836 for ; Wed, 29 May 2002 21:59:00 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id DAA13205; Thu, 30 May 2002 03:59:08 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de ([139.21.200.84]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id DAA28659; Thu, 30 May 2002 03:59:22 +0200 (MET DST) Received: by MCHH274E with Internet Mail Service (5.5.2653.19) id ; Thu, 30 May 2002 03:59:22 +0200 Message-ID: From: Brandner Rudolf To: "'Richard Shockey'" Cc: enum@ietf.org Subject: AW: [Enum] enumservice field discussion Date: Thu, 30 May 2002 03:59:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA06250 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Rich, thanks for your comments, mine are inline... > -----Ursprüngliche Nachricht----- > Von: Richard Shockey [mailto:rich.shockey@NeuStar.com] > Gesendet: Mittwoch, 29. Mai 2002 22:37 > An: Brandner Rudolf > Cc: enum@ietf.org > Betreff: Re: [Enum] enumservice field discussion > > > > > > >Camp B: proposing to have hints on URI schema in the > enumservice field for > >early discard of false positives (see Patriks e-mail about X > >= Y etc...). > > > >So it looks to me, that the whole discussion is going about > when and where > >in the process of getting the URIs the false positives, if > any, should be > >discarded. With Camp A proposal, this has to be done in the > application > >(it knows what protocols the end system is capable of), with Camp B > >proposal it can be done within the D3S process (the > enumservice field has > >tags or hints on the URIs it can deal with). > > > >Now let's look at the cost side here. The Camp B proposal saves > >computational resources by discarding false positives before > doing the > >regexp. On the other hand, has higher cost on network > traffic. If I have a > >sophisticated gadget with all kind of protocols in it and I > want to send a > >message to someone, the end system will have to call ENUM > several times to > >collect all possible URIs for the protocols to send a > message (i.e. SMS, > >EMS, MMS, SMTP, FAX, etc.). > >The Camp A proposal collects all URIs for a given high level > enumservice > >(i.e. talk, msg, etc.) by querying ENUM once, but > potentially wasting > >computational resources by doing regexp on false positives. > > Should't you assume that you or your applicaiton knows what > enumservice its > looking for before it querys DNS? You have preselected fax ? > Or are you > saying ..oh I want to query DNS BEFORE I send a message > create a session to > see what my options are? Isn't that what ENUM is all about? I have a phone number and I want to know all means of communication associated with this phone number the domain holder is willing to reveal. At least, that's my view of what ENUM is and I might be off some miles here. > > A fax machine is going only for mailtofax or something like that. > ... or maybe .only. telfax? It looks like there might not always be one and only means of sending a fax. > My sip phone is only going to look for sip ... etc > I am here with you. However, my PC has a FAX software on it and is directly connected to my ISDN PBX. So sending a FAX I have the choice (and I personally like choices) to dial a number (might be an international one) to send the fax in case of telfax. Or I could dial up the local access number for my ISP and send the fax via e-mail in case of mailtofax. > Remember the DNS will give you back ALL NAPTR records on any query. > You are absolutely right, and D3S is throwing away some (useful) of them because I had to decide beforehand what protocol to use. Or I KNOW beforehand what means of communication are associated with this phone number. If I don't know it beforehand, I or my app needs to make a guess. mailtofax might probably be a good start querying ENUM. This query gives me all NAPTR records. What if it turns up nothing because there is no NAPTR with enumservice mailtofax? Then I or my app will have to make another guess: telfax perhaps. This query gives me all NAPTR records, again. Well, you get the picture. We have to make a decision one way or the other. This decision has implications on the clients, network and the ENUM servers. My concern here is, that we might get to a consensus based on 'dislike' or 'unacceptable' whithout having looked at the implications more closely or whithout good reasoning. > One other reason that I have dislike the discussion of all of these > enumservice labels is that at some point you might break the > UDP packet > limit and force a DNS query via TCP, thus injecting more > latency into the > response. > I assume that you are thinking about grouping enumservices. Yes, this is another implication we need to look at. To me, it looks like this is at least a two dimensional space. One dimension is the protocols to be used (which then lead to the associated URI), the other dimension is the function you can perform. This gives you a matrix of combinations and two possibilities of grouping. As an example (I am using some high level enumservices Lawrence proposed for this example and some URIs), which is not exhaustive: FUNCTION -------- : : --------+------+------+-------+---------+-------+------+-------- talk | * | * | * | * | | | --------+------+------+-------+---------+-------+------+-------- srs | | * | | | | | --------+------+------+-------+---------+-------+------+-------- deliver | * | | | * | | * | --------+------+------+-------+---------+-------+------+-------- | tel: | sip: | h323: | mailto: | http: | ftp: | ...... URI --- The question you raise here is, which way is better for grouping? Either proposal has implications on this, too. Actually, I did not do the combinatory stuff on this yet. Thus I am not sure, that there is a more optimal grouping or whether it is just mood because it is all the same, regardless which way you look at it. Hope this helps, Rudi > snip... _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 30 05:17:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27041 for ; Thu, 30 May 2002 05:17:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10144 for enum-archive@odin.ietf.org; Thu, 30 May 2002 05:18:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09884; Thu, 30 May 2002 05:08:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA09853 for ; Thu, 30 May 2002 05:08:52 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26980 for ; Thu, 30 May 2002 05:08:26 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 30 May 2002 10:55:30 +0200 Message-ID: From: "Stastny, Richard" To: "'Richard Shockey'" , Brandner Rudolf Cc: enum@ietf.org Date: Thu, 30 May 2002 10:55:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Enum] Triggering ENUM Queries Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi folks, good morning, Rich wrote in response to Rudi: > Should't you assume that you or your applicaiton knows what > enumservice its > looking for before it querys DNS? You have preselected fax ? > Or are you > saying ..oh I want to query DNS BEFORE I send a message > create a session to > see what my options are? I think we have a point here, why there are different camps: Camp B is assuming, that the ENUM query is launched from within an application which already nows what it is looking for, so there should be an efficient way to find out the ONE useful NAPTR (from the enumservice field). Camp A has a broader view and see in addition the user who just wants to communicate with another user and has not decided yet, how he will do this. So the user is querying ENUM, retrieving all NAPTR records e.g. by a stand-alone application, and gets the result displayed in a user meaningful format, e.g. URLs sorted by tel, fax, sms, mail, like on a business card. The user is now selecting the proper appclication by clicking on the URL. This also explains, that this camp has no problem with peeking ahead beyond the enumservices field. To summarize, we really have three principle ways to trigger an ENUM query, and we want to use the trials to find out the user preferences (maybe all tree variants are needed anyway): 1. Stand-alone ENUM Client: The stand-alone ENUM client is given an E.164 Number in the format +431..., retrieving all NAPTRs (and ev. other records) from the given domain and displaying them in a human readable and grouped form, eg. Richard Stastny Currently at the IETF in Yokohama To talk: sip:user@host To send a fax message: tel:+431...;svc=fax To send an e-mail: mailto:user@host To send an sms: tel:+43664...;svc=sms To look on my webpage: http://www.stastny.com Note that the additional text may come from TXT records The user may now select the way to communicate, eg. he may first look up the webpage (first choice for if you want to communicate with a company). If he has no sip-client, he cannot talk. It is obvious, that the above information is preferably in the following NAPTRs: NAPTR blabla "E2U+talk" blabla sip:user@host NAPT blabla "E2U+msg" blabla tel:+431...;svc=fax NAPTR blabla "E2U+msg" blabla mailto:user@host NAPTR blabla "E2U+msg" blabla tel:+43664..;svc=sms NAPTR blabla "E2U+info" blabla http://www.stastny.com I agree, that I can create the same information from the enumservices sip(voice), telfax, mailto, telsms, info. 2. ENUM queries from specific applications If I have my fax-client or sms-client already started, and enter +431... in the To field of my fax client, it is obvious, that I want a 'msg' service with svc=fax (so I have to peek ahead) or 'telfax' or ?. So the application is launching an ENUM add-on, querying ENUM DNS and replacing the entered phone number with the URI retrieved from ENUM (similar to Outlook, if it replaces a contact name entered). Sip and tel are special in both cases: Sip may be used for additional services than talk, but tel may also be used by sip, if your service provider allows you to INVITE E.164 numbers (has a gateway). Anyway, I have to admit, that the camp B proposal is more straightforward for this requirements. In response to Rich: In this case I suggest to have both sip AND sipvoice AND sipwhatever. Sip only means, that you should negotiate the services (except for services already listed in other NAPTRs). Note: As one sees, I try to avoid the usage of order and preference. Order IMHO shall not be used (currently) within the ENUM system at all, with preference I am not sure yet. Maybe the trials will show. 3. ENUM query triggered by URL I also see a third possibility to launch an ENUM query: by clicking on an URL on a webpage or in a document. This is a bit different from the usage of URL in the stand-alone client, because then I use the URL AFTER the ENUM query. The problem here is, that this requires some additions to the existing URI schemes, eg: mailto:+431... or sip:+431... or http://+431... If there is an ambiguity, whether ENUM should be queried or not, a ;svc=enum parameter could be used. If such an URL is used, the corresponding application should be launched and, provided there is an ENUM add-on, ENUM should be queried, and the number should be replaced with the retrieved URI as in 2. Proposal of a new URI scheme enum:+431... This leads to another requirement: If a user has an ENUM entry, it does not make sense to list all the different URLs e.g. on his e-mail signature, pointing to the same ENUM entry. He may just want to say, hey guys, I am in ENUM, you can get all information there. Therefore a new URI scheme is required: enum:+431... This URL would launch the standalone client from 1. and I can also imagine, that a bubble with the information pops up, if you hoover with the mouse over the URL ;-) The new URI scheme ENUM may also come in handy to forward the complete E.164 domain to another number, including all services. If I enter in my office number domain +4317978032 NAPTR blabla "E2U+enum" blabla enum:+436644204100 I can forward now ALL services to my mobile number, having all records in one place. This is proposed as alternative to the use of CNAME for End Users. Note: For forwarding of voice calls only the usage of tel: was proposed. This is IMHO problematic for different reasons: DNS is not designed for (too) dynamic updates anyway, forwardings should be done with the personal user agent of the provider, It may be confusing to the user, if he has differnt forwardings on his GSTN line and on ENUM, and these fwds are not synchronized. And last but not least, the construct is ambiguos: if you retrieve a tel:+431..., should you use this to establish a connection to the GSTN directly via a gateway, or launch another ENUM query (thsi could be solved also with the svc=enum parameter) Best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Thu May 30 05:54:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27556 for ; Thu, 30 May 2002 05:54:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12350 for enum-archive@odin.ietf.org; Thu, 30 May 2002 05:54:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA12022; Thu, 30 May 2002 05:45:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11923 for ; Thu, 30 May 2002 05:45:34 -0400 (EDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27504 for ; Thu, 30 May 2002 05:45:08 -0400 (EDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id g4U9jQd01896; Thu, 30 May 2002 09:45:26 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.35 #1) id 17DMUk-000CRs-00; Thu, 30 May 2002 10:45:22 +0100 Date: Thu, 30 May 2002 10:45:22 +0100 From: "Clive D.W. Feather" To: "Stastny, Richard" Cc: "'Richard Shockey'" , Brandner Rudolf , enum@ietf.org Subject: Re: [Enum] Triggering ENUM Queries Message-ID: <20020530094522.GL28471@finch-staff-1.demon.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Stastny, Richard said: > Camp B is assuming, that the ENUM query is launched from within an > application which already nows what it is looking for, so there should be an > efficient way to find out the ONE useful NAPTR (from the enumservice field). [...] A DNS query is going to return all the records no matter what, isn't it. So we should perhaps be looking at minimizing the size of the NAPTR record. This would imply that the service field should not duplicate anything that's available in the resulting URL. It seems to me that this is more important than reducing the processing time slightly. Is there any way we can modify the specification of the REs to make it easier to determine what protocol is used ? I don't mean replacing the RE by something else, but an idea like "if the RE doesn't rewrite the protocol field of the URI, the RE delimiter is '!'; if it does, the delimiter is something else". Would this help ? -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 30 08:47:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01975 for ; Thu, 30 May 2002 08:47:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA24020 for enum-archive@odin.ietf.org; Thu, 30 May 2002 08:48:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23098; Thu, 30 May 2002 08:39:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23066 for ; Thu, 30 May 2002 08:39:17 -0400 (EDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01632 for ; Thu, 30 May 2002 08:38:50 -0400 (EDT) Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by internal.mail.demon.net with ESMTP id g4UCcsd24449; Thu, 30 May 2002 12:38:54 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.35 #1) id 17DPCc-000Jod-00; Thu, 30 May 2002 13:38:50 +0100 Date: Thu, 30 May 2002 13:38:50 +0100 From: "Clive D.W. Feather" To: Lawrence Conroy Cc: Richard Shockey , "Stastny, Richard" , enum@ietf.org Subject: Re: [Enum] SchemaSet strawman Proposal Message-ID: <20020530123850.GO28471@finch-staff-1.demon.net> References: <5.1.0.14.2.20020529121102.027a6dd0@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Lawrence Conroy said: >> this can be arranged ..... I think we are pretty close to consensus here > Actually, I have yet to see a rationale for this decision so I'm not sure > that this dazed feeling of being clubbed into submission is consensus. I have to agree - I don't see consensus. I don't even see a solid understandable proposal that consensus might happen around. -- Clive D.W. Feather | Work: | Tel: +44 20 8371 1138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 30 09:52:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05025 for ; Thu, 30 May 2002 09:52:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA00582 for enum-archive@odin.ietf.org; Thu, 30 May 2002 09:53:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29763; Thu, 30 May 2002 09:43:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29731 for ; Thu, 30 May 2002 09:43:15 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04485 for ; Thu, 30 May 2002 09:42:49 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 30 May 2002 15:29:55 +0200 Message-ID: From: "Stastny, Richard" To: "'Clive D.W. Feather'" , Lawrence Conroy Cc: Richard Shockey , "Stastny, Richard" , enum@ietf.org Subject: RE: [Enum] SchemaSet strawman Proposal Date: Thu, 30 May 2002 15:29:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Clive said: > Lawrence Conroy said: > >> this can be arranged ..... I think we are pretty close to > consensus > >> here > > Actually, I have yet to see a rationale for this decision > so I'm not > > sure that this dazed feeling of being clubbed into submission is > > consensus. > > I have to agree - I don't see consensus. I don't even see a > solid understandable proposal that consensus might happen around. > Maybe one reason that there is no proposals around yet is, that nobody wants to put an effort into this, before he sees the main direction to go. There have been at least two (three) proposals on the list, but most responses where not constructive like: in priciple yes, but have you considered that also, or yes, but this a want different, etc. Most responses where destructive: No, I do not like this, this does not work, etc. Lets try again: Currently three variants of enumservices definitions are under discussion: Variant 1: Same name as URI e.g.: sip, mailto, tel, as in the examples in RFC2916bis. Note: causes problems with URIs with multiple use (e.g. tel:) Variant 2: Generic grouping (strawman) e.g.: talk (former tel) or rtc (real-time communications), all voice and video msg Message, all mail, fax, sms, etc info or file (all http, ftp and document retrieval) srs (former sip) Service Resolution Service (srs) streaming for broadcast of audio and video pres presence, location (GPS coordinates of company) key for public keys (just created this one) Chat or included in rtc any for complete forwarding of ENUM domain This solution requires peek-ahead into the URI and svc, but as already stated by Rudi and Clive, this should be a problem and reduces the number of NAPTR, which may be more advantage. The related URIs have already be listed by Lawrence Variant 3: Combination of URI and Service e.g.: mailto, telvoice, telfax, telsms, sipvoice, h323voice, http, https, enum, etc. The advantage of this proposal is, that the functionality is nearly selfexplaining. This is BTW the initial list of URIs and services used for our trial. I consider variant 2 more elegant, but could live (at least for the trial) also with this variant. Some additional comments: The enumservice enum may be used to forward all services of a given E.164 number to another E.164 number (instead of using CNAME, which may case problems in general and also within the DDDS algorithm). This service requires a new URI "enum:" to be defined. It should be noted, that this new URI may also be convenient for usage to trigger an ENUM query from a link in a web-page or document (e.g. in an e-mail signature). The new URI has the format enum:+431... and shall trigger the launch of an ENUM application able to query the DNS and giving back all information stored under this number. First, are there other proposals? If yes, show the at least in principle If not, could we agree that the final solution is one of the three variant and maybe vote, which one is preferred. If one or two variants are left over to be considered seriously, I could imagine, that one or two drafts still can be created for Yokohama, containing "solid understandable proposals". Best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 30 10:41:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07270 for ; Thu, 30 May 2002 10:41:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05094 for enum-archive@odin.ietf.org; Thu, 30 May 2002 10:41:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04536; Thu, 30 May 2002 10:32:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04505 for ; Thu, 30 May 2002 10:32:52 -0400 (EDT) Received: from bailey.dscga.com (bailey.neonym.net [198.78.11.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07021 for ; Thu, 30 May 2002 10:32:27 -0400 (EDT) Received: from bailey.dscga.com (localhost [127.0.0.1]) by bailey.dscga.com (8.12.1/8.12.1) with ESMTP id g4UEV5Et002562; Thu, 30 May 2002 10:31:05 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g4UEV4jZ002561; Thu, 30 May 2002 10:31:04 -0400 (EDT) Date: Thu, 30 May 2002 10:31:04 -0400 From: Michael Mealling To: "Stastny, Richard" Cc: "'Richard Shockey'" , Brandner Rudolf , enum@ietf.org Subject: Re: [Enum] Triggering ENUM Queries Message-ID: <20020530103104.C1019@bailey.dscga.com> Reply-To: Michael Mealling References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org On Thu, May 30, 2002 at 10:55:29AM +0200, Stastny, Richard wrote: > Camp B is assuming, that the ENUM query is launched from within an > application which already nows what it is looking for, so there should be an > efficient way to find out the ONE useful NAPTR (from the enumservice field). > > Camp A has a broader view and see in addition the user who just wants to > communicate with another user and has not decided yet, how he will do this. > > To summarize, we really have three principle ways to trigger an ENUM query, > and we want to use the trials to find out the user preferences (maybe all > tree variants are needed anyway): > > 1. Stand-alone ENUM Client: > > The stand-alone ENUM client is given an E.164 Number in the format +431..., > retrieving all NAPTRs (and ev. other records) from the given domain and > displaying them in a human readable and grouped form, eg. > > Richard Stastny > Currently at the IETF in Yokohama > > To talk: sip:user@host > To send a fax message: tel:+431...;svc=fax > To send an e-mail: mailto:user@host > To send an sms: tel:+43664...;svc=sms > To look on my webpage: http://www.stastny.com > > 2. ENUM queries from specific applications > > If I have my fax-client or sms-client already started, and enter +431... in > the To field of my fax client, it is obvious, that I want a 'msg' service > with svc=fax (so I have to peek ahead) or 'telfax' or ?. So the application > is launching an ENUM add-on, querying ENUM DNS and replacing the entered > phone number with the URI retrieved from ENUM (similar to Outlook, if it > replaces a contact name entered). > > 3. ENUM query triggered by URL IMHO, the first (or Camp A) should be a service in Camp B. If you simply willy nilly show the user all NAPTR records regardless of any priority settings or inquiry-style referral (e.g. LDAP or SIP) then you're doing something that isn't explicit and is prone to confusion. You're basically negating the ability to use preferences at all by ignoring them and showing the user _everything_ regardless of whether or not the user should even be seeing it. IMHO, if you need to do #1 (don't get me wrong, I think its a cool application) then I think you need to specify that information behind something that can express policy and do it as an explicit query. I guess my problem with the scheme you suggest in #1 is that "ENUM is used for turning an E.164 number into a URI", not advertising service endpoints intended for a user interface. I realize the distinction is subtle but its an important one (especially when you throw in the mention of "additional text can be returned in TXT records". Does that mean I can put logos and pop up ads in there too?) -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 30 11:24:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08862 for ; Thu, 30 May 2002 11:24:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09342 for enum-archive@odin.ietf.org; Thu, 30 May 2002 11:25:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08472; Thu, 30 May 2002 11:16:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08440 for ; Thu, 30 May 2002 11:16:05 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08579 for ; Thu, 30 May 2002 11:15:40 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 30 May 2002 17:02:44 +0200 Message-ID: From: "Stastny, Richard" To: "'Michael Mealling'" Cc: "'Richard Shockey'" , Brandner Rudolf , enum@ietf.org Subject: RE: [Enum] Triggering ENUM Queries Date: Thu, 30 May 2002 17:02:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Michael wrote: > IMHO, the first (or Camp A) should be a service in Camp B. If > you simply willy nilly show the user all NAPTR records > regardless of any priority settings or inquiry-style referral > (e.g. LDAP or SIP) then you're doing something that isn't > explicit and is prone to confusion. You're basically negating > the ability to use preferences at all by ignoring them and > showing the user _everything_ regardless of whether or not > the user should even be seeing it. Have you ever been confused with a business card? Maybe if it was from somebody from Japan and you looked at the wong side ;-) Anyway, I have seen so many ideas and possiblities to use ENUM, and I have currently no idea what the users will really prefer. So a major target of our trial is to find out what the users really are going for. We also may have the problem, that the called user may have one idea and the called user another. Also regarding the preferences you may have two approaches: One is to list e.g. three phone URIs with preference. This is in my opinion quite useless for the calling party, because I want to reach the called party and do not want to try three URIs. The other is to give preferences for different services, eg. Mail is preferred. This is nice, and could be listed also with the stand-alone client (e.g. e-mail is preferred), but this does not help a caller very much if he is calling from a steam phone. So our intention is to be open for all of these variants in the trial and find out what the users are doing. I only expect, that some users will like this and others that, as you see on the list. We all are potential users, arent we? ;-) > > IMHO, if you need to do #1 (don't get me wrong, I think its a > cool application) then I think you need to specify that > information behind something that can express policy and do > it as an explicit query. I guess my problem with the scheme > you suggest in #1 is that "ENUM is used for turning an E.164 > number into a URI", not advertising service endpoints > intended for a user interface. I realize the distinction is > subtle but its an important one > (especially when you throw in the mention of "additional text > can be returned in TXT records". Does that mean I can put > logos and pop up ads in there too?) Why not? That is the reason also for the enumservice involving http. I expect ENUM to be used by companies and with 800 and 900 numbers, and they may want to provide a link to their web-page (especially for their hotline) or additional information like address (thats why some location information is needed), or opening hours or whatever in TXT records. TXT records may also be usefull for info on incomplete or invalid numbers. This is also an area for investigation. You can use either TXT, http and/or announcements. Regards Richard > > -MM > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 30 11:25:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08895 for ; Thu, 30 May 2002 11:25:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09467 for enum-archive@odin.ietf.org; Thu, 30 May 2002 11:26:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08602; Thu, 30 May 2002 11:17:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08575 for ; Thu, 30 May 2002 11:17:21 -0400 (EDT) Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08635 for ; Thu, 30 May 2002 11:16:56 -0400 (EDT) Received: from [193.118.192.111] (HELO [193.118.192.41]) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090304; Thu, 30 May 2002 16:17:04 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: Date: Thu, 30 May 2002 16:16:47 +0100 To: Rudi From: Lawrence Conroy Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] The Matrix Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Hi Rudi, folks, Welcome back to work and hope you dry out soon - Nice two-dimensional matrix! At 3:59 am +0200 30/5/02, Brandner Rudolf wrote: >To me, it looks like this is at least a two dimensional space. One >dimension is the protocols to be used (which then lead to the >associated URI), the other dimension is the function you can >perform. This gives you a matrix of combinations and two >possibilities of grouping. As an example (I am using some high >level enumservices Lawrence proposed for this example and some >URIs), which is not exhaustive: > >FUNCTION >-------- >: >: >--------+------+------+-------+---------+-------+------+-------- >talk | * | * | * | * | | | >--------+------+------+-------+---------+-------+------+-------- >srs | | * | | | | | >--------+------+------+-------+---------+-------+------+-------- >deliver | * | | | * | | * | >--------+------+------+-------+---------+-------+------+-------- > | tel: | sip: | h323: | mailto: | http: | ftp: | ...... URI > --- > >The question you raise here is, which way is better for grouping? >Either proposal has implications on this, too. Um...to use this, I suspect we need to define BOTH elements. Thus there will need to be: * a description of (say) the 'talk' function and the the URIs that might be used to provide it, PLUS * a description of (say) tel: operation with an explanation of how it works to provide each of the functions (with any special operational features that are specific to this protocol/function combination) We could conflate each of these into a constellation of cross points (e.g. sdkTALK for an emumservice that is the product of the talk function and the tel: protocol/URI-scheme). We could combine these points into a smaller number of RFCs. For example, a single RFC could cover a column of the matrix. Alternatively, a separate RFC could be provided for each row of the matrix. I think that, with this conflation, either way there is bound to be a duplication of text. Just choose an orientation. The alternative I looked at with the strawman is to produce separate text for each column header and row header. Thus there'd be a document describing the 'talk' function, another to describe the 'deliver' function, and separate documents each describing the 'tel:, 'h323:', and 'sip:' protocols/URI-schemes. These could be combined by reference only. Thus for a talk service using tel:, look at the document describing 'talk', the separate document describing 'tel:', and that's it. For a talk service using h323:, look instead at the 'h323:' protocol document. Any other offers? OK, folks, place your bets; - vertical, - horizontal, - exhaustive cloud of individual points, or - individual column/row headers only (pick your own). or... - some scheme that is NOT in the above set of choices. all the best, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Thu May 30 13:42:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14770 for ; Thu, 30 May 2002 13:42:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23732 for enum-archive@odin.ietf.org; Thu, 30 May 2002 13:42:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22633; Thu, 30 May 2002 13:29:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22583 for ; Thu, 30 May 2002 13:29:15 -0400 (EDT) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14236 for ; Thu, 30 May 2002 13:28:47 -0400 (EDT) Received: from dick.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4UHSUc26992; Thu, 30 May 2002 13:28:30 -0400 Message-Id: <5.1.0.14.2.20020530131501.02916a50@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 30 May 2002 13:31:50 -0400 To: "Stastny, Richard" , "'Michael Mealling'" From: Richard Shockey Subject: RE: [Enum] Triggering ENUM Queries Cc: Brandner Rudolf , enum@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org At 05:02 PM 5/30/2002 +0200, Stastny, Richard wrote: >Michael wrote: > > > IMHO, the first (or Camp A) should be a service in Camp B. If > > you simply willy nilly show the user all NAPTR records > > regardless of any priority settings or inquiry-style referral > > (e.g. LDAP or SIP) then you're doing something that isn't > > explicit and is prone to confusion. You're basically negating > > the ability to use preferences at all by ignoring them and > > showing the user _everything_ regardless of whether or not > > the user should even be seeing it. I know I continue to sound like the skunk at the garden party ..but Michael has a excellent point here that I have a lot of trouble with ... Is the DNS the appropriate mechanism to display all the user preferences for communication ... IMHO NO ... this is something I want to have more control over either in a directory that can authenticate who is asking for the information or SIP where a defined CPL that has the expression of my preferences or other mechanism can be used to define or transfer the session to something else. >Have you ever been confused with a business card? Maybe if it was from >somebody from Japan and you looked at the wong side ;-) > >Anyway, I have seen so many ideas and possiblities to use ENUM, and I have >currently no idea what the users will really prefer. So a major target of >our trial is to find out what the users really are going for. We also may >have the problem, that the called user may have one idea and the called user >another. Exactly we need to see how all of this works but ultimately it will be user that has control over the e.164 number that registers it under e164.arpa and my suspicion is that will be a minimalist set listed . Just MHO >Also regarding the preferences you may have two approaches: >One is to list e.g. three phone URIs with preference. This is in my opinion >quite useless for the calling party, because I want to reach the called >party and do not want to try three URIs. > >The other is to give preferences for different services, eg. Mail is >preferred. This is nice, and could be listed also with the stand-alone >client (e.g. e-mail is preferred), but this does not help a caller very much >if he is calling from a steam phone. > >So our intention is to be open for all of these variants in the trial and >find out what the users are doing. I only expect, that some users will like >this and others that, as you see on the list. We all are potential users, >arent we? ;-) or another variation ...use LDAP > > > > IMHO, if you need to do #1 (don't get me wrong, I think its a > > cool application) then I think you need to specify that > > information behind something that can express policy and do > > it as an explicit query. I guess my problem with the scheme > > you suggest in #1 is that "ENUM is used for turning an E.164 > > number into a URI", not advertising service endpoints > > intended for a user interface. I realize the distinction is > > subtle but its an important one > > (especially when you throw in the mention of "additional text > > can be returned in TXT records". Does that mean I can put > > logos and pop up ads in there too?) > >Why not? That is the reason also for the enumservice involving http. I >expect ENUM to be used by companies and with 800 and 900 numbers, and they >may want to provide a link to their web-page (especially for their hotline) >or additional information like address (thats why some location information >is needed), or opening hours or whatever in TXT records. TXT records may >also be usefull for info on incomplete or invalid numbers. This is also an >area for investigation. You can use either TXT, http and/or announcements. On this BTW I really agree with this there is a lot of investment in freephone numbers. On the SIP side I've almost considered doing a ID on a new SIP header for HTTP URI so that all the new SIP phones with color LED's can display the web page of the called party...useful for Pizza Specials etc. >Regards >Richard > > > > > -MM > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 45980 Center Oak Plaza Bldg 8 Sterling, VA 20166 1120 Vermont Ave NW Suite 400 Washington DC 20005 Voice +1 571.434.5651 Cell : +1 314.503.0640, Fax: +1 815.333.1237 or <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri May 31 03:49:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08356 for ; Fri, 31 May 2002 03:49:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA11237 for enum-archive@odin.ietf.org; Fri, 31 May 2002 03:50:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10613; Fri, 31 May 2002 03:36:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10579 for ; Fri, 31 May 2002 03:36:00 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08053 for ; Fri, 31 May 2002 03:35:33 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Fri, 31 May 2002 09:22:23 +0200 Message-ID: From: "Stastny, Richard" To: "'Richard Shockey'" , "'Michael Mealling'" Cc: Brandner Rudolf , enum@ietf.org Subject: RE: [Enum] Triggering ENUM Queries Date: Fri, 31 May 2002 09:22:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Rich wrote: > Michael has a excellent point here that I have a lot of > trouble with ... Is > the DNS the appropriate mechanism to display all the user > preferences for > communication ... IMHO NO ... this is something I want to > have more control > over either in a directory that can authenticate who is > asking for the > information or SIP where a defined CPL that has the expression of my > preferences or other mechanism can be used to define or transfer the > session to something else. > I think this is exactly one of the issues why we see nor progress here. There are a lot of variants how you can use ENUM, the two extremes are: 1. put everything you want to be known in ENUM, ending up with a lot NAPTRs 2. put ONE pointer to a Personal User Agent (PUA), which controls your complete communication (including screening, filtering, etc.) Of course, for the group heading in the second direction, the whole discussion on enumservices is somewhat ridiculous, they say (depending in the multiservice they prefer), just put in sip, h323, pres, srs, uci, .... And here we are again at the point: as long as we do not have these multiservices PUAs in operation, we have to live with the multiple NAPTRs, different URIs and services. I my personal opinion, the future will be with the PUA type services, and thats exactly the reason why I am also involved in UPT and UCI (Universal Communications Identifier) (see 31-WP1 from lthis May SG2 or ETSI STF180). And this is also the reason, why we requested the delegation og +87810 for ENUM (which was approved in May SG2). With UPT, you terminate on the same PUA regardless if you are using the GSTN with the UPT number or ENUM pointing to a H323 or SIP-address. There is also a clear path from ENUM via UPT to UCI (the numeric key of UCI will be an E.164 numbers). But we all should keep one thing in mind: if UPT/UCI is fully implemented as intended, you do not need (User) ENUM anymore (maybe infrstructure ENUM). This means, that the window of opportunity for ENUM is closing very fast. Little remark: currently ITU SG2 is progressing more and faster with ENUM then the IETF. As far as the ITU is concerned, we can start with the trials in e164.arpa now, as far as the IETF ENUM WG, we cannot, because there is not a single enumservice defined. > Exactly we need to see how all of this works but ultimately > it will be user > that has control over the e.164 number that registers it > under e164.arpa > and my suspicion is that will be a minimalist set listed . Just MHO Yes, if the services are available and compatible. Everybody now may have an e-mail address, but where can I subcribe a full sip service? BTW, where can a subscribe a sip service, where I am able to get a sip URI sip:user@host? > or another variation ...use LDAP Yes, I have some ideas on the stack with LDAP (e.g. names, addresses, public keys, etc.) > On this BTW I really agree with this there is a lot of investment in > freephone numbers. On the SIP side I've almost considered > doing a ID on a > new SIP header for HTTP URI so that all the new SIP phones > with color LED's > can display the web page of the called party...useful for > Pizza Specials etc. > I have seen this idea a long time ago (2-3 years?)in TIPHON for h323, exactly for this purpose. I think it was from Nokia or Ericsson. I have no idea what happend to this. Maybe you ask Melinda. Regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri May 31 04:31:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09015 for ; Fri, 31 May 2002 04:31:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA14631 for enum-archive@odin.ietf.org; Fri, 31 May 2002 04:32:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13735; Fri, 31 May 2002 04:23:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13703 for ; Fri, 31 May 2002 04:22:52 -0400 (EDT) Received: from oefeg-mail.oefeg.at (mail.oefeg.at [62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08942 for ; Fri, 31 May 2002 04:22:26 -0400 (EDT) Received: by OEFEG-MAIL with Internet Mail Service (5.5.2650.21) id ; Fri, 31 May 2002 10:09:30 +0200 Message-ID: From: "Stastny, Richard" To: "'Lawrence Conroy'" , Rudi Cc: enum@ietf.org Subject: RE: [Enum] The Matrix Date: Fri, 31 May 2002 10:09:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Lawrence wrote: > At 3:59 am +0200 30/5/02, Brandner Rudolf wrote: > >To me, it looks like this is at least a two dimensional space. Sorry, it is at least tree dimensional: The function you can perform, the URI and the Service related to the URI (e.g voice, fax, sms, etc) Of course you have the service (have you?) defined with the URI, but are they consistently defined? My problem is, that at least I have no complete overview on the URI definitions under discussion. I would like to see, that e.g. voice or fax can be used with tel, sip, h323 and what else? > OK, folks, place your bets; > - vertical, > - horizontal, > - exhaustive cloud of individual points, or > - individual column/row headers only (pick your own). > or... > - some scheme that is NOT in the above set of choices. > So what is in the jackpot? A lady from Austria just won 22 Mio $ in Las Vegas. So, for the horizontal scheme, we either define just the function to perform, list the URIs allowed and point to the relevant URI description. But this works only, if peek-ahead is allowed. If not, we need to define things like talktelvoice, talksipvoice etc., which is a bit awkward and not much better then the vertical approach So the vertical approach comes in: Use the already proposed URI - service combinations eg telvoice, sipvoice, etc.. The grouping could be done within the client itself for display. Since the services are defined explicitely, not all services need to be defined on the first run, and they can be defined consistently. So in my opinion the question if peek-ahead is allowed should be clarified. We could also leave this for later, because: The two schemes are compatible, since all the names used for the horizontal scheme are (on purpose) different from the names of the vertical scheme. Clients could easily live with both schemes, the NAPTR "generators" may choose one of the two. The final scheme may be selected either in Yokohama or even after the trials. I suggest that we come up with two lists, finally ending up in two "drafts" for IDs. I volunteer to put on the list a proposal for the vertical scheme, and collect further inputs, maybe Lawrence is doing the hoizontal one? I think we need something concrete to discuss. Best regards Richard _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri May 31 14:56:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27278 for ; Fri, 31 May 2002 14:56:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA26937 for enum-archive@odin.ietf.org; Fri, 31 May 2002 14:56:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26423; Fri, 31 May 2002 14:36:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26392 for ; Fri, 31 May 2002 14:36:35 -0400 (EDT) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26185 for ; Fri, 31 May 2002 14:36:07 -0400 (EDT) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4VIYjl17040 for ; Fri, 31 May 2002 14:34:45 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g4VIYjx17028 for ; Fri, 31 May 2002 14:34:45 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Enum] The Matrix Date: Fri, 31 May 2002 12:37:21 -0600 Message-ID: Thread-Topic: [Enum] The Matrix Thread-Index: AcIIhuXojpEBleVxRx2g1Saim8+1yAASYJ4Q From: "Zmolek, Andrew (Andrew)" To: "Stastny, Richard" , "Lawrence Conroy" , "Rudi" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA26393 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Richard Stastny wrote: > So the vertical approach comes in: > Use the already proposed URI - service combinations eg > telvoice, sipvoice, etc.. The grouping could be done > within the client itself for display. Since the > services are defined explicitely, not all services need > to be defined on the first run, and they can be defined > consistently. This so-called 'vertical approach' is really a row-by-row combination of row elements, not a pure vertical approach which would list only the rows themselves. The vertical approach was: 'talk' or 'voice' or something, 'enquire' or 'query' or something, 'deliver' or 'message' or some such 'chat' or 'texttalk' or something similar, et cetera I've even been thinking about something like: 'verify' or 'certificate' or a similar service [that points to a certificate or authenticator URI for non-repudiation of identity--but that's an enumservice for later] Anyway, I think this matrix thread is the right discussion to have regarding schema. Are we to the point where each of the 3+ camps needs to (1) put forth specific schema proposals and (2) show the specific benefits of sticking to a single schema vs. using any and all comers? Perhaps that would be the main focus of our Yokohama meeting, since I detect that we aren't getting enough traction on the list itself on any specific direction other than the need for a sensible schema. --Andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri May 31 15:12:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27863 for ; Fri, 31 May 2002 15:12:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA28324 for enum-archive@odin.ietf.org; Fri, 31 May 2002 15:12:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27700; Fri, 31 May 2002 15:03:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27669 for ; Fri, 31 May 2002 15:03:42 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27572 for ; Fri, 31 May 2002 15:03:14 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11866 for ; Fri, 31 May 2002 15:01:57 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11849 for ; Fri, 31 May 2002 15:01:57 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [Enum] Triggering ENUM Queries Date: Fri, 31 May 2002 13:04:28 -0600 Message-ID: Thread-Topic: [Enum] Triggering ENUM Queries Thread-Index: AcIIe7JF3IQ5azfBQUS1qTIbFUL+DQAVsFUQ From: "Zmolek, Andrew (Andrew)" To: "Stastny, Richard" , "Richard Shockey" , "Michael Mealling" Cc: "Brandner Rudolf" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA27670 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit Richard Stastny wrote: > 2. put ONE pointer to a Personal User Agent (PUA), which controls your > complete communication (including screening, filtering, etc.) > > Of course, for the group heading in the second direction, the whole > discussion on enumservices is somewhat ridiculous, they say > (depending in > the multiservice they prefer), just put in sip, h323, pres, > srs, uci, .... > > And here we are again at the point: as long as we do not have these > multiservices PUAs in operation, we have to live with the > multiple NAPTRs, > different URIs and services. I think this is the crux of the issue, e.g. ENUM will ultimately be used as a way of resolving an arbitrary E.164 number into associated PUA services, but the bootstrapping of ENUM may depend on more exposure of these services until the interfaces and protocols for PUA services are well defined and widespread. This is why the schema matters, since the success of the bootstrap depends on the widespread use of a well-defined, well-understood service schema that doesn't have more than a dozen elements. I continue to assert that the basic intent of the inquiry should be the predominating factor in enumservice selection, e.g.: - I want to talk to the entity behind this E.164 number - I want to deposit a message for the entity behind this E.164 number - I want to enter a chat session with the entity behind this E.164 number - I want to use a share a collaborative application with the entity behind this E.164 number - I want to go to the web site for the entity behind this E.164 number - I want to see my options for communication with the entity behind this E.164 number - I want to validate the identity of the entity behind this E.164 number and eventually a wildly successful deployment might lead to: - I want to post a micropayment to the entity behind this E.164 number - I want to post an invoice to the entity behind this E.164 number - I want to get location information for the entity behind this E.164 number (as a PSAP, for instance) and even more interesting concepts where the intent is very different than communications and the transactions happen elsewhere but use the E.164 number as a means of identity resolution for entities human and machine, organized and grouped under a single entity like a corporation or government or just individual devices or an individual role for a single person. The point is that E.164 numbers are used for all of these purposes today but require active human participation to complete these transactions, so these scenarios aren't as far fetched so long as identity and policy systems are available to the participating entities. Anyway, the point here is a simple request to stick to the definition of vertical that we started with -or- draw a different matrix and call the resulting scheme 'vertical scheme from matrix2' or something that clearly distinguishes it from the original vertical. --Andy _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri May 31 15:28:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28958 for ; Fri, 31 May 2002 15:28:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29008 for enum-archive@odin.ietf.org; Fri, 31 May 2002 15:29:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28730; Fri, 31 May 2002 15:20:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28699 for ; Fri, 31 May 2002 15:20:29 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28101 for ; Fri, 31 May 2002 15:20:01 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24761 for ; Fri, 31 May 2002 15:18:44 -0400 (EDT) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24754 for ; Fri, 31 May 2002 15:18:44 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: Don't use spam blocker addresses on mail lists, please (was RE: [Enum] The Matrix (verification)) Date: Fri, 31 May 2002 13:21:16 -0600 Message-ID: Thread-Topic: RE: [Enum] The Matrix (verification) Thread-Index: AcII09YQivpF0S+dSXuHW2CzxdzgxAAAssyg From: "Zmolek, Andrew (Andrew)" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA28700 Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 8bit I don't know who Brian Cartmell is, but his email apparently uses a "revolutionary and unobtrusive technology that stops spam before it reaches the inbox" that appears to be pretty good at stopping email too, as clicking on the service provider's link only gets me the following: 500 Servlet Exception Note: sun.tools.javac.Main has been deprecated. /home/sa/sa/WEB-INF/classes/spamarrest/build/MergeConfigAntTask.java:4: Package org.apache.tools.ant not found in import. import org.apache.tools.ant.*; ^ /home/sa/sa/WEB-INF/classes/spamarrest/build/MergeConfigAntTask.java:9: Superclass spamarrest.build.Task of class spamarrest.build.MergeConfigAntTask not found. public class MergeConfigAntTask extends Task { ^ 2 errors, 1 warning -------------------------------------------------------------------------------- Resin 2.1.0 (built Tue Mar 26 14:12:50 PST 2002) So Brian and anyone else foolish enough to believe this vendor's pitch, please don't subscribe to mailing lists behind these spam-prevention services. This is the last list submission I'll "click to verify" and I don't want to see this get so out-of-hand that every poster will be treated to hundreds of these 'unobtrusive' requests for verification for the privilege of participation. --Andy -----Original Message----- From: Brian Cartmell [mailto:brian@cartmell.cc] Sent: Friday, May 31, 2002 12:46 PM To: Zmolek, Andrew (Andrew) Subject: RE: RE: [Enum] The Matrix (verification) Brian Cartmell would like to receive your email "RE: [Enum] The Matrix". brian@cartmell.cc is now using Spamarrest to block unwanted email. Spamarrest is a revolutionary and unobtrusive technology that stops spam before it reaches the inbox. Please click the link to complete transit of your email and all future messages to Brian Cartmell http://spamarrest.com/a?3820200:68006 Thank you. Spamarrest.com - Try it free for 30 days! http://spamarrest.com _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Fri May 31 19:07:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06508 for ; Fri, 31 May 2002 19:07:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA11332 for enum-archive@odin.ietf.org; Fri, 31 May 2002 19:08:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10341; Fri, 31 May 2002 18:52:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10281 for ; Fri, 31 May 2002 18:52:45 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06286; Fri, 31 May 2002 18:52:18 -0400 (EDT) Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4VMpFuF005821; Fri, 31 May 2002 15:51:15 -0700 (PDT) Received: from DWINGW2K4 (dhcp-128-107-139-55.cisco.com [128.107.139.55]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AFA79331; Fri, 31 May 2002 15:52:13 -0700 (PDT) From: "Dan Wing" To: "Zmolek, Andrew \(Andrew\)" , Cc: "Brian Cartmell" , Subject: RE: Don't use spam blocker addresses on mail lists, please (was RE: [Enum] The Matrix (verification)) Date: Fri, 31 May 2002 15:51:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal Content-Transfer-Encoding: 7bit Sender: enum-admin@ietf.org Errors-To: enum-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Enum Discussion List X-BeenThere: enum@ietf.org Content-Transfer-Encoding: 7bit I have set his address to NOMAIL until this is resolved. -Dan Wing, dwing@cisco.com co-admin, enum mailing list > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Zmolek, Andrew (Andrew) > Sent: Friday, May 31, 2002 12:21 PM > To: enum@ietf.org > Subject: Don't use spam blocker addresses on mail lists, please (was RE: > [Enum] The Matrix (verification)) > > > I don't know who Brian Cartmell is, but his email > apparently uses a "revolutionary and unobtrusive technology that > stops spam before it reaches the inbox" that appears to be pretty > good at stopping email too, as clicking on the service provider's > link only gets me the following: > > 500 Servlet Exception > Note: sun.tools.javac.Main has been deprecated. > /home/sa/sa/WEB-INF/classes/spamarrest/build/MergeConfigAntTask.java:4: > Package org.apache.tools.ant not found in import. > import org.apache.tools.ant.*; > ^ > /home/sa/sa/WEB-INF/classes/spamarrest/build/MergeConfigAntTask.java:9: > Superclass spamarrest.build.Task of class > spamarrest.build.MergeConfigAntTask > not found. > public class MergeConfigAntTask extends Task { > ^ > 2 errors, 1 warning > > > ---------------------------------------------------------------------- > ---------- > Resin 2.1.0 (built Tue Mar 26 14:12:50 PST 2002) > > > So Brian and anyone else foolish enough to believe this vendor's > pitch, please don't subscribe to mailing lists behind these > spam-prevention services. This is the last list submission I'll > "click to verify" and I don't want to see this get so out-of-hand > that every poster will be treated to hundreds of these 'unobtrusive' > requests for verification for the privilege of participation. > > --Andy > > > -----Original Message----- > From: Brian Cartmell [mailto:brian@cartmell.cc] > Sent: Friday, May 31, 2002 12:46 PM > To: Zmolek, Andrew (Andrew) > Subject: RE: RE: [Enum] The Matrix (verification) > > > Brian Cartmell would like to receive your email > "RE: [Enum] The Matrix". > > brian@cartmell.cc is now using Spamarrest to block unwanted email. > Spamarrest is a revolutionary and unobtrusive technology that > stops spam before it reaches the inbox. > > Please click the link to complete transit of your email > and all future messages to Brian Cartmell > > http://spamarrest.com/a?3820200:68006 > > Thank you. > > > > Spamarrest.com - Try it free for 30 days! > http://spamarrest.com > > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www1.ietf.org/mailman/listinfo/enum _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum