From daemon@optimus.ietf.org Mon Jul 1 09: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 JAA06221 for ; Mon, 1 Jul 2002 09:58:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA29597 for enum-archive@odin.ietf.org; Mon, 1 Jul 2002 09:59: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 JAA28049; Mon, 1 Jul 2002 09:49: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 JAA27998 for ; Mon, 1 Jul 2002 09:49:44 -0400 (EDT) Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05390 for ; Mon, 1 Jul 2002 09:48:55 -0400 (EDT) Received: from RWALTER ([65.203.166.26]) by hvmta02-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020701134933.NMZQ1878.hvmta02-stg.us.psimail.psi.net@RWALTER>; Mon, 1 Jul 2002 09:49:33 -0400 Reply-To: From: "Robert H. Walter" To: "Brandner Rudolf" Cc: Subject: RE: [Enum] enumservices in new version of 2916bis Date: Mon, 1 Jul 2002 09:49:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: 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 Rudolf, The [] around the enumservice production are unnecessary since *() already specifies that there are to be zero or more. Using formal ABNF, I'm assuming that you actually mean the following: servicefield = "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] Can you provide the complete ABNF defining the uri-scheme, enumservice and addinfo productions? In particular what is addinfo and how is it to be used? Thank you, Bob Walter NetNumber, Inc. > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Brandner Rudolf > Sent: Friday, June 28, 2002 10:19 PM > To: 'Michael Mealling'; CONROY LAWRENCE > Cc: enum@ietf.org; richard.stastny@oefeg.at > Subject: AW: [Enum] enumservices in new version of 2916bis > > > Hi all, > > I'd like to come back to the very pressing issue: enumservice field > structure. I'm with Richard Stastny on this: we really need to sort this > out. Thus I'd like to ask whether we do have a (rough) consensus on > servicefield = "E2U" ("-" ) [*("+" > )] ["*" ] > or not. > > [note: I think I've got the addinfo right now. If not, please let me know.] > > And yes, I agree that we will have to be very clear about addinfo being optional. > > Now on to the thread of protocols and APIs: > > > -----Ursprüngliche Nachricht----- > > Von: Michael Mealling [mailto:michael@neonym.net] > > Gesendet: Freitag, 28. Juni 2002 23:01 > > An: Lawrence Conroy > > Cc: enum@ietf.org; Michael Mealling; richard.stastny@oefeg.at > > Betreff: Re: [Enum] enumservices in new version of 2916bis > > > > > > On Fri, Jun 28, 2002 at 09:21:47PM +0100, Lawrence Conroy wrote: > > > At 3:05 pm -0400 28/6/02, Robert H. Walter wrote: > > > > > Umm.... I'm not sure in what context you're using the > > string 'mailto' > > > >> here but just in case: > > > >> > > > >> mailto is a URI scheme defined in RFC 2368 which only > > mentioned SMTP > > > >> _once_ > > > >> in a caveat about making sure the SMTP 'From' address is set > > > >>correctly in the > > > >> message. RFC 2368 does not define any transport system > > to be used. > > > >> Period. > > > >> 'mailto:' identifies RFC 822 addresses and messages. How > > you get to an > > > >> address or send a message is not defined. > > > >> > > > >> Everyone: Please be _very_ careful how you use > > 'mailto:'. It _does NOT_ > > > >> mean what you think it means simply from your usage on a > > web page. Please > > > >> read RFC 2368 and RFC 2396 if this is confusing.... > > > > > > > >Agreed, the uri-scheme and protocol are different things > > and should not > > > >be used interchangeably... > > > > > > To which I reply: > > > Amen to that. > > > > > > (In answer to Michael's question regarding implementing URL > > handlers > > > ...me too !) > > > I guess that the problem is that I'd rather like to have something > > > implemented by the end of the summer that doesn't just have > > SRS as the > > > service and sip: as the URL. > > > > Can you describe that something? > > > > Hmmm, I'm not sure, whether this discussion is helpful on our main issue: > enumservice field structure. > > > > > I believe that I and everyone else here understands the > > difference between > > > the architecture and the implementation - at least the old > > fogeys around here > > > [and I still have hopes for Xanadu]. > > > > > > We seem to be getting to the nub here - how an end user gets to the > > > resource with which they want to communicate is not > > specified in the URL. > > > > Correct. It just specifies what that resource is. We still need a way > > to specify what method is used to talk to it. > > > > Sorry, but I think no, we don't as far as protocols are concerned. > > Today, I can send an SMS to an e-mail address. My mobile phone might not > get a very popular e-mail client any time soon, but it might get > ENUM-enabled. If my mobile phone gets a mailto: it might fire up the SMS UI > to enter the message, prepends the e-mail address and sends it to a gateway > of choice, which forwards it as an e-mail to the reciepient. > > If you are going to specify protocols here you are opening a whole new can > of worms. The only thing I need to know is how the receiving end can be > reached. How the communication is started with is a complete different > story. For instance, if you are specifying SMTP as the protocol of choice, > I won't be able to send a message to an e-mail address from my mobile phone > any more until it get's STMP or at least an e-mail client. > > > > At what point did instructing the querying end user/client exactly > > > how to connect to their intended correspondent become a > > core part of ENUM? > > > > When it became clear that simply identifying the endpoint > > wasn't sufficient > > for knowing how to interact with that resource since the > > protocol you use > > to do has a large amount of impact on what services you can > > express for > > that endpoint. > > > > Define a default behaviour of the client for a default protocol. However, > the protocol used at the recieving side does not necessarily be the same as > on the sender side. ENUM is about how a recieving side can be contacted. > > > > > In answer to the "what will it break"? question, my answer is > > > "nothing, if ignored". > > > > Depending on your implementation schedule and feature list that might > > be sufficient for now. I assume you'll be coming out with updates? > > > > You're not? (sorry, couldn't resist ;^) > > > > Those fine OS manufacturers have provided an easy API to > > fire up a URL > > > handler for "mailto:". > > > > Sure. But on a very popular OS platform all that does is bring up the > > Outlook with a few header fields filled in. You can't really > > use that as > > a voice mail interface. I.e. if the _service_ you want is voice mail > > then bringing up Outlook is probably _not_ what you wanted to happen, > > regardless of whether or not there's a built in handler for > > the 'mailto' > > scheme on that platform. > > > > As for that very popular OS platform: is it ENUM enabled? > > If you are looking for a vmail service and start an application which is > not capable of dealing with voice.... er... what's wrong here? > > Maybe there need to be some application to glue together. In this > particular case, looking for a vmail it might be of help first start some > voice recording software and then send it using that very popular mailer > until that very popular software company gets its very popular mailer ENUM-enabled. > > > > I also have an easy API to fire up a URL handler for "tel:" > > > (strictly, this one's via TAPI), and for "http:", and > > (shortly) for "sip:". > > > > Sure. But do those APIs know what it is you're trying to _do_ with > > those endpoints? > > > > Maybe I am off some miles here, but I think that the APIs do not need to > know. An ENUM client software should know about the features ENUM enables > and start the appropriate pieces of software already being there. > > > > > The querying end user (or the defaults of a certain Redmond company) > > > configure what protocols and programs these URLs trigger. > > > No great pain, and we'll get something out soon. > > > > The Asynchronous Pluggable Protocol (bad terminology!) APIs found in > > urlmon and friends are great. But they're only half of the > > story. Before > > your call ever goes the actual scheme handler it goes through a > > security and caching policy filter that can determine whether or not > > your 'ftp:' URL request actually gets sent to your proxy via the HTTP > > protocol. If you're client has this specified then your 'sip:' > > url is going to get sent to the the 'http:' handler as a > > proxy proccess. > > So it isn't as clear cut as "Microsoft just gives me nifty > > APIs and that's > > all I need". There are nasy side effects when you use it if you aren't > > clear why your using it. > > > > Is Microsoft's software ENUM enabled already? If not, maybe they just up > the ante in changing APIs and their semantics a little bit....... > > Sorry for being somehow sarcastic here. I see that there are problems with > actual APIs. However, I do not see any immediate link to the enumservice > field. The trials will show how easy or complicated it is to implement > useful ENUM clients. APIs might change after getting some experice. > > > > If ENUM implementors are expected to find a way to override these > > > configurations and control the programs to run whatever > > protocol the > > > registrant specifies, we might have the trials sometime before the > > > end of 2003. > > > > I'm not so sure. I think we're actually converging very quickly. > > We've only been having this particular discussion for 2 days. A couple > > of more and I think we'll have it... > > > > > My gripe is that, until this week's wheeze, there was none > > of this - it's > > > all new. New and "by September 2002" don't mix. > > > > Well, its a discussion that's been going on in fits and starts since > > Minneapolis. IMHO, we'll get there soon. I'll do my best to get this > > settled by Yokohama... > > > > I'm with you here. > > .... and if not, I suggest that we discuss this in Yokohama over a beer or two..... > > > Rudi > ------[snipp]----- > > _______________________________________________ > 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 Mon Jul 1 10:37: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 KAA09435 for ; Mon, 1 Jul 2002 10:37:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04707 for enum-archive@odin.ietf.org; Mon, 1 Jul 2002 10:38: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 KAA03479; Mon, 1 Jul 2002 10:29: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 KAA03447 for ; Mon, 1 Jul 2002 10:29:39 -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 KAA08877 for ; Mon, 1 Jul 2002 10:28:50 -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.0000090740 for ; Mon, 01 Jul 2002 15:29:53 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Mon, 1 Jul 2002 15:28:59 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: ENUM Broken? 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, Just when you thought it was safe to come out onto the streets! To summarise the "URI is insufficient without protocol" view: At 1:09 pm -0400 28/6/02, Michael Mealling wrote (in response to Richard's statement here): > > But I definetly see nor reason to add a protocol information. > >You need it because URI does _not_ equate with how you are expected >to access it that particular endpoint. You can use _any_ URI scheme >within the HTTP protocol. 'urn', 'mailto', 'data', 'news', etc are >all examples of URIs that do not and never will define a protocl by which >you access the resource identified by that URI. ...and... At 5:01 pm -0400 28/6/02, Michael Mealling wrote (In response to my statement here): > > At what point did instructing the querying end user/client exactly >> how to connect to their intended correspondent become a core part of ENUM? > >When it became clear that simply identifying the endpoint wasn't sufficient >for knowing how to interact with that resource since the protocol you use >to do has a large amount of impact on what services you can express for >that endpoint. To summarise the "it just works" view: At 9:52 pm +0200 28/6/02, Stastny Richard wrote: >Richard Stastny replies: Ok. I have learned a lot today. For years >there were given examples on how to use ENUM, especially mailto+E2U >and E2U+mailto. Every dummy out there, including myself and ITU-T >SG2 thought you can send an e-mail with this. > >Today I have heard, we all are stupid, mailto does not mean what >everbody think it means and you need to add a protocol information >to get this working. As a dummy MS operating system user you may >click on mailto: link, MS Outlook starts, you write an e-mail and it >is also received by the recipient, but this is just pure luck. > >I have also learned today, that a couple of very sophisticated and >wise guys have defined an RFC2916 and even a 2919bis, which has been >discussed for 2 years in all necessary and unnecessary standard >bodies, but which cannot implemented at least in is simplest >version, because at the moment not even ONE bl... ENUM service is >defined. > >I have also learned (not only today, but since some months), that >what is proposed does not work, why it does not work, Nah, you >cannot do this and you cannot do that, it should be done in another >way, etc. > >Can anybody who defined ENUM please explain to me what I shall use in a trial. > >What I want is at least a simple basic workable solution, for mail, >tel, fax, sms and http: and I want this after Yokohama. ...and... At 9:06 am +0200 29/6/02, Stastny Richard wrote: >Maybe we have a serious misunderstanding of the useability of ENUM >here, but if am am wrong, I mayself and also a lot of other people >in ITU-T, ETSI and other bodies have wasted a lot of their time with >a badly designed or explained system from the IETF. I suspect that a major issue has appeared. OK - it seems that RFC2916 is being updated not only to formalise the processing rules. (At least) half of the authorship of the proposed rfc2916bis update have stated that RFC2916 is incorrect - one needs a ->protocol<- rather than just a URI-scheme. I just want something to implement, after a couple of years of discussion. Question:: GIVEN that in the following statement, "service" is meant in the sense of an entry in the UN*X /etc/services file (i.e. NOT a teleservice, as the term has been used on this list): "If 'protocol supported by destination end point' is REQUIRED, then why not use an SRV record, as this is designed to hold the protocol and service supported"? I would suggest that this is -not- the ENUM 'E2U' D3S application. Instead, this is a different D3S Application, 'E2S', that generates a SRV record reference (and in this case the terminal NAPTR will hold an "s" flag field). OK - this is an idea. What d'you 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 Mon Jul 1 15:00: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 PAA26336 for ; Mon, 1 Jul 2002 15:00:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA01741 for enum-archive@odin.ietf.org; Mon, 1 Jul 2002 15:01: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 OAA00198; Mon, 1 Jul 2002 14:51: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 OAA00163 for ; Mon, 1 Jul 2002 14:51:48 -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 OAA25638 for ; Mon, 1 Jul 2002 14:50:58 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id UAA14116; Mon, 1 Jul 2002 20:51:28 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id UAA18610; Mon, 1 Jul 2002 20:51:42 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 20:51:11 +0200 Message-ID: From: Brandner Rudolf To: "'rwalter@netnumber.com'" , Brandner Rudolf Cc: enum@ietf.org Subject: AW: [Enum] enumservices in new version of 2916bis Date: Mon, 1 Jul 2002 20:51:07 +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 OAA00167 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 Bob, first I'd like to cite Lawrence Conroy: > Von: Lawrence Conroy [mailto:lwc@roke.co.uk] > Gesendet: Freitag, 28. Juni 2002 13:15 > An: enum@ietf.org > Betreff: Re: [ENUM] service field in rfc2916bis > > > Hi Folks, > In answer to Rich's question - "are we close"? I think so, but > using the earlier BNF roughtly like this: > servicefield = "E2U" ("-" ) [*("+" )] > is a URI scheme label registered in an RFC > as defined > according to RFC2717 section 4. > In the case of a non-terminal NAPTR only, > is empty. > is an enumservice label registered in an RFC as > defined according to 2916 section 3. > Note that in this BNF the URI-scheme is a separate sub-field. Following might serve as an example: servicefield : "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] uri-scheme : "tel" | "mailto" | "sip" | "ldap" | ...more according to category-ID... enumservice : "voice" | "video" | "email" | "sms" | "mms" | "talk" | "msg" | ....more according to category-ID.... addinfo : "home" | "business" | "mobile" | other other : The addinfo is just additional information and is thought to be passed to a user (if there) as a FYI. BTW: I'd like to note, that we are thinking about x- experimenatal enumservice and know that there is resistance against this in some places. Hope this answeres your questions. Rudi > -----Ursprüngliche Nachricht----- > Von: Robert H. Walter [mailto:rwalter@netnumber.com] > Gesendet: Montag, 1. Juli 2002 15:50 > An: Brandner Rudolf > Cc: enum@ietf.org > Betreff: RE: [Enum] enumservices in new version of 2916bis > > > Rudolf, > > The [] around the enumservice production are unnecessary since *() > already specifies that there are to be zero or more. Using formal > ABNF, I'm assuming that you actually mean the following: > > servicefield = "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] > > Can you provide the complete ABNF defining the uri-scheme, enumservice > and addinfo productions? In particular what is addinfo and how is it > to be used? > > Thank you, > > Bob Walter > NetNumber, Inc. > > > -----Original Message----- -----[snipp]----- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jul 1 15:14: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 PAA27332 for ; Mon, 1 Jul 2002 15:14:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03190 for enum-archive@odin.ietf.org; Mon, 1 Jul 2002 15:15: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 PAA02167; Mon, 1 Jul 2002 15:05: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 PAA02142 for ; Mon, 1 Jul 2002 15:05:32 -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 PAA26647 for ; Mon, 1 Jul 2002 15:04:41 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id VAA14216 for ; Mon, 1 Jul 2002 21:05:11 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id VAA19520 for ; Mon, 1 Jul 2002 21:05:26 +0200 (MET DST) Received: by MCHH247E with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Jul 2002 21:04:53 +0200 Message-ID: From: Brandner Rudolf To: CONROY LAWRENCE Cc: enum@ietf.org Subject: AW: [Enum] Re: ENUM Broken? Date: Mon, 1 Jul 2002 21:04:51 +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 PAA02143 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, this might be of help: If a system (end-system or intermediate gateway) detects that it can communicate with the destination (directly and according to the URI), it could do an E2S lookup for selecting the right protocol. Yet another step, but still ..... In addition, the E2S might prove very helpful, if a protocol might be updated. For instance, one bright person invents THE killer protocol for e-mail: cmtp (complex mail transfer protocol). Then the E2S can help to find out whether to use the (then) old style smtp or the new cmtp. Rudi > -----Ursprüngliche Nachricht----- > Von: Lawrence Conroy [mailto:lwc@roke.co.uk] > Gesendet: Montag, 1. Juli 2002 16:29 > An: enum@ietf.org > Betreff: [Enum] Re: ENUM Broken? > > > Hi Folks, > Just when you thought it was safe to come out onto the streets! > > To summarise the "URI is insufficient without protocol" view: > At 1:09 pm -0400 28/6/02, Michael Mealling wrote (in response to > Richard's statement here): > > > But I definetly see nor reason to add a protocol information. > > > >You need it because URI does _not_ equate with how you are expected > >to access it that particular endpoint. You can use _any_ URI scheme > >within the HTTP protocol. 'urn', 'mailto', 'data', 'news', etc are > >all examples of URIs that do not and never will define a > protocl by which > >you access the resource identified by that URI. > ...and... > At 5:01 pm -0400 28/6/02, Michael Mealling wrote (In response to my > statement here): > > > At what point did instructing the querying end > user/client exactly > >> how to connect to their intended correspondent become a > core part of ENUM? > > > >When it became clear that simply identifying the endpoint > wasn't sufficient > >for knowing how to interact with that resource since the > protocol you use > >to do has a large amount of impact on what services you can > express for > >that endpoint. > > To summarise the "it just works" view: > > At 9:52 pm +0200 28/6/02, Stastny Richard wrote: > >Richard Stastny replies: Ok. I have learned a lot today. For years > >there were given examples on how to use ENUM, especially mailto+E2U > >and E2U+mailto. Every dummy out there, including myself and ITU-T > >SG2 thought you can send an e-mail with this. > > > >Today I have heard, we all are stupid, mailto does not mean what > >everbody think it means and you need to add a protocol information > >to get this working. As a dummy MS operating system user you may > >click on mailto: link, MS Outlook starts, you write an e-mail and it > >is also received by the recipient, but this is just pure luck. > > > >I have also learned today, that a couple of very sophisticated and > >wise guys have defined an RFC2916 and even a 2919bis, which has been > >discussed for 2 years in all necessary and unnecessary standard > >bodies, but which cannot implemented at least in is simplest > >version, because at the moment not even ONE bl... ENUM service is > >defined. > > > >I have also learned (not only today, but since some months), that > >what is proposed does not work, why it does not work, Nah, you > >cannot do this and you cannot do that, it should be done in another > >way, etc. > > > >Can anybody who defined ENUM please explain to me what I > shall use in a trial. > > > >What I want is at least a simple basic workable solution, for mail, > >tel, fax, sms and http: and I want this after Yokohama. > ...and... > At 9:06 am +0200 29/6/02, Stastny Richard wrote: > >Maybe we have a serious misunderstanding of the useability of ENUM > >here, but if am am wrong, I mayself and also a lot of other people > >in ITU-T, ETSI and other bodies have wasted a lot of their time with > >a badly designed or explained system from the IETF. > > I suspect that a major issue has appeared. > > OK - it seems that RFC2916 is being updated not only to formalise the > processing rules. > > (At least) half of the authorship of the proposed rfc2916bis update > have stated that > RFC2916 is incorrect - one needs a ->protocol<- rather than > just a URI-scheme. > > I just want something to implement, after a couple of years > of discussion. > > Question:: > GIVEN that in the following statement, "service" is meant in the > sense of an entry in the UN*X /etc/services file (i.e. NOT a > teleservice, as the term has been used on this list): > "If 'protocol supported by destination end point' is REQUIRED, then > why not use > an SRV record, as this is designed to hold the protocol > and service > supported"? > > I would suggest that this is -not- the ENUM 'E2U' D3S application. > Instead, this is a different D3S Application, 'E2S', that generates a > SRV record reference (and in this case the terminal NAPTR will hold > an "s" flag field). > > OK - this is an idea. What d'you 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 > _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Jul 2 08:21: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 IAA05550 for ; Tue, 2 Jul 2002 08:21:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06684 for enum-archive@odin.ietf.org; Tue, 2 Jul 2002 08:22: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 IAA06325; Tue, 2 Jul 2002 08:10: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 IAA06294 for ; Tue, 2 Jul 2002 08:10:42 -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 IAA05012 for ; Tue, 2 Jul 2002 08:09:52 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g62C93hW013008; Tue, 2 Jul 2002 14:09:14 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 2 Jul 2002 13:09:48 +0100 Received: from host-n12-37.homerun.telia.com ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 2 Jul 2002 14:09:47 +0200 Date: Tue, 02 Jul 2002 14:08:58 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: rwalter@netnumber.com, Brandner Rudolf cc: enum@ietf.org Subject: RE: [Enum] enumservices in new version of 2916bis Message-ID: <28296772.1025618938@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: 02 Jul 2002 12:09:47.0887 (UTC) FILETIME=[5C304FF0:01C221C1] 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-07-01 09.49 -0400 "Robert H. Walter" wrote: > The [] around the enumservice production are unnecessary since *() > already specifies that there are to be zero or more. Using formal > ABNF, I'm assuming that you actually mean the following: > > servicefield = "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] > > Can you provide the complete ABNF defining the uri-scheme, enumservice > and addinfo productions? In particular what is addinfo and how is it > to be used? This is what I wrote in the new draft which you might have seen by now. I.e. I am not claiming what I wrote is what we finally should use, but, this is what I wrote in what we will discuss in Yokohama: service_field = "E2U" 1*(enumservice) enumservice = service [":" protocol] service = 1*32(ALPHA / DIGIT) protocol = 1*32(ALPHA / DIGIT) paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Jul 2 09:04: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 JAA07303 for ; Tue, 2 Jul 2002 09:04:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09527 for enum-archive@odin.ietf.org; Tue, 2 Jul 2002 09:05: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 IAA08382; Tue, 2 Jul 2002 08:54: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 IAA08351 for ; Tue, 2 Jul 2002 08:54:15 -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 IAA06783 for ; Tue, 2 Jul 2002 08:53:24 -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.0000090770; Tue, 02 Jul 2002 13:54:35 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <28296772.1025618938@localhost> References: <28296772.1025618938@localhost> Date: Tue, 2 Jul 2002 13:53:40 +0100 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , rwalter@netnumber.com, Brandner Rudolf From: Lawrence Conroy Subject: RE: [Enum] enumservices in new version of 2916bis 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 IAA08352 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 2:08 pm +0200 2/7/02, Patrik Fältström wrote: >--On 2002-07-01 09.49 -0400 "Robert H. Walter" >wrote: > >> The [] around the enumservice production are unnecessary since *() >> already specifies that there are to be zero or more. Using formal >> ABNF, I'm assuming that you actually mean the following: >> >> servicefield = "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] >> >> Can you provide the complete ABNF defining the uri-scheme, enumservice >> and addinfo productions? In particular what is addinfo and how is it >> to be used? > >This is what I wrote in the new draft which you might have seen by now. > >I.e. I am not claiming what I wrote is what we finally should use, but, >this is what I wrote in what we will discuss in Yokohama: > > service_field = "E2U" 1*(enumservice) > enumservice = service [":" protocol] > service = 1*32(ALPHA / DIGIT) > protocol = 1*32(ALPHA / DIGIT) > > paf > Hi Folks, obviously we have a meeting of minds. Two questions:: Is there intended to be a white space or some punctuation between the "E2U" and the start of the enumservice list? Is there intended to be white space around the enumservice elements, or is it intended as a comma-separated list, or do we just run them together? I repeat my comment that I do not think that a protocol or protocol set is needed to return a URI, nor to select between a group of URLs, each held in a separate NAPTR. For this a service or set of services is needed to show the user intent; how that intent is executed is a combination of the end user system policy and the URL field. 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 Jul 2 10:19: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 KAA11425 for ; Tue, 2 Jul 2002 10:19:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA22833 for enum-archive@odin.ietf.org; Tue, 2 Jul 2002 10:19: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 KAA21921; Tue, 2 Jul 2002 10:07: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 KAA21890 for ; Tue, 2 Jul 2002 10:07:04 -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 KAA10460 for ; Tue, 2 Jul 2002 10:06:17 -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 g62E5Jfa001361; Tue, 2 Jul 2002 10:05:19 -0400 (EDT) Received: (from michael@localhost) by bailey.dscga.com (8.12.1/8.12.1/Submit) id g62E5I1s001360; Tue, 2 Jul 2002 10:05:18 -0400 (EDT) Date: Tue, 2 Jul 2002 10:05:18 -0400 From: Michael Mealling To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: rwalter@netnumber.com, Brandner Rudolf , enum@ietf.org Subject: Re: [Enum] enumservices in new version of 2916bis Message-ID: <20020702100518.A1040@bailey.dscga.com> Reply-To: Michael Mealling References: <28296772.1025618938@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <28296772.1025618938@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 Tue, Jul 02, 2002 at 02:08:58PM +0200, Patrik Fältström wrote: > --On 2002-07-01 09.49 -0400 "Robert H. Walter" > wrote: > > The [] around the enumservice production are unnecessary since *() > > already specifies that there are to be zero or more. Using formal > > ABNF, I'm assuming that you actually mean the following: > > > > servicefield = "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] > > > > Can you provide the complete ABNF defining the uri-scheme, enumservice > > and addinfo productions? In particular what is addinfo and how is it > > to be used? > > This is what I wrote in the new draft which you might have seen by now. > > I.e. I am not claiming what I wrote is what we finally should use, but, > this is what I wrote in what we will discuss in Yokohama: > > service_field = "E2U" 1*(enumservice) > enumservice = service [":" protocol] > service = 1*32(ALPHA / DIGIT) > protocol = 1*32(ALPHA / DIGIT) Which also includes the fact that both 'service' and 'protocol' are IANA registered items that point to documentation about what they mean, right? So the 'protocol' registration can specify a) what transport protocol you're talking about and b) what URI schemes are valid for it. Thus, the 'sip' protocol can say that only 'sip:' URI schems are valid for it. -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 Tue Jul 2 10:36: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 KAA12516 for ; Tue, 2 Jul 2002 10:36:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA24876 for enum-archive@odin.ietf.org; Tue, 2 Jul 2002 10:37: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 KAA23508; Tue, 2 Jul 2002 10:26: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 KAA23461 for ; Tue, 2 Jul 2002 10:26:04 -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 KAA11830 for ; Tue, 2 Jul 2002 10:25:17 -0400 (EDT) Received: from user-2ivelth.dialup.mindspring.com ([165.247.87.177] helo=dick.ix.netcom.com) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17PObT-0000m7-00 for enum@ietf.org; Tue, 02 Jul 2002 10:26:04 -0400 Message-Id: <5.1.0.14.2.20020701181308.01f9a338@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 02 Jul 2002 10:31:59 -0400 To: enum@ietf.org From: Richard Shockey 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 KAA23462 Subject: [Enum] Proposed Agenda for ENUM WG in Yokohama 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 got some private notes requesting some time but I'd like to put a straw man out there for consideration. BTW any volunteers for scribe? Jay are you coming? MONDAY, July 15, 2002 0800-1930 IETF Registration - 1130-1300 Break 1300-1500 Afternoon Sessions I TSV enum Telephone Number Mapping WG Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction … ?????? RFC2916bis -01 REV - Faltstrom/Mealing (45 Min) The goal here should be to give the document authors definitive direction on the draft so that it can begin to move forward with all deliberate speed. The 01 revision is in the hopper so we should see it shortly. The ENUMSERVICE's documents 45 Min [Stastny/Conroy/Brandner] It should be clear from the list that these documents have generated the most discussion and I want the meeting in Yokohama to come to some reasonable consensus on the next steps for these documents. I think there we are close to agreement on several points but we have several proposals on what is the proper ABNF syntax to use and the exact terms and definitions to be used in describing the data elements. For instance it is still disagreement on URI scheme vs a more expanded 'protocol' element for the mandatory portion of the enumservice field. Presenters should be prepared to precisely define their proposals and the rationale for them. What I would still like to happen is that portions of these drafts could be combined with previous work from Doug Ranalli and Bob Walter into a new ID that we could track to Experimental status that implementers could begin to use for testing purposes. This would define a very limited matrix of options along the lines suggested by both Walter and S/C/B and could move in parallel with 2916bis to provide guidance to some of our colleagues in SG2 etc. (WHO WANTS TO PRESENT THESE - I know Richard will still have jet lag Monday. http://www.ietf.org/internet-drafts/draft-stastny-enum-services-analysis-00.txt Categorical enumservices http://www.ietf.org/internet-drafts/draft-brandner-enum-categorical-enumservices-00.txt Scenarios for ENUM and ENUM-like Systems http://www.ietf.org/internet-drafts/draft-stastny-enum-scenarios-00.txt ################ The 'enum' URI 15-20 M RUDOLF IS THIS OK ? http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt and if there is any time left The tel URI... LARRY ??? http://www.ietf.org/internet-drafts/draft-brandner-tel-svc-00.txt Comments ? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Jul 3 04:12: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 EAA01417 for ; Wed, 3 Jul 2002 04:12:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA19908 for enum-archive@odin.ietf.org; Wed, 3 Jul 2002 04:13: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 EAA19441; Wed, 3 Jul 2002 04:01: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 EAA19410 for ; Wed, 3 Jul 2002 04:01:42 -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 EAA01244 for ; Wed, 3 Jul 2002 04:00:52 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6380EFQ001190; Wed, 3 Jul 2002 10:00:16 +0200 (MET DST) Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 3 Jul 2002 08:58:54 +0100 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 3 Jul 2002 09:58:53 +0200 Date: Tue, 02 Jul 2002 19:20:04 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Lawrence Conroy , rwalter@netnumber.com, Brandner Rudolf cc: enum@ietf.org Subject: RE: [Enum] enumservices in new version of 2916bis Message-ID: <28600245.1025637604@localhost> In-Reply-To: References: <28296772.1025618938@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: 03 Jul 2002 07:58:53.0726 (UTC) FILETIME=[799F63E0:01C22267] 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-07-02 13.53 +0100 Lawrence Conroy wrote: >> I.e. I am not claiming what I wrote is what we finally should use, but, >> this is what I wrote in what we will discuss in Yokohama: >> >> service_field = "E2U" 1*(enumservice) >> enumservice = service [":" protocol] >> service = 1*32(ALPHA / DIGIT) >> protocol = 1*32(ALPHA / DIGIT) >> > Two questions:: > > Is there intended to be a white space or some punctuation between the > "E2U" and the start of the enumservice list? Mea culpa. Mea maxima culpa. There should be a '+' there. Correct grammar should have been: service_field = "E2U" 1*("+" enumservice) enumservice = service [":" protocol] service = 1*32(ALPHA / DIGIT) protocol = 1*32(ALPHA / DIGIT) paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Jul 3 05:26: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 FAA02386 for ; Wed, 3 Jul 2002 05:26:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA23719 for enum-archive@odin.ietf.org; Wed, 3 Jul 2002 05:26: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 FAA23441; Wed, 3 Jul 2002 05:15: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 FAA23410 for ; Wed, 3 Jul 2002 05:15: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 FAA02212 for ; Wed, 3 Jul 2002 05:15:07 -0400 (EDT) Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g639ES0b014480; Wed, 3 Jul 2002 11:14:34 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 3 Jul 2002 11:15:19 +0200 Received: from [10.0.1.2] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 3 Jul 2002 11:15:18 +0200 Date: Wed, 03 Jul 2002 11:00:24 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Michael Mealling cc: rwalter@netnumber.com, Brandner Rudolf , enum@ietf.org Subject: Re: [Enum] enumservices in new version of 2916bis Message-ID: <29611695.1025694024@localhost> In-Reply-To: <20020702100518.A1040@bailey.dscga.com> References: <28296772.1025618938@localhost> <20020702100518.A1040@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: 03 Jul 2002 09:15:18.0685 (UTC) FILETIME=[26789CD0:01C22272] 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-07-02 10.05 -0400 Michael Mealling wrote: >> service_field = "E2U" 1*(enumservice) >> enumservice = service [":" protocol] >> service = 1*32(ALPHA / DIGIT) >> protocol = 1*32(ALPHA / DIGIT) > > Which also includes the fact that both 'service' and 'protocol' are IANA > registered items that point to documentation about what they mean, right? The _combination_ of service and protocol must be described somewhere. > So the 'protocol' registration can specify a) what transport protocol > you're talking about and b) what URI schemes are valid for it. Thus, > the 'sip' protocol can say that only 'sip:' URI schems are valid for it. I don't care what the 'protocol' specifies. My view (after reading the discussions on this list) is that what it actually specifies differ between different usages. It is a placeholder for a subtype of "service". paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@ns.ietf.org Wed Jul 3 11:39: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 LAA18655 for ; Wed, 3 Jul 2002 11:39:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA18873 for enum-archive@odin.ietf.org; Wed, 3 Jul 2002 11:40: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 KAA16293; Wed, 3 Jul 2002 10:59: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 KAA16262 for ; Wed, 3 Jul 2002 10:59:46 -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 KAA17327 for ; Wed, 3 Jul 2002 10:58:56 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA02927; Wed, 3 Jul 2002 16:59:28 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA20196; Wed, 3 Jul 2002 16:59:43 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Jul 2002 16:59:43 +0200 Message-ID: From: Brandner Rudolf To: "'Richard Shockey'" Cc: enum@ietf.org Subject: AW: [Enum] Proposed Agenda for ENUM WG in Yokohama Date: Wed, 3 Jul 2002 16:59:41 +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 KAA16263 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 Richard, I'll prepare for the ENUM analysis, categorical enumservices, the 'enum' URI and the tel-svc. I'll need about 35 minutes. Richard Stastny indicated that he is going to prepare some slides on the Scenarios http://www.ietf.org/internet-drafts/draft-stastny-enum-scenarios-00.txt Many thanks, Rudi > -----Ursprüngliche Nachricht----- > Von: Richard Shockey [mailto:rshockey@ix.netcom.com] > Gesendet: Dienstag, 2. Juli 2002 16:32 > An: enum@ietf.org > Betreff: [Enum] Proposed Agenda for ENUM WG in Yokohama -----[snipp]----- > (WHO WANTS TO PRESENT THESE - I know Richard will still have > jet lag Monday. > > http://www.ietf.org/internet-drafts/draft-stastny-enum-service s-analysis-00.txt Categorical enumservices http://www.ietf.org/internet-drafts/draft-brandner-enum-categorical-enumservices-00.txt Scenarios for ENUM and ENUM-like Systems http://www.ietf.org/internet-drafts/draft-stastny-enum-scenarios-00.txt ################ The 'enum' URI 15-20 M RUDOLF IS THIS OK ? http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt and if there is any time left The tel URI... LARRY ??? http://www.ietf.org/internet-drafts/draft-brandner-tel-svc-00.txt Comments ? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jul 5 09:58:06 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 JAA25595 for ; Fri, 5 Jul 2002 09:58:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03153 for enum-archive@odin.ietf.org; Fri, 5 Jul 2002 09:58: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 JAA02704; Fri, 5 Jul 2002 09:48:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02673 for ; Fri, 5 Jul 2002 09:48:13 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25095; Fri, 5 Jul 2002 09:47:20 -0400 (EDT) Received: from user-2iveru9.dialup.mindspring.com ([165.247.111.201] helo=dick.ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17QTRR-0005Pt-00; Fri, 05 Jul 2002 09:48:10 -0400 Message-Id: <5.1.0.14.2.20020705094209.01d4b970@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Jul 2002 09:50:23 -0400 To: enum@ietf.org From: Richard Shockey Cc: agenda@ietf.org 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 JAA02674 Subject: [Enum] Final Agenda ENUM WG IETF 54 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 MONDAY, July 15, 2002 0800-1930 IETF Registration - 1130-1300 Break 1300-1500 Afternoon Sessions I TSV enum Telephone Number Mapping WG Chair(s): Patrik Faltstrom Richard Shockey Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:enum@ietf.org To Subscribe: enum-request@ietf.org In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/enum/ AGENDA BASHING (5 min) Scribe Introduction … Jay Hilton 1. RFC2916bis -01 REV - Faltstrom/Mealing (45 Min) The goal here should be to give the document authors definitive direction on the draft so that it can begin to move forward with all deliberate speed. The 01 revision is in the hopper so we should see it shortly. ############### 2. The ENUMSERVICE's documents 45 Min [Stastny/Conroy/Brandner] It should be clear from the list that these documents have generated the most discussion and I want the meeting in Yokohama to come to some reasonable consensus on the next steps for these documents. I think there we are close to agreement on several points but we have several proposals on what is the proper ABNF syntax to use and the exact terms and definitions to be used in describing the data elements. For instance it is still disagreement on URI scheme vs a more expanded 'protocol' element for the mandatory portion of the enumservice field. Presenters should be prepared to precisely define their proposals and the rationale for them. Scenarios for ENUM and ENUM-like Systems http://www.ietf.org/internet-drafts/draft-stastny-enum-scenarios-00.txt Analysis of the Usage of ENUM and ENUM Services http://www.ietf.org/internet-drafts/draft-stastny-enum-services-analysis-00.txt Categorical enumservices http://www.ietf.org/internet-drafts/draft-brandner-enum-categorical-enumservices-00.txt ################ 3. The 'enum' URI 10 M http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt OPTIONAL IF there is any time left The tel URI... http://www.ietf.org/internet-drafts/draft-brandner-tel-svc-00.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Jul 5 09:58: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 JAA25603 for ; Fri, 5 Jul 2002 09:58:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA03164 for enum-archive@odin.ietf.org; Fri, 5 Jul 2002 09:58: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 JAA02734; Fri, 5 Jul 2002 09:48: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 JAA02709 for ; Fri, 5 Jul 2002 09:48:17 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25103 for ; Fri, 5 Jul 2002 09:47:25 -0400 (EDT) Received: from user-2iveru9.dialup.mindspring.com ([165.247.111.201] helo=dick.ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17QTRT-0005Pt-00; Fri, 05 Jul 2002 09:48:12 -0400 Message-Id: <5.1.0.14.2.20020705095029.01d528e8@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Jul 2002 09:53:02 -0400 To: Brandner Rudolf From: Richard Shockey Subject: Re: AW: [Enum] Proposed Agenda for ENUM WG in Yokohama Cc: enum@ietf.org In-Reply-To: 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 JAA02710 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 04:59 PM 7/3/2002 +0200, Brandner Rudolf wrote: >Hi Richard, > >I'll prepare for the ENUM analysis, categorical enumservices, the 'enum' >URI and the tel-svc. I'll need about 35 minutes. > >Richard Stastny indicated that he is going to prepare some slides on the >Scenarios >http://www.ietf.org/internet-drafts/draft-stastny-enum-scenarios-00.txt > >Many thanks, >Rudi That's fine ..but lets keep the tel document optional at this point ..we only have 2 hours and I think there is enough to cover at this point. > > -----Ursprüngliche Nachricht----- > > Von: Richard Shockey [mailto:rshockey@ix.netcom.com] > > Gesendet: Dienstag, 2. Juli 2002 16:32 > > An: enum@ietf.org > > Betreff: [Enum] Proposed Agenda for ENUM WG in Yokohama >-----[snipp]----- > > (WHO WANTS TO PRESENT THESE - I know Richard will still have > > jet lag Monday. > > > > http://www.ietf.org/internet-drafts/draft-stastny-enum-service >s-analysis-00.txt > >Categorical enumservices > >http://www.ietf.org/internet-drafts/draft-brandner-enum-categorical-enumservices-00.txt > >Scenarios for ENUM and ENUM-like Systems > >http://www.ietf.org/internet-drafts/draft-stastny-enum-scenarios-00.txt > >################ > >The 'enum' URI 15-20 M RUDOLF IS THIS OK ? > >http://www.ietf.org/internet-drafts/draft-brandner-enum-uri-00.txt > > >and if there is any time left > >The tel URI... LARRY ??? > >http://www.ietf.org/internet-drafts/draft-brandner-tel-svc-00.txt > > >Comments ? > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Jul 5 20:12: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 UAA25786 for ; Fri, 5 Jul 2002 20:12:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA01706 for enum-archive@odin.ietf.org; Fri, 5 Jul 2002 20:13: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 UAA01439; Fri, 5 Jul 2002 20:03: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 OAA18613 for ; Fri, 5 Jul 2002 14:32:26 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09141 for ; Fri, 5 Jul 2002 14:31:35 -0400 (EDT) Received: from user-2ivemvj.dsl.mindspring.com ([165.247.91.243] helo=dick.ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17QXsM-0005bl-00 for enum@ietf.org; Fri, 05 Jul 2002 14:32:15 -0400 Message-Id: <5.1.0.14.2.20020705143339.01e320b8@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 05 Jul 2002 14:38:44 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_91419113==_" Subject: [Enum] The new RFC2916bis 01 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 --=====================_91419113==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Normally I would not do this but the ID mail server is really running slow this time ..in order for you to have a opportunity to read ,review and comment on the latest revision before next week its is attached. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< --=====================_91419113==_ Content-Type: text/plain; name="draft-ietf-enum-rfc2916bis-01.txt"; x-mac-type="42494E41"; x-mac-creator="74747874" Content-Disposition: attachment; filename="draft-ietf-enum-rfc2916bis-01.txt" Content-Transfer-Encoding: base64 CgoKRU5VTSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUC4gRmFsdHN0cm9tCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBDaXNjbyBTeXN0ZW1zIEluYwpFeHBpcmVzOiBOb3ZlbWJlciAzMCwg MjAwMiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gTWVhbGxpbmcKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFZlcmlTaWduCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEp1bmUgMjAwMgoKCiAgICAgICAgICAgICAgICAgICBUaGUgRS4xNjQg dG8gVVJJIERERFMgQXBwbGljYXRpb24KICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtZW51 bS1yZmMyOTE2YmlzLTAxLnR4dAoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBkb2N1bWVu dCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoCiAg IGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAg IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBO b3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJh ZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5 IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0 IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRz IGFzIHJlZmVyZW5jZQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0 cyBjYW4gYmUgYWNjZXNzZWQgYXQgaHR0cDovLwogICB3d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJz dHJhY3RzLnR4dC4KCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3Rv cmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bC4KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTm92ZW1iZXIgMzAsIDIw MDIuCgpDb3B5cmlnaHQgTm90aWNlCgogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2Np ZXR5ICgyMDAyKS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCgpBYnN0cmFjdAoKICAgVGhpcyBkb2N1 bWVudCBkaXNjdXNzZXMgdGhlIHVzZSBvZiB0aGUgRG9tYWluIE5hbWUgU3lzdGVtIChETlMpIGZv cgogICBzdG9yYWdlIG9mIEUuMTY0IG51bWJlcnMuICBNb3JlIHNwZWNpZmljYWxseSwgaG93IERO UyBjYW4gYmUgdXNlZCBmb3IKICAgaWRlbnRpZnlpbmcgYXZhaWxhYmxlIHNlcnZpY2VzIGNvbm5l Y3RlZCB0byBvbmUgRS4xNjQgbnVtYmVyLiAgSXQKICAgc3BlY2lmaWNhbGx5IG9ic29sZXRlcyBS RkMgMjkxNiB0byBicmluZyBpdCBpbiBsaW5lIHdpdGggdGhlIER5bmFtaWMKICAgRGVsZWdhdGlv biBEaXNjb3ZlcnkgU3lzdGVtIChERERTKSBBcHBsaWNhdGlvbiBzcGVjaWZpY2F0aW9uIGZvdW5k IGluCiAgIHRoZSBkb2N1bWVudCBzZXJpZXMgc3BlY2lmaWVkIGluIFJGQyBXV1dXLiAgSXQgaXMg dmVyeSBpbXBvcnRhbnQgdG8KICAgbm90ZSB0aGF0IGl0IGlzIGltcG9zc2libGUgdG8gcmVhZCBh bmQgdW5kZXJzdGFuZCB0aGlzIGRvY3VtZW50CiAgIHdpdGhvdXQgcmVhZGluZyB0aGUgZG9jdW1l bnRzIGRpc2N1c3NlZCBpbiBSRkMgV1dXVy4KCgoKCgpGYWx0c3Ryb20gJiBNZWFsbGluZyAgICBF eHBpcmVzIE5vdmVtYmVyIDMwLCAyMDAyICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgICAgRU5VTSAgICAgICAgICAgICAgICAgICAgICAgICBK dW5lIDIwMDIKCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gICAgICBJbnRyb2R1Y3Rpb24gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgIDEuMSAgICAg VGVybWlub2xvZ3kgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgMwogICAxLjIgICAgIFVzZSBmb3IgdGhlc2UgbWVjaGFuaXNtcyBmb3IgcHJpdmF0ZSBkaWFs aW5nIHBsYW5zIC4gLiAuIC4gIDMKICAgMS4zICAgICBBcHBsaWNhdGlvbiBvZiBsb2NhbCBwb2xp Y3kgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzCiAgIDIuICAgICAgVGhlIEVOVU0g QXBwbGljYXRpb24gU3BlY2lmaWNhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAy LjEgICAgIEFwcGxpY2F0aW9uIFVuaXF1ZSBTdHJpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDQKICAgMi4yICAgICBGaXJzdCBXZWxsIEtub3duIFJ1bGUgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0CiAgIDIuMyAgICAgRXhwZWN0ZWQgT3V0cHV0ICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNAogICAyLjQgICAgIFZh bGlkIERhdGFiYXNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDQKICAgMi40LjEgICBGbGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA1CiAgIDIuNC4yICAgU2VydmljZXMgUGFyYW1ldGVycyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNgogICAyLjQuMi4xIEVOVU0gU2Vydmlj ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYKICAgMy4g ICAgICBSZWdpc3RyYXRpb24gbWVjaGFuaXNtIGZvciBFbnVtc2VydmljZXMgIC4gLiAuIC4gLiAu IC4gLiAuICA4CiAgIDMuMSAgICAgUmVnaXN0cmF0aW9uIFJlcXVpcmVtZW50cyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOAogICAzLjEuMSAgIEZ1bmN0aW9uYWxpdHkgUmVxdWly ZW1lbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgKICAgMy4xLjIgICBOYW1p bmcgcmVxdWlyZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4 CiAgIDMuMS4zICAgU2VjdXJpdHkgcmVxdWlyZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgOAogICAzLjEuNCAgIFB1YmxpY2F0aW9uIFJlcXVpcmVtZW50cyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkKICAgMy4yICAgICBSZWdpc3RyYXRpb24g cHJvY2VkdXJlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5CiAgIDMuMi4x ICAgSUFOQSBSZWdpc3RyYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgOQogICAzLjIuMS4xIExvY2F0aW9uIG9mIEVOVU0gRW51bXNlcnZpY2UgUmVnaXN0cmF0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gIDkKICAgMy4yLjEuMiBDaGFuZ2UgQ29udHJvbCAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwCiAgIDMuMi4yICAgUmVnaXN0 cmF0aW9uIFRlbXBsYXRlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMAog ICA0LiAgICAgIEV4YW1wbGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTEKICAgNC4xICAgICBFeGFtcGxlIDEgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExCiAgIDQuMiAgICAgRXhhbXBsZSAyICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQogICA0LjMgICAg IEV4YW1wbGUgMyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTEKICAgNS4gICAgICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDEzCiAgIDYuICAgICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNAogICA3LiAgICAgIEFja25vd2xl ZGdtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTUKICAg ICAgICAgICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE2CiAgICAgICAgICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNgogICAgICAgICAgIEZ1bGwgQ29weXJpZ2h0IFN0 YXRlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgKCgoKCgoKCgoKCgoK CgoKCkZhbHRzdHJvbSAmIE1lYWxsaW5nICAgIEV4cGlyZXMgTm92ZW1iZXIgMzAsIDIwMDIgICAg ICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBF TlVNICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwMgoKCjEuIEludHJvZHVjdGlvbgoK ICAgVGhyb3VnaCB0cmFuc2Zvcm1hdGlvbiBvZiBFLjE2NCBbOV0gbnVtYmVycyBpbnRvIEROUyBu YW1lcyBhbmQgdGhlCiAgIHVzZSBvZiBleGlzdGluZyBETlMgc2VydmljZXMgbGlrZSBkZWxlZ2F0 aW9uIHRocm91Z2ggTlMgcmVjb3JkcyBhbmQKICAgTkFQVFIgcmVjb3Jkcywgb25lIGNhbiBsb29r IHVwIHdoYXQgc2VydmljZXMgYXJlIGF2YWlsYWJsZSBmb3IgYQogICBzcGVjaWZpYyBkb21haW4g bmFtZSBpbiBhIGRlY2VudHJhbGl6ZWQgd2F5IHdpdGggZGlzdHJpYnV0ZWQKICAgbWFuYWdlbWVu dCBvZiB0aGUgZGlmZmVyZW50IGxldmVscyBpbiB0aGUgbG9va3VwIHByb2Nlc3MuCgogICBUaGUg ZG9tYWluICJlMTY0LmFycGEiIGlzIGJlaW5nIHBvcHVsYXRlZCBpbiBvcmRlciB0byBwcm92aWRl IHRoZQogICBpbmZyYXN0cnVjdHVyZSBpbiBETlMgZm9yIHN0b3JhZ2Ugb2YgRS4xNjQgbnVtYmVy cy4gIEluIG9yZGVyIHRvCiAgIGZhY2lsaXRhdGUgZGlzdHJpYnV0ZWQgb3BlcmF0aW9ucywgdGhp cyBkb21haW4gaXMgZGl2aWRlZCBpbnRvCiAgIHN1YmRvbWFpbnMuICBIb2xkZXJzIG9mIEUuMTY0 IG51bWJlcnMgd2hpY2ggd2FudCB0byBiZSBsaXN0ZWQgaW4gRE5TCiAgIHNob3VsZCBjb250YWN0 IHRoZSBhcHByb3ByaWF0ZSB6b25lIGFkbWluaXN0cmF0b3IgaW4gb3JkZXIgdG8gYmUKICAgbGlz dGVkLCBieSBleGFtaW5pbmcgdGhlIFNPQSByZXNvdXJjZSByZWNvcmQgYXNzb2NpYXRlZCB3aXRo IHRoZQogICB6b25lLCBqdXN0IGxpa2UgaW4gbm9ybWFsIEROUyBvcGVyYXRpb25zLgoKICAgT2Yg Y291cnNlLCBhcyB3aXRoIG90aGVyIGRvbWFpbnMsIHBvbGljaWVzIGZvciBzdWNoIGxpc3Rpbmdz IHdpbGwgYmUKICAgY29udHJvbGxlZCBvbiBhIHN1YmRvbWFpbiBiYXNpcyBhbmQgbWF5IGRpZmZl ciBpbiBkaWZmZXJlbnQgcGFydHMgb2YKICAgdGhlIHdvcmxkLgoKMS4xIFRlcm1pbm9sb2d5Cgog ICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwg IlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAi TUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQyAyMTE5LgoKICAgQWxsIGNhcGl0YWxpemVkIHRlcm1z IGFyZSB0YWtlbiBmcm9tIHRoZSB2b2NhYnVsYXJ5IGZvdW5kIGluIHRoZSBERERTCiAgIGFsZ29y aXRobSBzcGVjaWZpY2F0aW9uIGZvdW5kIGluIFJGQyBaWlpaIFszXS4KCjEuMiBVc2UgZm9yIHRo ZXNlIG1lY2hhbmlzbXMgZm9yIHByaXZhdGUgZGlhbGluZyBwbGFucwoKICAgVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgaG93ICJFTlVNIiB3b3JrcywgdGhhdCBpcyBob3cgdG8gaGFuZGxlCiAgIG51 bWJlcnMgYWxsb2NhdGVkIGFjY29yZGluZyB0byB0aGUgSVRVLVQgc3RhbmRhcmQgRS4xNjQuICBC dXQsIGEKICAgc2ltaWxhciBtZWNoYW5pc20gY2FuIGJlIHVzZWQgYWxzbyBmb3Igb3RoZXIgbnVt YmVycywgc3VjaCBhcyBwcml2YXRlCiAgIGRpYWxpbmcgcGxhbnMuICBUbyBpbXBsZW1lbnQgdGhh dCAoYSkgYSBkaWZmZXJlbnQgZG9tYWluLCB3ZWxsLWtub3duCiAgIGZvciBhbGwgcGFydGllcyB1 c2luZyB0aGUgc2FtZSBkaWFsaW5nIHBsYW4sIFNIT1VMRCBiZSBzZWxlY3RlZCBhbmQKICAgKGIp IHRoZSBhcHBsaWNhdGlvbiB1bmlxdWUgc3RyaW5nIChzZWUgc2VjdGlvbiAzLjEgYmVsb3cpIFNI T1VMRCBiZQogICB0aGUgZnVsbCBudW1iZXIgYXMgc3BlY2lmaWVkIGJ1dCB3aXRob3V0IHRoZSBs ZWFkaW5nICcrJy4KCjEuMyBBcHBsaWNhdGlvbiBvZiBsb2NhbCBwb2xpY3kKCiAgIFRoZSBwcmlv cml0eSBmaWVsZCBpbiB0aGUgTkFQVFIgaXMgYSByZXF1ZXN0IGZyb20gdGhlIGhvbGRlciBvZiB0 aGUKICAgRS4xNjQgaW4gd2hhdCBvcmRlciB0aGUgcmVjb3JkcyBhcmUgdG8gYmUgdXNlZC4gIEl0 IGlzIHRvIGJlIG5vdGVkCiAgIHRoYXQgdGhlIHBhcnR5IGxvb2tpbmcgdXAgdGhlIHJlY29yZHMg TUFZIGFwcGx5IGEgbG9jYWwgcG9saWN5IGZvciBpbgogICB3aGF0IG9yZGVyIHRoZSByZWNvcmRz IGFyZSB0byBiZSB1c2VkIGJhc2VkIG9uIGEgY29tYmluYXRpb24gb2YgdGhlCiAgIHNlcnZpY2Ug ZmllbGRzIGFuZCBVUkkgc2NoZW1lcy4KCgoKCgpGYWx0c3Ryb20gJiBNZWFsbGluZyAgICBFeHBp cmVzIE5vdmVtYmVyIDMwLCAyMDAyICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgRU5VTSAgICAgICAgICAgICAgICAgICAgICAgICBKdW5l IDIwMDIKCgoyLiBUaGUgRU5VTSBBcHBsaWNhdGlvbiBTcGVjaWZpY2F0aW9ucwoKICAgVGhpcyB0 ZW1wbGF0ZSBkZWZpbmVzIHRoZSBFTlVNIERERFMgQXBwbGljYXRpb24gYWNjb3JkaW5nIHRvIHRo ZQogICBydWxlcyBhbmQgcmVxdWlyZW1lbnRzIGZvdW5kIGluIFszXS4gIFRoZSBERERTIGRhdGFi YXNlIHVzZWQgYnkgdGhpcwogICBBcHBsaWNhdGlvbiBpcyBmb3VuZCBpbiBbNF0gd2hpY2ggaXMg dGhlIGRvY3VtZW50IHRoYXQgZGVmaW5lcyB0aGUKICAgTkFQVFIgRE5TIFJlc291cmNlIFJlY29y ZCB0eXBlLgoKMi4xIEFwcGxpY2F0aW9uIFVuaXF1ZSBTdHJpbmcKCiAgIFRoZSBBcHBsaWNhdGlv biBVbmlxdWUgU3RyaW5nIGlzIGEgZnVsbHkgcXVhbGlmaWVkIEUuMTY0IG51bWJlciBtaW51cwog ICBhbnkgbm9uLWRpZ2l0IGNoYXJhY3RlcnMgZXhjZXB0IGZvciB0aGUgJysnIGNoYXJhY3RlciB3 aGljaCBhcHBlYXJzCiAgIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIG51bWJlci4gIFRoZSAiKyIg aXMga2VwdCB0byBwcm92aWRlIGEgd2VsbAogICB1bmRlcnN0b29kIGFuY2hvciBmb3IgdGhlIEFV UyBpbiBvcmRlciB0byBkaXN0aW5ndWlzaCBpdCBmcm9tIG90aGVyCiAgIHRlbGVwaG9uZSBudW1i ZXJzIHRoYXQgYXJlIG5vdCBwYXJ0IG9mIHRoZSBFLjE2NCBuYW1lc3BhY2UuCgogICBGb3IgZXhh bXBsZSwgdGhlIEUuMTY0IG51bWJlciBjb3VsZCBzdGFydCBvdXQgYXMgIisxLTc3MC05MjMtOTU5 NSIuCiAgIFRvIGVuc3VyZSB0aGF0IG5vIHN5bnRhY3RpYyBzdWdhciBpcyBhbGxvd2VkIGludG8g dGhlIEFVUywgYWxsIG5vbi0KICAgZGlnaXRzIGV4Y2VwdCBmb3IgIisiIGFyZSByZW1vdmVkLCB5 aWVsZGluZyAiKzE3NzA5MjM5NTk1Ii4KCjIuMiBGaXJzdCBXZWxsIEtub3duIFJ1bGUKCiAgIFRo ZSBGaXJzdCBXZWxsIEtub3duIFJ1bGUgZm9yIHRoaXMgQXBwbGljYXRpb24gaXMgdGhlIGlkZW50 aXR5IHJ1bGUuCiAgIFRoZSBvdXRwdXQgb2YgdGhpcyBydWxlIGlzIHRoZSBzYW1lIGFzIHRoZSBp bnB1dC4gIFRoaXMgaXMgYmVjYXVzZQogICB0aGUgRS4xNjQgbmFtZXNwYWNlIGFuZCB0aGlzIEFw cGxpY2F0aW9ucyBkYXRhYmFzZXMgYXJlIG9yZ2FuaXplZCBpbgogICBzdWNoIGEgd2F5IHRoYXQg aXQgaXMgcG9zc2libGUgdG8gZ28gZGlyZWN0bHkgZnJvbSB0aGUgbmFtZSB0byB0aGUKICAgc21h bGxlc3QgZ3JhbnVsYXJpdHkgb2YgdGhlIG5hbWVzcGFjZSBkaXJlY3RseSBmcm9tIHRoZSBuYW1l IGl0c2VsZi4KCiAgIFRha2UgdGhlIHByZXZpb3VzIGV4YW1wbGUsIHRoZSBBVVMgaXMgIisxNzcw OTIzOTU5NSIuICBBcHBseWluZyB0aGUKICAgRmlyc3QgV2VsbCBLbm93biBSdWxlIHByb2R1Y2Vz IHRoZSBleGFjdCBzYW1lIHN0cmluZywgIisxNzcwOTIzOTU5NSIuCgoyLjMgRXhwZWN0ZWQgT3V0 cHV0CgogICBUaGUgb3V0cHV0IG9mIHRoZSBsYXN0IERERFMgbG9vcCBpcyBhIFVuaWZvcm0gUmVz b3VyY2UgSWRlbnRpZmllciBpbgogICBpdHMgYWJzb2x1dGUgZm9ybSBhY2NvcmRpbmcgdG8gdGhl ICdhYnNvbHV0ZVVSSScgcHJvZHVjdGlvbiBpbiB0aGUKICAgQ29sbGVjdGVkIEFCTkYgZm91bmQg aW4gUkZDMjM5NiBbN10uCgoyLjQgVmFsaWQgRGF0YWJhc2VzCgogICBBdCBwcmVzZW50IG9ubHkg b25lIERERFMgRGF0YWJhc2UgaXMgc3BlY2lmaWVkIGZvciB0aGlzIEFwcGxpY2F0aW9uLgogICAi RHluYW1pYyBEZWxlZ2F0aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERERFMpIFBhcnQgVGhyZWU6ICBU aGUgRE5TCiAgIERhdGFiYXNlIiAoUkZDIFpaWlopIFs0XSBzcGVjaWZpZXMgYSBERERTIERhdGFi YXNlIHRoYXQgdXNlcyB0aGUKICAgTkFQVFIgRE5TIHJlc291cmNlIHJlY29yZCB0byBjb250YWlu IHRoZSByZXdyaXRlIHJ1bGVzLiAgVGhlIEtleXMgZm9yCiAgIHRoaXMgZGF0YWJhc2UgYXJlIGVu Y29kZWQgYXMgZG9tYWluLW5hbWVzLgoKICAgVGhlIG91dHB1dCBvZiB0aGUgRmlyc3QgV2VsbCBL bm93biBSdWxlIGZvciB0aGUgRU5VTSBBcHBsaWNhdGlvbiBpcwogICB0aGUgRS4xNjQgbnVtYmVy IG1pbnVzIGFsbCBub24tZGlnaXQgY2hhcmFjdGVycyBleGNlcHQgZm9yIHRoZSArLiAgSW4KICAg b3JkZXIgdG8gY29udmVydCB0aGlzIHRvIGEgdW5pcXVlIGtleSBpbiB0aGlzIERhdGFiYXNlIHRo ZSBzdHJpbmcgaXMKICAgY29udmVydGVkIGludG8gYSBkb21haW4tbmFtZSBhY2NvcmRpbmcgdG8g dGhpcyBhbGdvcml0aG06CgoKCkZhbHRzdHJvbSAmIE1lYWxsaW5nICAgIEV4cGlyZXMgTm92ZW1i ZXIgMzAsIDIwMDIgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgICBFTlVNICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwMgoKCiAg IDEuICBSZW1vdmUgYWxsIGNoYXJhY3RlcnMgd2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSBkaWdp dHMuICBGb3IKICAgICAgIGV4YW1wbGUsIHRoZSBGaXJzdCBXZWxsIEtub3duIFJ1bGUgcHJvZHVj ZWQgdGhlIEtleQogICAgICAgIis0Njg5NzYxMjM0Ii4gIFRoaXMgc3RlcCB3b3VsZCBzaW1wbHkg cmVtb3ZlIHRoZSBsZWFkaW5nICIrIiwKICAgICAgIHByb2R1Y2luZyAiNDY4OTc2MTIzNCIuCgog ICAyLiAgUHV0IGRvdHMgKCIuIikgYmV0d2VlbiBlYWNoIGRpZ2l0LiAgRXhhbXBsZTogNC42Ljgu OS43LjYuMS4yLjMuNAoKICAgMy4gIFJldmVyc2UgdGhlIG9yZGVyIG9mIHRoZSBkaWdpdHMuICBF eGFtcGxlOiA0LjMuMi4xLjYuNy45LjguNi40CgogICA0LiAgQXBwZW5kIHRoZSBzdHJpbmcgIi5l MTY0LmFycGEiIHRvIHRoZSBlbmQuICBFeGFtcGxlOgogICAgICAgNC4zLjIuMS42LjcuOS44LjYu NC5lMTY0LmFycGEKCiAgIFRoaXMgZG9tYWluLW5hbWUgaXMgdXNlZCB0byByZXF1ZXN0IE5BUFRS IHJlY29yZHMgd2hpY2ggbWF5IGNvbnRhaW4KICAgdGhlIGVuZCByZXN1bHQgb3IsIGlmIHRoZSBm bGFncyBmaWVsZCBpcyBibGFuaywgcHJvZHVjZXMgbmV3IGtleXMgaW4KICAgdGhlIGZvcm0gb2Yg ZG9tYWluLW5hbWVzIGZyb20gdGhlIEROUy4KCiAgIEROUyBzZXJ2ZXJzIE1BWSBpbnRlcnByZXQg RmxhZyB2YWx1ZXMgYW5kIHVzZSB0aGF0IGluZm9ybWF0aW9uIHRvCiAgIGluY2x1ZGUgYXBwcm9w cmlhdGUgcmVzb3VyY2UgcmVjb3JkcyBpbiB0aGUgQWRkaXRpb25hbCBJbmZvcm1hdGlvbgogICBw b3J0aW9uIG9mIHRoZSBETlMgcGFja2V0LiAgQ2xpZW50cyBhcmUgZW5jb3VyYWdlZCB0byBjaGVj ayBmb3IKICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBidXQgYXJlIG5vdCByZXF1aXJlZCB0byBk byBzby4gIFNlZSB0aGUKICAgQWRkaXRpb25hbCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nIHNlY3Rp b24gb2YgUkZDIFlZWVkgZm9yIG1vcmUKICAgaW5mb3JtYXRpb24gb24gTkFQVFIgcmVjb3JkcyBh bmQgdGhlIEFkZGl0aW9uYWwgSW5mb3JtYXRpb24gc2VjdGlvbgogICBvZiBhIEROUyByZXNwb25z ZSBwYWNrZXQuCgogICBUaGUgY2hhcmFjdGVyIHNldCB1c2VkIHRvIGVuY29kZSB0aGUgc3Vic3Rp dHV0aW9uIGV4cHJlc3Npb24gaXMgVVRGLQogICA4LiAgVGhlIGFsbG93ZWQgaW5wdXQgY2hhcmFj dGVycyBhcmUgYWxsIHRob3NlIGNoYXJhY3RlcnMgdGhhdCBhcmUKICAgYWxsb3dlZCBhbnl3aGVy ZSBpbiBhbiBFLjE2NCBudW1iZXIuICBUaGUgY2hhcmFjdGVycyBhbGxvd2VkIHRvIGJlIGluCiAg IGEgS2V5IGFyZSB0aG9zZSB0aGF0IGFyZSBjdXJyZW50bHkgZGVmaW5lZCBmb3IgRE5TIGRvbWFp bi1uYW1lcy4KCjIuNC4xIEZsYWdzCgogICBUaGlzIERhdGFiYXNlIGNvbnRhaW5zIGEgZmllbGQg dGhhdCBjb250YWlucyBmbGFncyB0aGF0IHNpZ25hbCB3aGVuCiAgIHRoZSBERERTIGFsZ29yaXRo bSBoYXMgZmluaXNoZWQuICBBdCB0aGlzIHRpbWUgb25seSBvbmUgZmxhZywgIlUiLCBpcwogICBk ZWZpbmVkLiAgVGhpcyBtZWFucyB0aGF0IHRoaXMgUnVsZSBpcyB0aGUgbGFzdCBvbmUgYW5kIHRo YXQgdGhlCiAgIG91dHB1dCBvZiB0aGUgUnVsZSBpcyBhIFVSSSBbN10uCgogICBJZiBhIGNsaWVu dCBlbmNvdW50ZXJzIGEgcmVjb3JkIHdpdGggYW4gdW5rbm93biBmbGFnLCBpdCBNVVNUIGlnbm9y ZQogICBpdCBhbmQgbW92ZSB0byB0aGUgbmV4dCBSdWxlLiAgVGhpcyB0ZXN0IHRha2VzIHByZWNl ZGVuY2Ugb3ZlciBhbnkKICAgb3JkZXJpbmcgc2luY2UgZmxhZ3MgY2FuIGNvbnRyb2wgdGhlIGlu dGVycHJldGF0aW9uIHBsYWNlZCBvbiBmaWVsZHMuCiAgIEEgbm92ZWwgZmxhZyBtaWdodCBjaGFu Z2UgdGhlIGludGVycHJldGF0aW9uIG9mIHRoZSByZWdleHAgYW5kL29yCiAgIHJlcGxhY2VtZW50 IGZpZWxkcyBzdWNoIHRoYXQgaXQgaXMgaW1wb3NzaWJsZSB0byBkZXRlcm1pbmUgaWYgYQogICBy ZWNvcmQgbWF0Y2hlZCBhIGdpdmVuIHRhcmdldC4KCiAgIElmIHRoaXMgZmxhZyBpcyBub3QgcHJl c2VudCB0aGVuIHRoaXMgcnVsZSBpcyBub24tdGVybWluYWwuICBJZiBhCiAgIFJ1bGUgaXMgbm9u LXRlcm1pbmFsIHRoZW4gY2xpZW50cyBNVVNUIHVzZSB0aGUgS2V5IHByb2R1Y2VkIGJ5IHRoaXMK ICAgUmV3cml0ZSBSdWxlIGFzIHRoZSBuZXcgS2V5IGluIHRoZSBERERTIGxvb3AgKGkuZS4gIGNh dXNpbmcgdGhlCiAgIGNsaWVudCB0byBxdWVyeSBmb3IgbmV3IE5BUFRSIHJlY29yZHMgYXQgdGhl IGRvbWFpbi1uYW1lIHRoYXQgaXMgdGhlCiAgIHJlc3VsdCBvZiB0aGlzIFJ1bGUpLgoKCgpGYWx0 c3Ryb20gJiBNZWFsbGluZyAgICBFeHBpcmVzIE5vdmVtYmVyIDMwLCAyMDAyICAgICAgICAgICAg ICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgRU5VTSAgICAg ICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDIKCgoyLjQuMiBTZXJ2aWNlcyBQYXJhbWV0ZXJz CgogICBTZXJ2aWNlIFBhcmFtZXRlcnMgZm9yIHRoaXMgQXBwbGljYXRpb24gdGFrZSB0aGUgZm9s bG93aW5nIGZvcm0gYW5kCiAgIGFyZSBmb3VuZCBpbiB0aGUgU2VydmljZSBmaWVsZCBvZiB0aGUg TkFQVFIgcmVjb3JkLgoKCiAgICAgICAgICAgICAgICAgICAgc2VydmljZV9maWVsZCA9ICJFMlUi IDEqKGVudW1zZXJ2aWNlKQogICAJCSBlbnVtc2VydmljZSAgID0gc2VydmljZSBbIjoiIHByb3Rv Y29sXQogICAgICAgICAgICAgICAgICAgIHNlcnZpY2UgICAgICAgPSAxKjMyKEFMUEhBIC8gRElH SVQpCiAgICAgICAgICAgICAgICAgICAgcHJvdG9jb2wgICAgICA9IDEqMzIoQUxQSEEgLyBESUdJ VCkKCgogICBJbiBvdGhlciB3b3JkcywgYSBub24tb3B0aW9uYWwgIkUyVSIgKHVzZWQgdG8gZGVu b3RlIEVOVU0gb25seQogICBSZXdyaXRlIFJ1bGVzIGluIG9yZGVyIHRvIG1pdGlnYXRlIHJlY29y ZCBjb2xsaXNpb25zKSBmb2xsb3dlZCBieSAxCiAgIG9yIG1vcmUgb3IgbW9yZSBFbnVtc2Vydmlj ZXMgd2hpY2ggaW5kaWNhdGUgd2hhdCBjbGFzcyBvZgogICBmdW5jdGlvbmFsaXR5IGEgZ2l2ZW4g ZW5kIHBvaW50IG9mZmVycy4gIEVhY2ggRW51bXNlcnZpY2UgaXMKICAgaW5kaWNhdGVkIGJ5IGFu IGluaXRpYWwgJysnIGNoYXJhY3Rlci4KCiAgIFRoZSBlbXB0eSBzdHJpbmcgaXMgYWxzbyB2YWxp ZC4gIFRoaXMgd2lsbCB0eXBpY2FsbHkgYmUgc2VlbiBhdCB0aGUKICAgYmVnaW5uaW5nIG9mIGEg c2VyaWVzIG9mIFJ1bGVzLCB3aGVuIGl0IGlzIGltcG9zc2libGUgdG8ga25vdyB3aGF0CiAgIHNl cnZpY2VzIGFuZCBwcm90b2NvbHMgd2lsbCBiZSBvZmZlcmVkIGF0IHRoZSBlbmQgb2YgYSBwYXJ0 aWN1bGFyCiAgIGRlbGVnYXRpb24gcGF0aC4KCjIuNC4yLjEgRU5VTSBTZXJ2aWNlcwoKICAgQW4g ZW51bXNlcnZpY2UgTVVTVCBiZSByZWdpc3RlcmVkIHdpdGggdGhlIElBTkEgdmlhIGEgZGVzY3Jp cHRpb24gaW4KICAgYW4gUkZDLiAgRW51bXNlcnZpY2VzIHNwZWNpZmljYXRpb25zIGNvbnRhaW4g dGhlIGZ1bmN0aW9uYWwKICAgc3BlY2lmaWNhdGlvbiAoaS5lLiAgd2hhdCBpdCBjYW4gYmUgdXNl ZCBmb3IpLCB0aGUgdmFsaWQgcHJvdG9jb2xzLAogICBhbmQgdGhlIFVSSSBzY2hlbWVzIHRoYXQg bWF5IGJlIHJldHVybmVkLiAgTm90ZSB0aGF0IHRoZXJlIGlzIG5vCiAgIGltcGxpY2l0IG1hcHBp bmcgYmV0d2VlbiB0aGUgdGV4dHVhbCBzdHJpbmcgInByb3RvY29sIiBhbmQgInNlcnZpY2UiCiAg IGluIHRoZSBncmFtbWFyIGZvciB0aGUgRW51bXNlcnZlciBhbmQgVVJJIHNjaGVtZXMuICBUaGUg bWFwcGluZyBoYXZlCiAgIHRvIGJlIG1hZGUgZXhwbGljaXQgaW4gdGhlIHNwZWNpZmljYXRpb24g Zm9yIHRoZSBFbnVtc2VydmljZSBpdHNlbGYuCiAgIEl0IGlzIGFsbG93ZWQgdG8gc3BlY2lmeSB0 aGUgc2VydmljZSBhbmQgcHJvdG9jb2wgaW4gdHdvIGRpZmZlcmVudAogICBkb2N1bWVudHMsIHRv IG1ha2UgdGhlIGRlc2NyaXB0aW9uIGNvaGVyZW50IGFuZCBlYXN5IHRvIHVuZGVyc3RhbmQuCiAg IEZvciBleGFtcGxlLCB0aGUgRW51bXNlcnZpY2UgInByZXNlbmNlIiAobm90ZSwgbm8gcHJvdG9j b2wKICAgc3BlY2lmaWNhdGlvbikgd291bGQgZGVmaW5lIHRoZSB2YXJpb3VzIFVSSSBzY2hlbWVz ICgiaW06IiwKICAgIm1haWx0bzoiKSBjYW4gYmUgdXNlZCBhbmQgd2hhdCB0aGUgc2VydmljZSBj YW4gYmUgdXNlZCBmb3IgKCJXaGVyZQogICBpcyB0aGUgb3duZXIgb2YgdGhpcyBFLjE2NCBudW1i ZXI/IikuICBBbm90aGVyIGV4YW1wbGUgbWlnaHQgYmUKICAgInRhbGs6c2lwIiB3aGljaCBjYW4g c3BlY2lmeSB0aGF0IHRoZSBVUkkgbXVzdCB1c2UgdGhlICdzaXA6JyBVUkkKICAgc2NoZW1lIGFu ZCB1c2UgdGhlIFNJUCBwcm90b2NvbCB0byBtYWtlIGEgdm9pY2UgY2FsbCAoYXMgb3Bwb3NlZCB0 byBhCiAgIHZvaWNlIG1haWwgY2FsbCBvciBmYXggY2FsbCkuICBXaGF0IGZpbmFsIHByb3RvY29s IHRvIHVzZSBmb3IgdGhlCiAgIGFjdHVhbCB0cmFuc3BvcnQgb2Ygdm9pY2UgaXMgbmVnb3RpYXRl ZCBpbiB0aGUgU0lQIHByb3RvY29sCiAgIG5lZ290aWF0aW9uLgoKICAgVGhlIG9ubHkgZXhjZXB0 aW9uIHRvIHRoZSByZWdpc3RyYXRpb24gcnVsZSBpcyBmb3Igc2VydmljZXMgYW5kCiAgIHByb3Rv Y29scyB1c2VkIGZvciBleHBlcmltZW50YWwgcHVycG9zZXMsIGFuZCB0aG9zZSBhcmUgdG8gc3Rh cnQgd2l0aAogICB0aGUgZmFjZXQgIlgtIi4gIFRoZXNlIHR5cGVzIGFyZSB1bnJlZ2lzdGVyZWQs IGV4cGVyaW1lbnRhbCwgYW5kCiAgIHNob3VsZCBiZSB1c2VkIG9ubHkgd2l0aCB0aGUgYWN0aXZl IGFncmVlbWVudCBvZiB0aGUgcGFydGllcwoKCgpGYWx0c3Ryb20gJiBNZWFsbGluZyAgICBFeHBp cmVzIE5vdmVtYmVyIDMwLCAyMDAyICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgRU5VTSAgICAgICAgICAgICAgICAgICAgICAgICBKdW5l IDIwMDIKCgogICBleGNoYW5naW5nIHRoZW0uCgogICBUaGUgcmVnaXN0cmF0aW9uIG1lY2hhbmlz bSBpcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAzLgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgpGYWx0c3Ryb20gJiBNZWFsbGluZyAgICBFeHBpcmVzIE5vdmVt YmVyIDMwLCAyMDAyICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgICAgRU5VTSAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDIKCgoz LiBSZWdpc3RyYXRpb24gbWVjaGFuaXNtIGZvciBFbnVtc2VydmljZXMKCiAgIFJlZ2lzdHJhdGlv biBvZiBFbnVtc2VydmljZXMgcmVxdWlyZXMgYXBwcm92YWwgYnkgdGhlIElFU0cgYW5kCiAgIHB1 YmxpY2F0aW9uIG9mIHRoZSBFbnVtc2VydmljZSByZWdpc3RyYXRpb24gYXMgc29tZSBmb3JtIG9m IFJGQy4KCjMuMSBSZWdpc3RyYXRpb24gUmVxdWlyZW1lbnRzCgogICBTZXJ2aWNlIHJlZ2lzdHJh dGlvbiBwcm9wb3NhbHMgYXJlIGFsbCBleHBlY3RlZCB0byBjb25mb3JtIHRvIHZhcmlvdXMKICAg cmVxdWlyZW1lbnRzIGxhaWQgb3V0IGluIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnMuCgozLjEuMSBG dW5jdGlvbmFsaXR5IFJlcXVpcmVtZW50CgogICBBbiBFbnVtc2VydmljZSByZWdpc3RlcmVkIG11 c3QgYmUgYWJsZSB0byBmdW5jdGlvbiBhcyBhIHNlbGVjdGlvbgogICBtZWNoYW5pc20gd2hlbiBj aG9vc2luZyBvbmUgTkFQVFIgcmVzb3VyY2UgcmVjb3JkIGZyb20gYW5vdGhlci4gIFRoYXQKICAg bWVhbnMgdGhhdCB0aGUgcmVnaXN0cmF0aW9uIE1VU1Qgc3BlY2lmeSB3aGF0IGlzIGV4cGVjdGVk IHdoZW4gdXNpbmcKICAgdGhhdCB2ZXJ5IE5BUFRSIHJlY29yZCwgYW5kIHRoZSBVUkkgd2hpY2gg aXMgdGhlIG91dGNvbWUgb2YgdGhlIHVzZQogICBvZiBpdC4KCiAgIFNwZWNpZmljYWxseSwgYSBy ZWdpc3RlcmVkIEVudW1zZXJ2aWNlIE1VU1Qgc3BlY2lmeSB0aGUgVVJJIHNjaGVtZShzKQogICB0 aGF0IG1heSBiZSB1c2VkIGZvciB0aGUgRW51bXNlcnZpY2UsIGFuZCwgd2hlbiBuZWVkZWQsIG90 aGVyCiAgIGluZm9ybWF0aW9uIHdoaWNoIHdpbGwgaGF2ZSB0byBiZSB0cmFuc2ZlcmVkIGludG8g dGhlIFVSSSByZXNvbHV0aW9uCiAgIHByb2Nlc3MgaXRzZWxmIChMREFQIEROcywgdHJhbnNmZXJy aW5nIG9mIHRoZSBBVVMgaW50byB0aGUgcmVzdWx0aW5nCiAgIFVSSSwgZXRjKS4KCjMuMS4yIE5h bWluZyByZXF1aXJlbWVudAoKICAgVGhlIG5hbWUgb2YgYW4gRW51bXNlcnZpY2UgTVVTVCBiZSB1 bmlxdWUsIGNvbmZvcm0gdG8gdGhlIEFCTkYKICAgc3BlY2lmaWVkIGluIFNlY3Rpb24gMi40LjIs IGFuZCBNVVNUIE5PVCBzdGFydCB3aXRoIHRoZSBmYWNldCAiWC0iCiAgIHdoaWNoIGlzIHJlc2Vy dmVkIGZvciBleHBlcmltZW50YWwsIHByaXZhdGUgdXNlLgoKMy4xLjMgU2VjdXJpdHkgcmVxdWly ZW1lbnQKCiAgIEFuIGFuYWx5c2lzIG9mIHNlY3VyaXR5IGlzc3VlcyBpcyByZXF1aXJlZCBmb3Ig Zm9yIGFsbCBFbnVtc2VydmljZXMKICAgcmVnaXN0ZXJlZC4gIChUaGlzIGlzIGluIGFjY29yZGFu Y2Ugd2l0aCB0aGUgYmFzaWMgcmVxdWlyZW1lbnRzIGZvcgogICBhbGwgSUVURiBwcm90b2NvbHMu KQoKICAgQWxsIGRlc2NyaXB0aW9ucyBvZiBzZWN1cml0eSBpc3N1ZXMgbXVzdCBiZSBhcyBhY2N1 cmF0ZSBhcyBwb3NzaWJsZQogICByZWdhcmRsZXNzIG9mIHJlZ2lzdHJhdGlvbiB0cmVlLiAgSW4g cGFydGljdWxhciwgYSBzdGF0ZW1lbnQgdGhhdAogICB0aGVyZSBhcmUgIm5vIHNlY3VyaXR5IGlz c3VlcyBhc3NvY2lhdGVkIHdpdGggdGhpcyBFbnVtc2VydmljZSIgbXVzdAogICBub3QgYmUgY29u ZnVzZWQgd2l0aCAidGhlIHNlY3VyaXR5IGlzc3VlcyBhc3NvY2lhdGVzIHdpdGggdGhpcwogICBF bnVtc2VydmljZSBoYXZlIG5vdCBiZWVuIGFzc2Vzc2VkIi4KCiAgIFRoZXJlIGlzIGFic29sdXRl bHkgbm8gcmVxdWlyZW1lbnQgdGhhdCBFbnVtc2VydmljZXMgcmVnaXN0ZXJlZCBtdXN0CiAgIGJl IHNlY3VyZSBvciBjb21wbGV0ZWx5IGZyZWUgZnJvbSByaXNrcy4gIE5ldmVydGhlbGVzcywgYWxs IGtub3duCiAgIHNlY3VyaXR5IHJpc2tzIG11c3QgYmUgaWRlbnRpZmllZCBpbiB0aGUgcmVnaXN0 cmF0aW9uIG9mIGEKICAgRW51bXNlcnZpY2UuCgogICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgc2VjdGlvbiBvZiBhbGwgcmVnaXN0cmF0aW9ucyBpcyBzdWJqZWN0CgoKCkZhbHRzdHJvbSAm IE1lYWxsaW5nICAgIEV4cGlyZXMgTm92ZW1iZXIgMzAsIDIwMDIgICAgICAgICAgICAgICBbUGFn ZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBFTlVNICAgICAgICAgICAg ICAgICAgICAgICAgIEp1bmUgMjAwMgoKCiAgIHRvIGNvbnRpbnVpbmcgZXZhbHVhdGlvbiBhbmQg bW9kaWZpY2F0aW9uLgoKICAgU29tZSBvZiB0aGUgaXNzdWVzIHRoYXQgc2hvdWxkIGJlIGxvb2tl ZCBhdCBpbiBhIHNlY3VyaXR5IGFuYWx5c2lzIG9mCiAgIGEgRW51bXNlcnZpY2UgYXJlOgoKICAg MS4gIENvbXBsZXggRW51bXNlcnZpY2VzIG1heSBpbmNsdWRlIHByb3Zpc2lvbnMgZm9yIGRpcmVj dGl2ZXMgdGhhdAogICAgICAgaW5zdGl0dXRlIGFjdGlvbnMgb24gYSB1c2VycyByZXNvdXJjZXMu ICBJbiBtYW55IGNhc2VzIHByb3Zpc2lvbgogICAgICAgY2FuIGJlIG1hZGUgdG8gc3BlY2lmeSBh cmJpdHJhcnkgYWN0aW9ucyBpbiBhbiB1bnJlc3RyaWN0ZWQKICAgICAgIGZhc2hpb24gd2hpY2gg bWF5IHRoZW4gaGF2ZSBkZXZhc3RhdGluZyByZXN1bHRzLiAgRXNwZWNpYWxseSBpZgogICAgICAg dGhlcmUgaXMgYSByaXNrIGZvciBhIG5ldyBFTlVNIGxvb2t1cCwgYW5kIGJlY2F1c2Ugb2YgdGhh dCBhbgogICAgICAgaW5maW5pdGUgbG9vcCBpbiB0aGUgb3ZlcmFsbCByZXNvbHV0aW9uIHByb2Nl c3Mgb2YgdGhlIEUuMTY0LgoKICAgMi4gIENvbXBsZXggRW51bXNlcnZpY2VzIG1heSBpbmNsdWRl IHByb3Zpc2lvbnMgZm9yIGRpcmVjdGl2ZXMgdGhhdAogICAgICAgaW5zdGl0dXRlIGFjdGlvbnMg d2hpY2gsIHdoaWxlIG5vdCBkaXJlY3RseSBoYXJtZnVsLCBtYXkgcmVzdWx0CiAgICAgICBpbiBk aXNjbG9zdXJlIG9mIGluZm9ybWF0aW9uIHRoYXQgZWl0aGVyIGZhY2lsaXRhdGVzIGEgc3Vic2Vx dWVudAogICAgICAgYXR0YWNrIG9yIGVsc2UgdmlvbGF0ZXMgdGhlIHVzZXJzIHByaXZhY3kgaW4g c29tZSB3YXkuCgogICAzLiAgQW4gRW51bXNlcnZpY2UgbWlnaHQgYmUgdGFyZ2V0ZWQgZm9yIGFw cGxpY2F0aW9ucyB0aGF0IHJlcXVpcmUKICAgICAgIHNvbWUgc29ydCBvZiBzZWN1cml0eSBhc3N1 cmFuY2UgYnV0IG5vdCBwcm92aWRlIHRoZSBuZWNlc3NhcnkKICAgICAgIHNlY3VyaXR5IG1lY2hh bmlzbXMgdGhlbXNlbHZlcy4gIEZvciBleGFtcGxlLCBhIEVudW1zZXJ2aWNlIGNvdWxkCiAgICAg ICBiZSBkZWZpbmVkIGZvciBzdG9yYWdlIG9mIGNvbmZpZGVudGlhbCBtZWRpY2FsIGluZm9ybWF0 aW9uIHdoaWNoCiAgICAgICBpbiB0dXJuIHJlcXVpcmVzIGFuIGV4dGVybmFsIGNvbmZpZGVudGlh bGl0eSBzZXJ2aWNlLgoKCjMuMS40IFB1YmxpY2F0aW9uIFJlcXVpcmVtZW50cwoKICAgUHJvcG9z YWxzIGZvciBFbnVtc2VydmljZXMgcmVnaXN0ZXJlZCBtdXN0IGJlIHB1Ymxpc2hlZCBhcyBSRkNz LgogICBJQU5BIHdpbGwgcmV0YWluIGNvcGllcyBvZiBhbGwgRW51bXNlcnZpY2UgcmVnaXN0cmF0 aW9uIHByb3Bvc2FscyBhbmQKICAgInB1Ymxpc2giIHRoZW0gYXMgcGFydCBvZiB0aGUgRU5VTSBF bnVtc2VydmljZSBSZWdpc3RyYXRpb24gdHJlZQogICBpdHNlbGYuCgozLjIgUmVnaXN0cmF0aW9u IHByb2NlZHVyZQoKICAgTm9ybWFsIElFVEYgcHJvY2Vzc2VzIHNob3VsZCBiZSB1c2VkIGZvciBw dWJsaWNhdGlvbiBvZiB0aGUgUkZDIHdoaWNoCiAgIGlzIHRoZSBiYXNpcyBvZiB0aGUgcmVnaXN0 cmF0aW9uIG9mIHRoZSBFbnVtc2VydmljZSBpdHNlbGYuCgozLjIuMSBJQU5BIFJlZ2lzdHJhdGlv bgoKICAgUHJvdmlkZWQgdGhhdCB0aGUgRW51bXNlcnZpY2UgaGFzIG9idGFpbmVkIGFwcHJvdmFs IHRoYXQgaXMKICAgbmVjZXNzYXJ5LCBhbmQgdGhlIFJGQyBpcyBwdWJsaXNoZWQsIElBTkEgd2ls bCByZWdpc3RlciB0aGUKICAgRW51bXNlcnZpY2UgYW5kIG1ha2UgdGhlIEVudW1zZXJ2aWNlIHJl Z2lzdHJhdGlvbiBhdmFpbGFibGUgdG8gdGhlCiAgIGNvbW11bml0eSBpbiBhZGRpdGlvbiB0byB0 aGUgUkZDIHB1YmxpY2F0aW9uIGl0c2VsZi4KCjMuMi4xLjEgTG9jYXRpb24gb2YgRU5VTSBFbnVt c2VydmljZSBSZWdpc3RyYXRpb25zCgogICBFbnVtc2VydmljZSByZWdpc3RyYXRpb25zIHdpbGwg YmUgcHVibGlzaGVkIGluIHRoZSBJQU5BIHJlcG9zaXRvcnkKICAgYW5kIG1hZGUgYXZhaWxhYmxl IHZpYSBhbm9ueW1vdXMgRlRQIGF0IHRoZSBmb2xsb3dpbmcgVVJJOiAiZnRwOi8vCiAgIGZ0cC5p c2kuZWR1L2luLW5vdGVzL2lhbmEvYXNzaWdubWVudHMvZW51bS1zZXJ2aWNlcy8iLgoKCgpGYWx0 c3Ryb20gJiBNZWFsbGluZyAgICBFeHBpcmVzIE5vdmVtYmVyIDMwLCAyMDAyICAgICAgICAgICAg ICAgW1BhZ2UgOV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgRU5VTSAgICAg ICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDIKCgozLjIuMS4yIENoYW5nZSBDb250cm9sCgog ICBDaGFuZ2UgY29udHJvbCBvZiBFbnVtc2VydmljZXMgc3RheSB3aXRoIHRoZSBJRVRGIHZpYSB0 aGUgUkZDCiAgIHB1YmxpY2F0aW9uIHByb2Nlc3MuICBFc3BlY2lhbGx5LCBFbnVtc2VydmljZSBy ZWdpc3RyYXRpb25zIG1heSBub3QKICAgYmUgZGVsZXRlZDsgRW51bXNlcnZpY2VzIHdoaWNoIGFy ZSBubyBsb25nZXIgYmVsaWV2ZWQgYXBwcm9wcmlhdGUgZm9yCiAgIHVzZSBjYW4gYmUgZGVjbGFy ZWQgT0JTT0xFVEUgYnkgcHVibGljYXRpb24gb2YgYSBuZXcgUkZDIGFuZCBhIGNoYW5nZQogICB0 byB0aGVpciAiaW50ZW5kZWQgdXNlIiBmaWVsZDsgc3VjaCBtZWRpYSB0eXBlcyB3aWxsIGJlIGNs ZWFybHkKICAgbWFya2VkIGluIHRoZSBsaXN0cyBwdWJsaXNoZWQgYnkgSUFOQS4KCjMuMi4yIFJl Z2lzdHJhdGlvbiBUZW1wbGF0ZQoKICAgRW51bXNlcnZpY2UgTmFtZToKCiAgIFVSSSBTY2hlbWUo cyk6CgogICBGdW5jdGlvbmFsIFNwZWNpZmljYXRpb246CgogICBTZWN1cml0eSBjb25zaWRlcmF0 aW9uczoKCiAgIEludGVuZGVkIHVzYWdlOiAoT25lIG9mIENPTU1PTiwgTElNSVRFRCBVU0Ugb3Ig T0JTT0xFVEUpCgogICBBdXRob3I6CgogICBBbnkgb3RoZXIgaW5mb3JtYXRpb24gdGhhdCB0aGUg YXV0aG9yIGRlZW1zIGludGVyZXN0aW5nOgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpGYWx0 c3Ryb20gJiBNZWFsbGluZyAgICBFeHBpcmVzIE5vdmVtYmVyIDMwLCAyMDAyICAgICAgICAgICAg ICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgRU5VTSAgICAg ICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDIKCgo0LiBFeGFtcGxlcwoKICAgVGhlIGV4YW1w bGVzIGJlbG93IHVzZSB0aGVvcmV0aWNhbCBzZXJ2aWNlcyB3aGljaCB1c2VzIEVudW1zZXJ2aWNl cwogICB3aGljaCBtaWdodCBub3QgbWFrZSBzZW5zZSwgYnV0IHRoZXkgYXJlIHN0aWxsIHVzZWQg Zm9yIGVkdWNhdGlvbmFsCiAgIHB1cnBvc2VzLiAgRm9yIGV4YW1wbGUsIHRoZSBwcm90b2NvbCB1 c2VkIGlzIGV4YWN0bHkgdGhlIHNhbWUgYXMgdGhlCiAgIFVSSSBzY2hlbWUuICBUaGF0IHdhcyB0 aGUgc3BlY2lmaWNhdGlvbiBpbiBSRkMgMjkxNiwgYnV0IHRoaXMgZGVmYXVsdAogICBzcGVjaWZp Y2F0aW9uIG9mIGEgRW51bXNlcnZpY2UgaXMgbm8gbG9uZ2VyIGFsbG93ZWQuICBBbGwKICAgRW51 bXNlcnZpY2VzIG5lZWQgdG8gYmUgcmVnaXN0ZXJlZCBleHBsaWNpdGx5IGJ5IHRoZSBwcm9jZWR1 cmUKICAgc3BlY2lmaWVkIGluIHNlY3Rpb24gU2VjdGlvbiAzTi4KCjQuMSBFeGFtcGxlIDEKCgoK ICAgJE9SSUdJTiA0LjMuMi4xLjYuNy45LjguNi40LmUxNjQuYXJwYS4KICAgICAgSU4gTkFQVFIg MTAwIDEwICJ1IiAiRTJVK3RhbGs6c2lwIiAgICAgICAiIV4uKiQhc2lwOmluZm9AdGVsZTIuc2Uh IiAgICAgLgogICAgICBJTiBOQVBUUiAxMDIgMTAgInUiICJFMlUrbWVzc2FnZTptYWlsdG8iICIh Xi4qJCFtYWlsdG86aW5mb0B0ZWxlMi5zZSEiICAuCgoKICAgVGhpcyBkZXNjcmliZXMgdGhhdCB0 aGUgZG9tYWluIDQuMy4yLjEuNi43LjkuOC42LjQuZTE2NC5hcnBhIGlzCiAgIHByZWZlcmFibHkg Y29udGFjdGVkIGJ5IFNJUCBmb3Igdm9pY2UsIGFuZCBzZWNvbmRseSBieSBTTVRQIGZvcgogICBt ZXNzYWdpbmcuCgogICBJbiBib3RoIGNhc2VzLCB0aGUgbmV4dCBzdGVwIGluIHRoZSByZXNvbHV0 aW9uIHByb2Nlc3MgaXMgdG8gdXNlIHRoZQogICByZXNvbHV0aW9uIG1lY2hhbmlzbSBmb3IgZWFj aCBvZiB0aGUgcHJvdG9jb2xzLCAoc3BlY2lmaWVkIGJ5IHRoZSBVUkkKICAgc2NoZW1lcyBTSVAg YW5kIFNNVFApIHRvIGtub3cgd2hhdCBub2RlIHRvIGNvbnRhY3QgZm9yIGVhY2guCgo0LjIgRXhh bXBsZSAyCgoKCiAgICRPUklHSU4gNC4zLjIuMS42LjcuOS44LjYuNC5lMTY0LmFycGEuCiAgICAg SU4gTkFQVFIgIDEwIDEwICJ1IiAiRTJVK3RhbGs6c2lwK21lc3NhZ2U6c2lwIiAiIV4uKiQhc2lw OnBhZkBzd2lwLm5ldCEiICAgIC4KICAgICBJTiBOQVBUUiAxMDIgMTAgInUiICJFMlUrbWVzc2Fn ZTptYWlsdG8iICAgICAgICIhXi4qJCFtYWlsdG86cGFmQHN3aXAubmV0ISIgLgogICAgIElOIE5B UFRSIDEwMiAxMCAidSIgIkUyVSt0YWxrOnRlbCIgICAgICAgICAgICAgIiFeKC4qJCkkIXRlbDpc MSEiICAgICAgICAgICAuCgoKICAgTm90ZSB0aGF0IG9uZSBjYW4gdXNlIHRoZSBzaXAgcHJvdG9j b2wgZm9yIGJvdGggInRhbGsiIGFuZCAibWVzc2FnZSIsCiAgIGFuZCB0aGF0IHRoZSBzaXAgVVJJ IGlzIHRoZSBwcmVmZXJyZWQgVVJJIHRvIHVzZS4gIFRoZSBVUkkgaXMKICAgcmVzb2x2ZWQgYXMg ZGVzY3JpYmVkIGluIFJGQyAyNTQzIFs2XS4gIEluIHRoZSBjYXNlIG9mIHRoZSAidGVsIiBVUkkK ICAgc2NoZW1lIFs3XSwgYSByZXBsYWNlbWVudCAiXDEiIGlzIHVzZWQuCgogICBUaGUgcmVzdCBv ZiB0aGUgcmVzb2x1dGlvbiBvZiB0aGUgcm91dGluZyBpcyBkb25lIGFzIGRlc2NyaWJlZCBhYm92 ZS4KCjQuMyBFeGFtcGxlIDMKCgoKCgoKRmFsdHN0cm9tICYgTWVhbGxpbmcgICAgRXhwaXJlcyBO b3ZlbWJlciAzMCwgMjAwMiAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICAgIEVOVU0gICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDAy CgoKICAgICAgJE9SSUdJTiA2LjQuZTE2NC5hcnBhLgogICAgICAqIElOIE5BUFRSIDEwMCAxMCAi dSIgIkUyVSt2cGltOmxkYXAiICIhXis0NiguKikkIWxkYXA6Ly9sZGFwLnNlL2NuPVwxISIgLgoK CiAgIFdlIHNlZSBpbiB0aGlzIGV4YW1wbGUgdGhhdCBpbmZvcm1hdGlvbiBhYm91dCBhbGwgRS4x NjQgbnVtYmVycyBpbgogICB0aGUgNDYgY291bnRyeWNvZGUgKGZvciBTd2VkZW4pIGV4aXN0cyBp biBhbiBMREFQIHNlcnZlciwgYW5kIHRoZQogICBzZWFyY2ggdG8gZG8gaXMgc3BlY2lmaWVkIGJ5 IHRoZSBMREFQIFVSSSBbOF0uICBUaGUgc2VydmljZSB2cGltIGlzCiAgIHVzZWQgdG8gbWVudGlv biB0aGF0IHRoZSBkYXRhYmFzZSBleHBsaWNpdGx5IGhvbGRzIGRhdGEgYWNjb3JkaW5nIHRvCiAg IHNvbWUgKGh5cG90aGV0aWNhbCkgdnBpbSAoVm9pY2UgUHJvZmlsZSBmb3IgSW50ZXJuZXQgTWFp bCkKICAgc3BlY2lmaWNhdGlvbi4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgpGYWx0c3Ryb20gJiBNZWFsbGluZyAgICBFeHBpcmVzIE5vdmVtYmVyIDMwLCAyMDAyICAg ICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg RU5VTSAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDIKCgo1LiBJQU5BIENvbnNpZGVy YXRpb25zCgogICBUaGlzIG1lbW8gcmVxdWVzdHMgdGhhdCB0aGUgSUFOQSBkZWxlZ2F0ZSB0aGUg RTE2NC5BUlBBIGRvbWFpbgogICBmb2xsb3dpbmcgaW5zdHJ1Y3Rpb25zIHRvIGJlIHByb3ZpZGVk IGJ5IHRoZSBJQUIuICBOYW1lcyB3aXRoaW4gdGhpcwogICB6b25lIGFyZSB0byBiZSBkZWxlZ2F0 ZWQgdG8gcGFydGllcyBhY2NvcmRpbmcgdG8gdGhlIElUVQogICByZWNvbW1lbmRhdGlvbiBFLjE2 NC4gIFRoZSBuYW1lcyBhbGxvY2F0ZWQgc2hvdWxkIGJlIGhpZXJhcmNoaWMgaW4KICAgYWNjb3Jk YW5jZSB3aXRoIElUVSBSZWNvbW1lbmRhdGlvbiBFLjE2NCwgYW5kIHRoZSBjb2RlcyBzaG91bGQK ICAgYXNzaWduZWQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoYXQgUmVjb21tZW5kYXRpb24uCgogICBJ QUIgaXMgdG8gY29vcmRpbmF0ZSB3aXRoIElUVS1UIFRTQiBpZiB0aGUgdGVjaG5pY2FsIGNvbnRh Y3QgZm9yIHRoZQogICBkb21haW4gZTE2NC5hcnBhIGlzIHRvIGNoYW5nZSwgYXMgSVRVLVQgVFNC IGhhcyBhbiBvcGVyYXRpb25hbAogICB3b3JraW5nIHJlbGF0aW9uc2hpcCB3aXRoIHRoaXMgdGVj aG5pY2FsIGNvbnRhY3Qgd2hpY2ggbmVlZHMgdG8gYmUKICAgcmVlc3RhYmxpc2hlZC4KCiAgIERl bGVnYXRpb25zIGluIHRoZSB6b25lIGUxNjQuYXJwYSAobm90IGRlbGVnYXRpb25zIGluIGRlbGVn YXRlZAogICBkb21haW5zIG9mIGUxNjQuYXJwYSkgc2hvdWxkIGJlIGRvbmUgYWZ0ZXIgRXhwZXJ0 IFJldmlldywgYW5kIHRoZQogICBJRVNHIHdpbGwgYXBwb2ludCBhIGRlc2lnbmF0ZWQgZXhwZXJ0 LgoKICAgSUFOQSBpcyB0byBjcmVhdGUgYSByZWdpc3RyeSBmb3IgRU5VTSBFbnVtc2VydmljZXMg YXMgc3BlY2lmaWVkIGluCiAgIFNlY3Rpb24gMy4gIFdoZW5ldmVyIGEgbmV3IEVOVU0gRW51bXNl cnZpY2UgaXMgcmVnaXN0ZXJlZCBieSB0aGUgUkZDCiAgIHByb2Nlc3MgaW4gdGhlIElFVEYsIElB TkEgaXMgYXQgdGhlIHRpbWUgb2YgcHVibGljYXRpb24gb2YgdGhlIFJGQyB0bwogICByZWdpc3Rl ciB0aGUgRW51bXNlcnZpY2UgYW5kIGFkZCBhIHBvaW50ZXIgdG8gdGhlIFJGQyBpdHNlbGYuCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKRmFsdHN0cm9tICYgTWVhbGxpbmcgICAgRXhwaXJl cyBOb3ZlbWJlciAzMCwgMjAwMiAgICAgICAgICAgICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgIEVOVU0gICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAy MDAyCgoKNi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIEFzIHRoaXMgc3lzdGVtIGlzIGJ1 aWx0IG9uIHRvcCBvZiBETlMsIG9uZSBjYW4gbm90IGJlIHN1cmUgdGhhdCB0aGUKICAgaW5mb3Jt YXRpb24gb25lIGdldCBiYWNrIGZyb20gRE5TIGlzIG1vcmUgc2VjdXJlIHRoYW4gYW55IEROUyBx dWVyeS4KICAgVG8gc29sdmUgdGhhdCwgdGhlIHVzZSBvZiBETlNTRUMgWzldIGZvciBzZWN1cmlu ZyBhbmQgdmVyaWZ5aW5nIHpvbmVzCiAgIGlzIHRvIGJlIHJlY29tbWVuZGVkLgoKICAgVGhlIGNh Y2hpbmcgaW4gRE5TIGNhbiBtYWtlIHRoZSBwcm9wYWdhdGlvbiB0aW1lIGZvciBhIGNoYW5nZSB0 YWtlCiAgIHRoZSBzYW1lIGFtb3VudCBvZiB0aW1lIGFzIHRoZSB0aW1lIHRvIGxpdmUgZm9yIHRo ZSBOQVBUUiByZWNvcmRzIGluCiAgIHRoZSB6b25lIHRoYXQgaXMgY2hhbmdlZC4gIFRoZSB1c2Ug b2YgdGhpcyBpbiBhbiBlbnZpcm9ubWVudCB3aGVyZQogICBJUC1hZGRyZXNzZXMgYXJlIGZvciBo aXJlIChmb3IgZXhhbXBsZSwgd2hlbiB1c2luZyBESENQIFsxMV0pIG11c3QKICAgdGhlcmVmb3Jl IGJlIGRvbmUgdmVyeSBjYXJlZnVsbHkuCgogICBUaGVyZSBhcmUgYSBudW1iZXIgb2YgY291bnRy aWVzIChhbmQgb3RoZXIgbnVtYmVyaW5nIGVudmlyb25tZW50cykgaW4KICAgd2hpY2ggdGhlcmUg YXJlIG11bHRpcGxlIHByb3ZpZGVycyBvZiBjYWxsIHJvdXRpbmcgYW5kIG51bWJlci9uYW1lLQog ICB0cmFuc2xhdGlvbiBzZXJ2aWNlcy4gIEluIHRoZXNlIGFyZWFzLCBhbnkgc3lzdGVtIHRoYXQg cGVybWl0cyB1c2VycywKICAgb3IgcHV0YXRpdmUgYWdlbnRzIGZvciB1c2VycywgdG8gY2hhbmdl IHJvdXRpbmcgb3Igc3VwcGxpZXIKICAgaW5mb3JtYXRpb24gbWF5IHByb3ZpZGUgaW5jZW50aXZl cyBmb3IgY2hhbmdlcyB0aGF0IGFyZSBhY3R1YWxseQogICB1bmF1dGhvcml6ZWQgKGFuZCwgaW4g c29tZSBjYXNlcywgZm9yIGRlbmlhbCBvZiBsZWdpdGltYXRlIGNoYW5nZQogICByZXF1ZXN0cyku ICBTdWNoIGVudmlyb25tZW50cyBzaG91bGQgYmUgZGVzaWduZWQgd2l0aCBhZGVxdWF0ZQogICBt ZWNoYW5pc21zIGZvciBpZGVudGlmaWNhdGlvbiBhbmQgYXV0aGVudGljYXRpb24gb2YgdGhvc2Ug cmVxdWVzdGluZwogICBjaGFuZ2VzIGFuZCBmb3IgYXV0aG9yaXphdGlvbiBvZiB0aG9zZSBjaGFu Z2VzLgoKICAgQSBsYXJnZSBhbW91bnQgb2YgU2VjdXJpdHkgSXNzdWVzIGhhdmUgdG8gZG8gd2l0 aCB0aGUgcmVzb2x1dGlvbgogICBwcm9jZXNzIGl0c2VsZiwgYW5kIHVzZSBvZiB0aGUgVVJJcyBw cm9kdWNlZCBieSB0aGUgREREUyBtZWNoYW5pc20uCiAgIFRob3NlIGhhdmUgdG8gYmUgc3BlY2lm aWVkIGluIHRoZSByZWdpc3RyYXRpb24gb2YgdGhlIEVOVU0KICAgRW51bXNlcnZpY2UgdXNlZCwg YXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gMy4xLjMuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkZh bHRzdHJvbSAmIE1lYWxsaW5nICAgIEV4cGlyZXMgTm92ZW1iZXIgMzAsIDIwMDIgICAgICAgICAg ICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBFTlVNICAg ICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwMgoKCjcuIEFja25vd2xlZGdtZW50cwoKICAg U3VwcG9ydCBhbmQgaWRlYXMgbGVhZGluZyB0byBSRkMgMjkxNiBoYXZlIGNvbWUgZnJvbSBwZW9w bGUgYXQKICAgRXJpY3Nzb24sIEJqb3JuIExhcnNzb24gYW5kIHRoZSBncm91cCB3aGljaCBpbXBs ZW1lbnRlZCB0aGlzIHNjaGVtZQogICBpbiB0aGVpciBsYWIgdG8gc2VlIHRoYXQgaXQgd29ya2Vk LiAgSW5wdXQgaGFzIGFsc28gYXJyaXZlZCBmcm9tIElUVS0KICAgVCBTRzIsIFdvcmtpbmcgUGFy dHkgMS8yIChOdW1iZXJpbmcsIFJvdXRpbmcsIEdsb2JhbCBNb2JpbGl0eSBhbmQKICAgRW51bXNl cnZpY2UgRGVmaW5pdGlvbiksIHRoZSBFTlVNIHdvcmtpbmcgZ3JvdXAgaW4gdGhlIElFVEYsIEpv aG4KICAgS2xlbnNpbiBhbmQgTGVpZiBTdW5uZWdhcmRoLgoKICAgVGhpcyB1cGRhdGUgb2YgUkZD IDI5MTYgaXMgY3JlYXRlZCB3aXRoIHNwZWNpZmljIGlucHV0IGZyb206IFJhbmR5CiAgIEJ1c2gs IERhdmlkIENvbnJhZCwgUmljaGFyZCBIaWxsLCBKaW0gUmVpZCwgSm9ha2ltIFN0cmFsbWFyaywg Um9iZXJ0CiAgIFdhbHRlciBhbmQgSmFtZXMgWXUuCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCkZhbHRzdHJvbSAmIE1lYWxsaW5nICAgIEV4cGlyZXMgTm92ZW1iZXIgMzAs IDIwMDIgICAgICAgICAgICAgIFtQYWdlIDE1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgICBFTlVNICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwMgoKClJlZmVyZW5j ZXMKCiAgIFsxXSAgTWVhbGxpbmcsIE0uLCAiRHluYW1pYyBEZWxlZ2F0aW9uIERpc2NvdmVyeSBT eXN0ZW0gKERERFMpIFBhcnQKICAgICAgICBPbmU6IFRoZSBDb21wcmVoZW5zaXZlIERERFMgU3Rh bmRhcmQiLCBSRkMgV1dXVywgZHJhZnQtaWV0Zi11cm4tCiAgICAgICAgZGRkcy10b2MtMDIudHh0 ICh3b3JrIGluIHByb2dyZXNzKSwgRmVicnVhcnkgMjAwMi4KCiAgIFsyXSAgTWVhbGxpbmcsIE0u LCAiRHluYW1pYyBEZWxlZ2F0aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERERFMpIFBhcnQKICAgICAg ICBUd286IFRoZSBBbGdvcml0aG0iLCBSRkMgWFhYWCwgZHJhZnQtaWV0Zi11cm4tZGRkcy0wNi50 eHQgKHdvcmsKICAgICAgICBpbiBwcm9ncmVzcyksIEZlYnJ1YXJ5IDIwMDIuCgogICBbM10gIE1l YWxsaW5nLCBNLiwgIkR5bmFtaWMgRGVsZWdhdGlvbiBEaXNjb3ZlcnkgU3lzdGVtIChERERTKSBQ YXJ0CiAgICAgICAgVGhyZWU6IFRoZSBETlMgRGF0YWJhc2UiLCBSRkMgWlpaWiwgZHJhZnQtaWV0 Zi11cm4tZG5zLWRkZHMtCiAgICAgICAgZGF0YWJhc2UtMDgudHh0ICh3b3JrIGluIHByb2dyZXNz KSwgRmVicnVhcnkgMjAwMi4KCiAgIFs0XSAgTWVhbGxpbmcsIE0uLCAiRHluYW1pYyBEZWxlZ2F0 aW9uIERpc2NvdmVyeSBTeXN0ZW0gKERERFMpIFBhcnQKICAgICAgICBGb3VyOiBUaGUgVVJJIFJl c29sdXRpb24gQXBwbGljYXRpb24iLCBSRkMgWVlZWSwgZHJhZnQtaWV0Zi11cm4tCiAgICAgICAg dXJpLXJlcy1kZGRzLTA2LnR4dCAod29yayBpbiBwcm9ncmVzcyksIEZlYnJ1YXJ5IDIwMDIuCgog ICBbNV0gIE1lYWxsaW5nLCBNLiwgIkR5bmFtaWMgRGVsZWdhdGlvbiBEaXNjb3ZlcnkgU3lzdGVt IChERERTKSBQYXJ0CiAgICAgICAgRml2ZTogVVJJLkFSUEEgQXNzaWdubWVudCBQcm9jZWR1cmVz IiwgUkZDIFZWVlYsIGRyYWZ0LWlldGYtdXJuLQogICAgICAgIG5ldC1wcm9jZWR1cmVzLTEwLnR4 dCAod29yayBpbiBwcm9ncmVzcyksIEZlYnJ1YXJ5IDIwMDIuCgogICBbNl0gIE1lYWxsaW5nLCBN LiwgIlVSSSBSZXNvbHV0aW9uIFNlcnZpY2VzIE5lY2Vzc2FyeSBmb3IgVVJOCiAgICAgICAgUmVz b2x1dGlvbiIsIFJGQyAyNDgzLCBKYW51YXJ5IDE5OTkuCgogICBbN10gIEJlcm5lcnMtTGVlLCBU LiwgRmllbGRpbmcsIFIuIGFuZCBMLiBNYXNpbnRlciwgIlVuaWZvcm0gUmVzb3VyY2UKICAgICAg ICBJZGVudGlmaWVycyAoVVJJKTogR2VuZXJpYyBTeW50YXgiLCBSRkMgMjM5NiwgQXVndXN0IDE5 OTguCgogICBbOF0gIFBldGtlLCBSLiBhbmQgSS4gS2luZywgIlJlZ2lzdHJhdGlvbiBQcm9jZWR1 cmVzIGZvciBVUkwgU2NoZW1lCiAgICAgICAgTmFtZXMiLCBSRkMgMjcxNywgQkNQIDM1LCBOb3Zl bWJlciAxOTk5LgoKICAgWzldICBJVFUtVCwgIlRoZSBJbnRlcm5hdGlvbmFsIFB1YmxpYyBUZWxl Y29tbXVuaWNhdGlvbiBOdW1iZXIgUGxhbiIsCiAgICAgICAgUmVjb21tZW5kYXRpb24gRS4xNjQs IE1heSAxOTk3LgoKCkF1dGhvcnMnIEFkZHJlc3NlcwoKICAgUGF0cmlrIEZhbHRzdHJvbQogICBD aXNjbyBTeXN0ZW1zIEluYwogICAxNzAgVyBUYXNtYW4gRHJpdmUgU0otMTMvMgogICBTYW4gSm9z ZSwgQ0EgIDk1MTM0CiAgIFVTQQoKICAgRU1haWw6IHBhZkBjaXNjby5jb20KICAgVVJJOiAgIGh0 dHA6Ly93d3cuY2lzY28uY29tCgoKCgoKCkZhbHRzdHJvbSAmIE1lYWxsaW5nICAgIEV4cGlyZXMg Tm92ZW1iZXIgMzAsIDIwMDIgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgICBFTlVNICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAw MgoKCiAgIE1pY2hhZWwgTWVhbGxpbmcKICAgVmVyaVNpZ24KICAgMjEzNDUgUmlkZ2V0b3AgQ2ly Y2xlCiAgIFN0ZXJsaW5nLCBWQSAgMjAxNjYKICAgVVMKCiAgIEVNYWlsOiBtaWNoYWVsQG5lb255 bS5uZXQKICAgVVJJOiAgIGh0dHA6Ly93d3cudmVyaXNpZ25sYWJzLmNvbQoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKRmFsdHN0cm9tICYgTWVhbGxpbmcgICAgRXhw aXJlcyBOb3ZlbWJlciAzMCwgMjAwMiAgICAgICAgICAgICAgW1BhZ2UgMTddCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICAgIEVOVU0gICAgICAgICAgICAgICAgICAgICAgICAgSnVu ZSAyMDAyCgoKRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50CgogICBDb3B5cmlnaHQgKEMpIFRoZSBJ bnRlcm5ldCBTb2NpZXR5ICgyMDAyKS4gIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCgogICBUaGlzIGRv Y3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVk IHRvCiAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90 aGVyd2lzZSBleHBsYWluIGl0CiAgIG9yIGFzc2lzdCBpbiBpdHMgaW1wbGVtZW50YXRpb24gbWF5 IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hlZAogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdo b2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55CiAgIGtpbmQsIHByb3Zp ZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFy ZQogICBpbmNsdWRlZCBvbiBhbGwgc3VjaCBjb3BpZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuICBI b3dldmVyLCB0aGlzCiAgIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVkIGluIGFu eSB3YXksIHN1Y2ggYXMgYnkgcmVtb3ZpbmcKICAgdGhlIGNvcHlyaWdodCBub3RpY2Ugb3IgcmVm ZXJlbmNlcyB0byB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBvdGhlcgogICBJbnRlcm5ldCBvcmdh bml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZgogICBkZXZlbG9w aW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBjYXNlIHRoZSBwcm9jZWR1cmVzIGZvcgog ICBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBwcm9jZXNzIG11 c3QgYmUKICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxh bmd1YWdlcyBvdGhlciB0aGFuCiAgIEVuZ2xpc2guCgogICBUaGUgbGltaXRlZCBwZXJtaXNzaW9u cyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlCiAgIHJldm9rZWQg YnkgdGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzIHN1Y2Nlc3NvcnMgb3IgYXNzaWducy4KCiAg IFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIHBy b3ZpZGVkIG9uIGFuCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFO RCBUSEUgSU5URVJORVQgRU5HSU5FRVJJTkcKICAgVEFTSyBGT1JDRSBESVNDTEFJTVMgQUxMIFdB UlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwgSU5DTFVESU5HCiAgIEJVVCBOT1QgTElNSVRF RCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTgogICBIRVJF SU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVT IE9GCiAgIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RS4KCkFja25vd2xlZGdlbWVudAoKICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rp b24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQogICBJbnRlcm5ldCBTb2NpZXR5LgoKCgoK CgoKCgoKCgoKCgoKCgoKRmFsdHN0cm9tICYgTWVhbGxpbmcgICAgRXhwaXJlcyBOb3ZlbWJlciAz MCwgMjAwMiAgICAgICAgICAgICAgW1BhZ2UgMThdCgwKCg== --=====================_91419113==_-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Jul 7 15:57:23 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 PAA03203 for ; Sun, 7 Jul 2002 15:57:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21077 for enum-archive@odin.ietf.org; Sun, 7 Jul 2002 15:58: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 PAA20570; Sun, 7 Jul 2002 15:40:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13563 for ; Sun, 7 Jul 2002 12:34:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25397; Sun, 7 Jul 2002 12:33:10 -0400 (EDT) Message-Id: <200207071633.MAA25397@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: enum@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Sun, 07 Jul 2002 12:33:09 -0400 Subject: [Enum] I-D ACTION:draft-ietf-enum-rfc2916bis-01.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Telephone Number Mapping Working Group of the IETF. Title : The E.164 to URI DDDS Application Author(s) : P. Faltstrom, M. Mealling Filename : draft-ietf-enum-rfc2916bis-01.txt Pages : 18 Date : 05-Jul-02 This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC WWWW. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC WWWW. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-enum-rfc2916bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-enum-rfc2916bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020705142553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-enum-rfc2916bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-enum-rfc2916bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020705142553.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Sun Jul 7 17: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 RAA05770 for ; Sun, 7 Jul 2002 17:09:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24793 for enum-archive@odin.ietf.org; Sun, 7 Jul 2002 17:10: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 RAA24470; Sun, 7 Jul 2002 17:01: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 RAA24426 for ; Sun, 7 Jul 2002 17:01:26 -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 RAA05388 for ; Sun, 7 Jul 2002 17:00:33 -0400 (EDT) Received: from user-uivenkr.dsl.mindspring.com ([165.247.94.155] helo=dick.ix.netcom.com) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17RJ9l-0006WG-00 for enum@ietf.org; Sun, 07 Jul 2002 17:01:23 -0400 Message-Id: <5.1.0.14.2.20020707170418.03cd1008@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 07 Jul 2002 17:06:00 -0400 To: enum@ietf.org From: Internet-Drafts@ietf.org (by way of Richard Shockey ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] I-D ACTION:draft-ietf-vpim-routing-03.txt 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 FYI... we should pay close attention to drafts such as this when considering defining enumservice fields. We need to make sure we coordinate our actions with other relevant IETF WG's ########################## A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Voice Profile for Internet Mail Working Group of the IETF. Title : Voice Message Routing Service Author(s) : G. Vaudreuil Filename : draft-ietf-vpim-routing-03.txt Pages : 11 Date : 03-Jul-02 Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The VPIM Directory service provides a directory mechanism to lookup a VPIM email address with a telephone number and confirm that the address is both valid and the associated with the intended recipient. However this service will take time become widely deployed in the nearest term. This document also describes a more limited send-and-pray service useful simply to route and deliver messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilies. Please send comments on this document to the VPIM working group mailing list A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-vpim-routing-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-vpim-routing-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <20020703132620.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-vpim-routing-03.txt _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jul 8 13:39: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 NAA27171 for ; Mon, 8 Jul 2002 13:39:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07715 for enum-archive@odin.ietf.org; Mon, 8 Jul 2002 13:39: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 NAA06415; Mon, 8 Jul 2002 13:28: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 NAA06387 for ; Mon, 8 Jul 2002 13:28: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 NAA26543 for ; Mon, 8 Jul 2002 13:27:45 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g68HS6F18272 for ; Mon, 8 Jul 2002 13:28:06 -0400 Message-Id: <5.1.0.14.2.20020708132937.021bb548@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Jul 2002 13:34:50 -0400 To: enum@ietf.org From: Richard Shockey 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 NAA06388 Subject: [Enum] Propoals on ABNF syntax for discussion in Yokohama 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 Perhaps the core issue for Yokohama is coming to rough consensus on the ABNF syntax for the NAPTR enumservice field After reviewing previous mails I wanted to make sure we all understood the 2 options proposed. ABNF Syntax for enumservice – Faltstrom/Mealling service_field = "E2U" + 1*(“+” enumservice) enumservice = service [":" protocol] service = 1*32(ALPHA / DIGIT) [mandatory] protocol = 1*32(ALPHA / DIGIT) [optional] ABNF Syntax for enumservice – Brandner/Stastny/Conroy servicefield : "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] uri-scheme : "tel" | "mailto" | "sip" | "ldap" | ... etc etc [mandatory] enumservice : "voice" | "video" | "email" | "sms" | "talk" | "msg" | etc etc [optional] addinfo : "home" | "business" | "mobile" | etc etc [optional] other : Do I have this right ... I wanted to have some slides ready to illustrate the options? Additions Modifications etc? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Jul 8 14:27: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 OAA29976 for ; Mon, 8 Jul 2002 14:27:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10465 for enum-archive@odin.ietf.org; Mon, 8 Jul 2002 14:26:50 -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 OAA10086; Mon, 8 Jul 2002 14:17: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 OAA10049 for ; Mon, 8 Jul 2002 14:17:24 -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 OAA29224 for ; Mon, 8 Jul 2002 14:16:32 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g68IGrF19022 for ; Mon, 8 Jul 2002 14:16:53 -0400 Message-Id: <5.1.0.14.2.20020708135254.02311148@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Jul 2002 14:23:38 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Comments on 2916bis 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 couple of personal comments to Patrik and Mike here based on the draft. The ABNF Syntax for enumservice is defined in 2916bis as follows with examples from the text. service_field = "E2U" + 1*("+" enumservice) enumservice = service [":" protocol] service = 1*32(ALPHA / DIGIT) [mandatory] examples [presence, talk,message, sip??] protocol = 1*32(ALPHA / DIGIT) [optional] examples [ tel ,mailto, sip ] I'm still wondering if the order of service and protocol should be reversed along with a requirement that protocol be mandatory and service optional. in order to permit definition of a protocol without defining an service associated with it. My views on why this is useful are well known. I wish to permit users to define the _minimal_ set of information necessary to establish an connection if that is possible using protocols that have on the wire negotiation capabilities. Obviously this would be helpful for the example "E2U+SIP:[blank] consequently I would propose the following revision to the syntax with the addition of 'label'which might have uses of its own under certain circumstances as B/C/S have proposed service_field = "E2U" + 1*("+" enumservice) enumservice = service [":" protocol ":" label] protocol = 1*32(ALPHA / DIGIT) [mandatory] examples [smtp, sip, tel, h323, ldap, vpim ] service = 1*32(ALPHA / DIGIT) [optional] examples [ video, sms, presence, talk, voice, message, fax, mailto ] label = 1*32(ALPHA / DIGIT) [optional] examples [ home, office, mobile ] Before 3.1.1 I would add an requirement for Applicability Statement before a Functionality requirement..namely why is this particular registration important and what need does it serve also add to Registration Template. After 7. Privacy Statement ... I think we should make it clear that information in the global DNS is open to all and exposure of certain information contains risks. I'm thinking of text that may be appropriate here ... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Jul 8 14:32:06 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 OAA00374 for ; Mon, 8 Jul 2002 14:32:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11326 for enum-archive@odin.ietf.org; Mon, 8 Jul 2002 14:32: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 OAA10355; Mon, 8 Jul 2002 14:24: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 OAA10326 for ; Mon, 8 Jul 2002 14:23:58 -0400 (EDT) Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net [38.202.36.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29878 for ; Mon, 8 Jul 2002 14:23:05 -0400 (EDT) Received: from RWALTER ([65.203.166.26]) by hvmta02-stg.us.psimail.psi.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020708182352.BKEX1878.hvmta02-stg.us.psimail.psi.net@RWALTER>; Mon, 8 Jul 2002 14:23:52 -0400 Reply-To: From: "Robert H. Walter" To: "Richard Shockey" , Subject: RE: [Enum] Propoals on ABNF syntax for discussion in Yokohama Date: Mon, 8 Jul 2002 14:24:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <5.1.0.14.2.20020708132937.021bb548@popd.ix.netcom.com> 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 Richard, May I suggest that you drop the [mandatory]/[optional] commentary because: 1. The ABNF already illustrates this... 2. It may be confused with an optional ABNF production. Alternatively, use the ABNF comment ";" specifier to drive point home for those that are unfamilar with ABNF i.e. service_field = "E2U" + 1*(“+” enumservice) enumservice = service [":" protocol] service = 1*32(ALPHA / DIGIT) ; mandatory protocol = 1*32(ALPHA / DIGIT) ; optional Also the "other" production is not reference anywhere, so it should be eliminated i.e. servicefield : "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] uri-scheme : "tel" | "mailto" | "sip" | "ldap" ; mandatory enumservice : "voice" | "video" | "email" | "sms" | "talk" | "msg" ; optional addinfo : "home" | "business" | "mobile" ; optional Regards, Bob Walter NetNumber, Inc. > -----Original Message----- > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > Richard Shockey > Sent: Monday, July 08, 2002 1:35 PM > To: enum@ietf.org > Subject: [Enum] Propoals on ABNF syntax for discussion in Yokohama > > > > Perhaps the core issue for Yokohama is coming to rough consensus on the > ABNF syntax for the NAPTR enumservice field > > After reviewing previous mails I wanted to make sure we all understood the > 2 options proposed. > > > ABNF Syntax for enumservice > – Faltstrom/Mealling > > service_field = "E2U" + 1*(“+” enumservice) > enumservice = service [":" protocol] > service = 1*32(ALPHA / DIGIT) [mandatory] > protocol = 1*32(ALPHA / DIGIT) [optional] > > > ABNF Syntax for enumservice > – Brandner/Stastny/Conroy > > servicefield : "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] > uri-scheme : "tel" | "mailto" | "sip" | "ldap" | ... etc etc [mandatory] > enumservice : "voice" | "video" | "email" | "sms" | "talk" | "msg" | etc > etc [optional] > addinfo : "home" | "business" | "mobile" | etc etc [optional] > other : > > > Do I have this right ... I wanted to have some slides ready to illustrate > the options? > > Additions Modifications etc? > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jul 8 14:37: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 OAA00816 for ; Mon, 8 Jul 2002 14:37:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11592 for enum-archive@odin.ietf.org; Mon, 8 Jul 2002 14:38:50 -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 OAA10568; Mon, 8 Jul 2002 14:29: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 OAA10543 for ; Mon, 8 Jul 2002 14:29:42 -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 OAA00100 for ; Mon, 8 Jul 2002 14:28:50 -0400 (EDT) Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g68ISOH3016270; Mon, 8 Jul 2002 20:28:24 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 8 Jul 2002 20:29:10 +0200 Received: from [192.168.1.13] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 8 Jul 2002 20:29:09 +0200 Date: Mon, 08 Jul 2002 20:26:10 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Richard Shockey , enum@ietf.org Subject: Re: [Enum] Propoals on ABNF syntax for discussion in Yokohama Message-ID: <50847031.1026159970@localhost> In-Reply-To: <5.1.0.14.2.20020708132937.021bb548@popd.ix.netcom.com> References: <5.1.0.14.2.20020708132937.021bb548@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: 08 Jul 2002 18:29:10.0168 (UTC) FILETIME=[5A0B4180:01C226AD] 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-07-08 13.34 -0400 Richard Shockey wrote: > service_field = "E2U" + 1*(?+? enumservice) > enumservice = service [":" protocol] > service = 1*32(ALPHA / DIGIT) [mandatory] > protocol = 1*32(ALPHA / DIGIT) [optional] This should be: service_field = "E2U" + 1*("+" enumservice) enumservice = service [":" protocol] service = 1*32(ALPHA / DIGIT) protocol = 1*32(ALPHA / DIGIT) paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jul 8 15:01: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 PAA02935 for ; Mon, 8 Jul 2002 15:01:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14032 for enum-archive@odin.ietf.org; Mon, 8 Jul 2002 15:02: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 OAA12822; Mon, 8 Jul 2002 14:53: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 OAA12791 for ; Mon, 8 Jul 2002 14:53: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 OAA02112 for ; Mon, 8 Jul 2002 14:52:11 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g68IqVF19720; Mon, 8 Jul 2002 14:52:32 -0400 Message-Id: <5.1.0.14.2.20020708143449.023edec8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Jul 2002 14:59:04 -0400 To: , From: Richard Shockey Subject: RE: [Enum] Propoals on ABNF syntax for discussion in Yokohama In-Reply-To: References: <5.1.0.14.2.20020708132937.021bb548@popd.ix.netcom.com> 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 OAA12792 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 02:24 PM 7/8/2002 -0400, Robert H. Walter wrote: >Richard, > >May I suggest that you drop the [mandatory]/[optional] >commentary because: > >1. The ABNF already illustrates this... >2. It may be confused with an optional ABNF production. > >Alternatively, use the ABNF comment ";" specifier to drive >point home for those that are unfamilar with ABNF i.e. > > service_field = "E2U" + 1*(“+” enumservice) > enumservice = service [":" protocol] > service = 1*32(ALPHA / DIGIT) ; mandatory > protocol = 1*32(ALPHA / DIGIT) ; optional thanks my mistake .. but what do you think about reversing the order? IYHO is a 'label' function useful? >Also the "other" production is not reference anywhere, so >it should be eliminated i.e. > > servicefield : "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] > uri-scheme : "tel" | "mailto" | "sip" | "ldap" ; mandatory > enumservice : "voice" | "video" | "email" | "sms" | "talk" | "msg" ; > optional > addinfo : "home" | "business" | "mobile" ; optional Well yes this is not in a draft, but it was offered up by Rudolf on the list as a rough approximation of the position taken by him Larry and Richard in their drafts... I'll let them A/M/D as necessary ... >Regards, > >Bob Walter >NetNumber, Inc. > > > -----Original Message----- > > From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of > > Richard Shockey > > Sent: Monday, July 08, 2002 1:35 PM > > To: enum@ietf.org > > Subject: [Enum] Propoals on ABNF syntax for discussion in Yokohama > > > > > > > > Perhaps the core issue for Yokohama is coming to rough consensus on the > > ABNF syntax for the NAPTR enumservice field > > > > After reviewing previous mails I wanted to make sure we all understood the > > 2 options proposed. > > > > > > ABNF Syntax for enumservice > > ­ Faltstrom/Mealling > > > > service_field = "E2U" + 1*(“+” enumservice) > > enumservice = service [":" protocol] > > service = 1*32(ALPHA / DIGIT) [mandatory] > > protocol = 1*32(ALPHA / DIGIT) [optional] > > > > > > ABNF Syntax for enumservice > > ­ Brandner/Stastny/Conroy > > > > servicefield : "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] > > uri-scheme : "tel" | "mailto" | "sip" | "ldap" | ... etc etc [mandatory] > > enumservice : "voice" | "video" | "email" | "sms" | "talk" | "msg" | etc > > etc [optional] > > addinfo : "home" | "business" | "mobile" | etc etc [optional] > > other : > > > > > > Do I have this right ... I wanted to have some slides ready to illustrate > > the options? > > > > Additions Modifications etc? > > > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Jul 8 15:04: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 PAA03122 for ; Mon, 8 Jul 2002 15:04:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA14135 for enum-archive@odin.ietf.org; Mon, 8 Jul 2002 15:05: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 OAA13054; Mon, 8 Jul 2002 14:56: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 OAA13019 for ; Mon, 8 Jul 2002 14:56:16 -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 OAA02377 for ; Mon, 8 Jul 2002 14:55:23 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g68IsbN5018304; Mon, 8 Jul 2002 20:54:57 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 8 Jul 2002 19:55:23 +0100 Received: from [192.168.1.13] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 8 Jul 2002 20:53:35 +0200 Date: Mon, 08 Jul 2002 20:40:48 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: rwalter@netnumber.com, Richard Shockey , enum@ietf.org Subject: RE: [Enum] Propoals on ABNF syntax for discussion in Yokohama Message-ID: <50899706.1026160848@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: 08 Jul 2002 18:53:36.0124 (UTC) FILETIME=[C3D263C0:01C226B0] 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-07-08 14.24 -0400 "Robert H. Walter" wrote: > May I suggest that you drop the [mandatory]/[optional] > commentary because: > > 1. The ABNF already illustrates this... > 2. It may be confused with an optional ABNF production. It should not be there. The ABNF is clear enough. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jul 8 16:10: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 QAA06515 for ; Mon, 8 Jul 2002 16:10:50 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20448 for enum-archive@odin.ietf.org; Mon, 8 Jul 2002 16:11: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 QAA19739; Mon, 8 Jul 2002 16:01: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 QAA19708 for ; Mon, 8 Jul 2002 16:01:47 -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 QAA05827 for ; Mon, 8 Jul 2002 16:00:54 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g68K0aF21303; Mon, 8 Jul 2002 16:00:36 -0400 Message-Id: <5.1.0.14.2.20020708154917.04648498@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 08 Jul 2002 16:07:25 -0400 To: "Toyoda, Kiyoshi" From: Richard Shockey Subject: Re: [Enum] SchemaSet strawman Cc: , enum@ietf.org, ietf-fax@imc.org In-Reply-To: <200205280600.AA01259@d23n59.rdmg.mgcs.mei.co.jp> References: <5.1.0.14.2.20020527125808.021ed588@popd.ix.netcom.com> <5.1.0.14.2.20020527125808.021ed588@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 03:00 PM 5/28/2002 +0900, Toyoda, Kiyoshi wrote: >Shockey-san, > >I would like to propose ifax services of ENUM. I comment >below. > >R >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. Some how this got lost in my email shuffle but my comments are below.... If you have been following the ENUM list we are now discussing the syntax for expressing your requirements... I suggest looking at: Title : The E.164 to URI DDDS Application Author(s) : P. Faltstrom, M. Mealling Filename : draft-ietf-enum-rfc2916bis-01.txt Pages : 18 Date : 05-Jul-02 This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the document series specified in RFC WWWW. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC WWWW. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-rfc2916bis-01.txt It proposes a syntax in ABNF format ervice_field = "E2U" + 1*("+" enumservice) enumservice = service [":" protocol] service = 1*32(ALPHA / DIGIT) protocol = 1*32(ALPHA / DIGIT) BTW we are meeting on Tuesday to discuss this proposal and others and there is similar work going on in VPIM as well... A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Voice Profile for Internet Mail Working Group of the IETF. Title : Voice Message Routing Service Author(s) : G. Vaudreuil Filename : draft-ietf-vpim-routing-03.txt Pages : 11 Date : 03-Jul-02 Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The VPIM Directory service provides a directory mechanism to lookup a VPIM email address with a telephone number and confirm that the address is both valid and the associated with the intended recipient. However this service will take time become widely deployed in the nearest term. This document also describes a more limited send-and-pray service useful simply to route and deliver messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilies. Please send comments on this document to the VPIM working group mailing list A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-03.txt >------------------------------------------------------------------- >Network Working Group K. Toyoda, MGCS >Internet Draft > May 2002 >Expires: November 2002 > > > > IFAX service of ENUM I think the timing for this is now perfect with the establishment of a IANA registration procedure for the syntax in 2916bis. The comments of the FAX WG would be most appreciated. > > > > S > >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!" this looks right with the service being ifax and the protocol being mailto in the syntax proposed IN NAPTR 10 10 "u" "E2U+ifax:smtp" "!^.*$!mailto:paf@ifax.net!" but you can now specify a different transport method if you chose such as IN NAPTR 10 10 "u" "E2U+ifax:ipp" "!^.*$!ipp://username/ifax.net!" if you wish.... or IN NAPTR 10 10 "u" "E2U+ifax:T38" "!^.*$h323:user@faxserver.ifax.net!" as different examples. >2. >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 > > > >Kiyoshi Toyoda >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Jul 8 17:01: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 RAA09800 for ; Mon, 8 Jul 2002 17:01:54 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25488 for enum-archive@odin.ietf.org; Mon, 8 Jul 2002 17:02:47 -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 QAA23820; Mon, 8 Jul 2002 16:53: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 QAA23786 for ; Mon, 8 Jul 2002 16:53:46 -0400 (EDT) Received: from dorfl.roke.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08316 for ; Mon, 8 Jul 2002 16:52:52 -0400 (EDT) Received: from [193.118.205.14] (HELO [192.168.0.3]) by dorfl.roke.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000090936; Mon, 08 Jul 2002 21:52:43 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 Message-Id: In-Reply-To: <5.1.0.14.2.20020708143449.023edec8@popd.ix.netcom.com> References: <5.1.0.14.2.20020708132937.021bb548@popd.ix.netcom.com> <5.1.0.14.2.20020708143449.023edec8@popd.ix.netcom.com> Date: Mon, 8 Jul 2002 21:50:34 +0100 To: Richard Shockey From: Lawrence Conroy Subject: RE: [Enum] Propoals on ABNF syntax for discussion in Yokohama Cc: rwalter@netnumber.com, 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 QAA23787 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 Rich, Folks, Hmm... framed - me? I have said this before, but, in the words of a famous (U.K.) Liberal Politician, "One More Push" First off - Please note that the URI-scheme or protocol or whatever IS available, as Richard S pointed out ("just look to the left"). There seemed to be a strong view ->from others<- that this information should be available within the service field. Personally, I still think of this as a copy, but at this point a little duplication is acceptable. Thus, I acquiesce in this situation. Note this word - it's descriptive. ->IF<- we are going to have uri-scheme in the services field, then it is going to be a pain if implementors have to play "hunt the uri-scheme". Thus, the argument went, if it's going to be there, then please can it be the first element in the list. As the enumservices should be optional (as pointed out by Rich, for privacy reasons), first is better than last. However, as there is no URI-scheme in some NAPTRs (e.g. non-terminals), we could do with some way of indicating that it isn't there. Hence the proposal that it use a different delimiter from the enumservices. In this case, an implementation would be easy even if both enumservices and URI-scheme were independently included in some NAPTRs and not in others. Thus, I didn't want URI-scheme in there as it's only a duplicate, but if this keeps folks up at night we can copy it into the service field. I ->do<- want a service (i.e. an indication of the end user's communications interest). This is not generally available from the generated URI or any other information in the NAPTR. -------- Re. other - this seems to have been replaced by "etc, etc". Bizarre. BTW, I note that the production in 2916bis seems to have been restricted to 32 characters that are digits or alphabetics. Not quite the same as TOKEN. Finally, the enumservices shouldn't, IMHO, be enumerated explicitly in a "real" framework ABNF as they will be defined in an RFC. These were only ->examples<- of candidate enumservice labels. -------- Richard S proposed an add-info section to cover things like office/home/mobile labels. I have no idea whether or not these will be useful (that's what trials are for :), but *as long as we can find some sensible program and/or user behaviour for them* it can be added without breaking anything, IMHO. It has to be optional and I guess may not even be considered by some client implementations. The add-info syntax could be appended to either of the ABNFs you listed. --------- The new version of 2916bis explicitly excludes implicit definition of the "protocol" element, so we DON'T just have a copy of the uri-scheme. Losing that is fine by me as I never liked it anyway. The original tel enumservice draft was an attempt to define an enumservice using the then proposed service field structure - on reflection, it's very low level - IMHO, this was true for the sip draft as well, as what's really happening in that draft is 'SRS', using the protocol indicated in the generated URI-scheme (which is expected to be sip:). IMHO, with very slight re-writing/expansion, the sip-e164 draft looks a good candidate for the 'SRS' enumservice definition. There's little point in a re-write of the 'tel' draft until it's clear quite what it's supposed to say. So my only question is - "what's a 'protocol', how is it used, why on earth would one ever need more than one in any single NAPTR, and have we drifted beyond RFC2396 into specifying more behaviour that we can control"? BTW, for an entertaining read on the 'plane, look out 3GPP's TS23.140 on MMS. fetch from . BTW, this implies that the server supports the FTP protocol. Consider the architecture diagram therein - what protocol(s) exactly are we supposed to specify in the NAPTR, and how are we going to enforce this for the MMS enumservice? (Hint - section 7 covers interfaces MM1, MM2, MM3, MM4, MM5, MM6 and MM7). See y'all. In reply to comments from... At 2:59 pm -0400 8/7/02, Richard Shockey wrote: >At 02:24 PM 7/8/2002 -0400, Robert H. Walter wrote: >>Richard, >> >>May I suggest that you drop the [mandatory]/[optional] >>commentary because: >> >>1. The ABNF already illustrates this... >>2. It may be confused with an optional ABNF production. >> >>Alternatively, use the ABNF comment ";" specifier to drive >>point home for those that are unfamilar with ABNF i.e. >> >> service_field = "E2U" + 1*(“+” enumservice) >> enumservice = service [":" protocol] >> service = 1*32(ALPHA / DIGIT) ; mandatory >> protocol = 1*32(ALPHA / DIGIT) ; optional > >thanks my mistake .. but what do you think about reversing the order? > >IYHO is a 'label' function useful? > >>Also the "other" production is not reference anywhere, so >>it should be eliminated i.e. >> >> servicefield : "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] >> uri-scheme : "tel" | "mailto" | "sip" | "ldap" ; mandatory >> enumservice : "voice" | "video" | "email" | "sms" | "talk" | >>"msg" ; optional >> addinfo : "home" | "business" | "mobile" ; optional > > >Well yes this is not in a draft, but it was offered up by Rudolf on >the list as a rough approximation of the position taken by him >Larry and Richard in their drafts... I'll let them A/M/D as >necessary ... > >>Regards, >> >>Bob Walter >>NetNumber, Inc. >> >>> -----Original Message----- >>> From: enum-admin@ietf.org [mailto:enum-admin@ietf.org]On Behalf Of >>> Richard Shockey >>> Sent: Monday, July 08, 2002 1:35 PM >>> To: enum@ietf.org >>> Subject: [Enum] Propoals on ABNF syntax for discussion in Yokohama >>> >>> >>> >>> Perhaps the core issue for Yokohama is coming to rough consensus on the >>> ABNF syntax for the NAPTR enumservice field >>> >>> After reviewing previous mails I wanted to make sure we all understood the >>> 2 options proposed. >>> >>> >>> ABNF Syntax for enumservice >>> ­ Faltstrom/Mealling >>> >>> service_field = "E2U" + 1*(“+” enumservice) >>> enumservice = service [":" protocol] >>> service = 1*32(ALPHA / DIGIT) [mandatory] >>> protocol = 1*32(ALPHA / DIGIT) [optional] >>> >>> >>> ABNF Syntax for enumservice >>> ­ Brandner/Stastny/Conroy >>> >>> servicefield : "E2U" ("-" uri-scheme) *("+" enumservice) ["*" addinfo] >>> uri-scheme : "tel" | "mailto" | "sip" | "ldap" | ... etc etc [mandatory] >>> enumservice : "voice" | "video" | "email" | "sms" | "talk" | "msg" | etc >>> etc [optional] >>> addinfo : "home" | "business" | "mobile" | etc etc [optional] >>> other : >>> >>> >>> Do I have this right ... I wanted to have some slides ready to illustrate >>> the options? >>> >> > Additions Modifications etc? -- All the best, Lawrence ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : legal relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Jul 9 08:48: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 IAA22927 for ; Tue, 9 Jul 2002 08:48:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00531 for enum-archive@odin.ietf.org; Tue, 9 Jul 2002 08:49: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 IAA29937; Tue, 9 Jul 2002 08:38: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 IAA29860 for ; Tue, 9 Jul 2002 08:38: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 IAA22277 for ; Tue, 9 Jul 2002 08:37:23 -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 g69CcOc03677; Tue, 9 Jul 2002 12:38:24 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 17RuFy-000BVv-00 for enum@ietf.org; Tue, 09 Jul 2002 13:38:14 +0100 Date: Tue, 9 Jul 2002 13:38:14 +0100 From: "Clive D.W. Feather" To: enum@ietf.org Message-ID: <20020709123814.GA18137@demon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [Enum] Re: Propoals on ABNF syntax for discussion in Yokohama 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 writes: > Perhaps the core issue for Yokohama is coming to rough consensus on the > ABNF syntax for the NAPTR enumservice field I have to say that this is a classic case of putting the cart before the horse. *First* you need to decide what information you actually want to put in the enumservice field. Once you've done that, addressing syntax issues is fairly simple. A couple of weeks ago, Robert Walter wrote: > I reiterate that the purpose of the service field is to allow an > application to rapidly select NAPTR records that are meaningful > to its purpose and/or function. That, I would suggest, remains key. Okay, what I'm seeing people want is: (1) Service, though this isn't a particularly well-specified concept. (2) Protocol. (3) URI scheme. Are these two the same ? (4) Additional information. People also seem to have different views of what should be mandatory and which order things would come in. When I think through what I want to see in a NAPTR record, what I come up with is: (A) What kind of interactivity do I want ? - I am sending something for the recipient to study (email, voicemail); - I want information from the recipient (web site, public key); - I want to interact with the recipient (phone, chat). (B) What type of material do I want to send ? - text - text and graphics - voice - video - application-specific data (C) What "situation" of the recipient do I want ? - work - home - urgent, wherever she is - when she's got time In some sense all of these are "service". I don't particularly care about the URI scheme, because that will be in the resulting URI. I don't think I care about "protocol", because that's up to my software and it depends on the URI as well. I *can* see the advantage of additional data. One other note to make is that the indirections available in the system mean that the eventual URI can vary enormously even without changing the NAPTR record. So any description system has to allow for alternatives. ---- Putting all this together, and adding some other thoughts that I haven't expressed here but are based on previous discussions, let me try to come up with some semantic proposals. (1) The enumservice field should provide information to allow the user (or, more precisely, the application software) to know whether or not it's worth expanding the NAPTR record to find the resulting URI. (2) The field should be able to hold one or more descriptions which are alternatives. If the user "likes" any of the descriptions, it is worth expanding the NAPTR record. The case of no descriptions is useful: it means that things are too complicated to just describe here. (3) Each description consists of a number of components. The NAPTR record is only "interesting" if all the components match the user's requirements. (4) There is no consensus on the relative importance of the components. nor which are essential. This says to me that *all* the components should be optional, with an omitted component meaning "always interesting". (5) The ordering of the components is not intrinsically important. It can be left for second-order or syntactic considerations. (6) Therefore the obvious way to distinguish the different sorts of component is to use different delimiters. This produces the following top-level syntax: service-field = "E2U" *("|" description) description = 1*(component) component = delimiter value Note: I've used | rather than + because RFC 2396 allows - and + in URI scheme names. Therefore these are bad characters to use as delimiters. If people really want "E2U+", then the correct syntax is: service-field = "E2U" [ "+" description *( "|" description )] Now we can look at the specific components: * Service. This wants to be one of a list of registered names. The name indicates the format and type of data being transferred. * Interactiveness. I think this is a useful concept, over and above service. That is, rather than having "voice" and "voicemail" as separate services, let them be "voice-chat" and "voice-send". Except that, since there are only three cases, we can use single characters to indicate them. * Situation. This would also be a list of registered names, just so that software had an idea of what they mean. * URI scheme. * Protocol. If this is actually useful, separate from URI scheme, then once again, it is a list of registered names. * Additional information. This is the one thing that is unstructured, since it's essentially a comment. However, I would be loath to claim that that's all we're ever going to want, and some attempts to construct examples make me wonder whether more will be needed. My inclination is therefore to combine service, situation, and protocol into a single concept of "property", which is something that is defined and can be tested for. When it comes to the ordering of components, I can see the following points. (7) There are benefits to forcing a standard order, though they are relatively minor. (8) If two descriptions differ in only one or two components, it seems silly to repeat the whole thing. So some kind of "factoring" would be useful. In particular, there's going to be a certain amount of use for things like "voice at work or voicemail at home". But we don't want anything that will require major parsing effort. Okay, let me try to put all this into a formal proposal for text. ======== Syntax: service-field = "E2U" [ "+" alternative *( "|" alternative )] alternative = property-set *uri / 1*uri property-set = property-list *("/" property-list) property-list = direction / [direction] property *("," property) direction = d-get [d-send][d-talk] / d-send [d-talk] / d-talk d-get = "<" d-send = ">" d-talk = "#" property = name uri = ":" URI-scheme URI-scheme = name name = 1*32n-char ; names beginning "x-" are reserved ; for experimentation; all others must ; be registered n-char = ALPHA / DIGIT / "+" / "-" / "." comment = "(" *(c-char / comment) ")" c-char = Note: the non-terminal "comment" does not appear in the grammar, but it is the intent that it may appear anywhere after the initial "+" except within a "name". This requires scanners to ignore delimiters within parentheses; if this is a problem, alternative approaches can be developed, so please don't see it as a show-stopper. Semantics of service-field: The service-field states that, when the NAPTR record is expanded, it will result in a URI that is described by one of the alternatives (which one is not stated and may vary; it might be described by more than one). The "/" notation is a way to abbreviate alternatives that have the same URI-schemes. That is: >home,urgent/>#work:tel is the same as: >home,urgent:tel|>#work:tel and might describe a telephone number that can be used to call the recipient at work, or to leave messages either at work or (if urgent) at home. A "basic alternative" is one that has no "/" delimiters. It says that: - the URI can be used for the direction(s) specified (with none being the same as all); - if one or more URI-schemes are specified, the URI will use one of them; - the URI will have all the properties specified. Semantics of directions: < the URI is intended for use in obtaining data from a server without human interaction at the recipient's end (e.g. an HTTP: URL). > the URI is intended for use in sending an item of data to the recipient without immediate response (e.g. a mailto: URL). # the URI is intended for use in real-time interaction with both parties (e.g. a telephone call). Semantics of properties: Properties form a namespace which IANA is requested to maintain. Values beginning with "x-" are for experimentation and MUST NOT be registered. Other values can be registered by IANA as a result of this specification or by being defined in another RFC. This specification registers the following properties: voice - the URI is for voice communications (telephone, voice mail, recorded information services) text - the URI is for text services (email, chat) video - the URI is for video services pubkey - this URI should be used for obtaining a public key business - the URI is associated with business rather than home home - the URI is associated with home rather than business mobile - the URI is for a communications device that travels with the recipient fixed - the URI is for a communications device which can only be used when the recipient is present remote - the URI is for a "fixed" communications device which the recipient can nevertheless sometimes access from other locations urgent - this URI should be used when the matter is urgent deferred - this URI should be used where an indefinite delay will not cause problems. ======== -- 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 Jul 11 13:05: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 NAA25888 for ; Thu, 11 Jul 2002 13:05:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA29329 for enum-archive@odin.ietf.org; Thu, 11 Jul 2002 13:06: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 MAA27270; Thu, 11 Jul 2002 12:53: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 MAA27225 for ; Thu, 11 Jul 2002 12:53:42 -0400 (EDT) Received: from mail.oefeg.at ([62.47.121.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25246 for ; Thu, 11 Jul 2002 12:52:47 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Thu, 11 Jul 2002 18:54:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <06CF906FE3998C4E944213062009F16202470B@oefeg-s02.oefeg.loc> Thread-Topic: Protocol in enum service? Thread-Index: AcIo+7ERoLERkbSrRRav2679ZUUubA== From: "Stastny Richard" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id MAA27226 Subject: [Enum] Protocol in enum service? 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 folks, sorry, I could not really participate in the discussion, because I was on vacation and had only limited Internet access. In the new rfc2916bis-01 draft I am somewhat confused with the term protocol. Is this now the URI-scheme or the protocol? In the examples, again mailto is used, in this case as protocol. I have learned from the previous discussions, that this is no protocol, because this may be smtp. IMHO this term should be named URI-scheme and a protocol should never be in the enumservice, because the recepient never knows the protocol the originator will use with the URI-scheme. What kind of protocol should be given e.g. with the tel-URI? DSS1, SS7, h323? In most cases not even the recipient will know. best regards from Cordoba (Spain) Richard Stastny _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Fri Jul 12 04:45:52 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 EAA11722 for ; Fri, 12 Jul 2002 04:45:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA01644 for enum-archive@odin.ietf.org; Fri, 12 Jul 2002 04:46: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 EAA00807; Fri, 12 Jul 2002 04:35: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 EAA00776 for ; Fri, 12 Jul 2002 04:35: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 EAA11295 for ; Fri, 12 Jul 2002 04:34:27 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6C8XxoK000612; Fri, 12 Jul 2002 10:34:03 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 12 Jul 2002 09:33:57 +0100 Received: from [192.168.1.13] ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 12 Jul 2002 10:33:56 +0200 Date: Fri, 12 Jul 2002 09:58:20 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Stastny Richard , enum@ietf.org Subject: Re: [Enum] Protocol in enum service? Message-ID: <8220244.1026467900@localhost> In-Reply-To: <06CF906FE3998C4E944213062009F16202470B@oefeg-s02.oefeg.loc> References: <06CF906FE3998C4E944213062009F16202470B@oefeg-s02.oefeg.loc> 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: 12 Jul 2002 08:33:56.0859 (UTC) FILETIME=[DCE7C4B0:01C2297E] 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-07-11 18.54 +0200 Stastny Richard wrote: > In the new rfc2916bis-01 draft I am somewhat confused with the term > protocol. Is this now the URI-scheme or the protocol? In the examples, > again mailto is used, in this case as protocol. I have learned from the > previous discussions, that this is no protocol, because this may be smtp. > > IMHO this term should be named URI-scheme and a protocol should never be > in the enumservice, because the recepient never knows the protocol the > originator will use with the URI-scheme. I thought I was clear stating that both the term "protocol" and "service" have absolutely no meaning if one does not read carefully the registration document (an RFC) for the protocol and service in question. That is where the string is defined. paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jul 15 00:21:22 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 AAA29883 for ; Mon, 15 Jul 2002 00:21:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA16830 for enum-archive@odin.ietf.org; Mon, 15 Jul 2002 00:22: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 AAA16383; Mon, 15 Jul 2002 00:11: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 AAA16352 for ; Mon, 15 Jul 2002 00:11:30 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29609 for ; Mon, 15 Jul 2002 00:10:33 -0400 (EDT) Received: from co7010exch003u.wins.lucent.com (h135-39-1-23.lucent.com [135.39.1.23]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6F4Aww06720 for ; Mon, 15 Jul 2002 00:10:58 -0400 (EDT) Received: by co7010exch003u.milehi.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 14 Jul 2002 22:10:58 -0600 Message-ID: From: "Vaudreuil, Greg M (Greg)" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , enum@ietf.org Date: Sun, 14 Jul 2002 22:10:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Enum] Subaddressing in 2916bis 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 would like to see a small addition / Clarification in section 2.1. The fully qualified number for the purposes of ENUM may include E.164 ISDN subaddressing information, extension number, or a submailbox number. Because these digits are essential to initiate a communication to the intended recipient, it makes sense to include these digits in the application unique string. Section 2.1 should explicitly indicate these cases. An immediate example may help. VPIM explicitly supports the concept of sending a message to a mailbox identified uniquely by the E.164 telephone number plus a extension number. The VPIM defined form of the number is +12148239325+3 for submailbox three. The AUS would thus be +121482393253. I will submit a document providing greater context and examples after this IETF week. Greg V. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jul 15 01:33: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 BAA02138 for ; Mon, 15 Jul 2002 01:33:06 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28261 for enum-archive@odin.ietf.org; Mon, 15 Jul 2002 01:34: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 BAA27424; Mon, 15 Jul 2002 01:22: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 BAA27392 for ; Mon, 15 Jul 2002 01:22:08 -0400 (EDT) Received: from elettra.trieste.it (SYNX02.elettra.trieste.it [140.105.2.2]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01809 for ; Mon, 15 Jul 2002 01:21:10 -0400 (EDT) Date: Mon, 15 Jul 2002 07:21:59 +0100 To: enum@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="--Next_Part(Mon_Jul_15_10:43:13_2002_955)--" Content-ID: From: Claudio Allocchio Subject: [Enum] Toyoda-san's slides (ENUM) 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. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ----Next_Part(Mon_Jul_15_10:43:13_2002_955)-- Content-Type: TEXT/PLAIN; charset=US-ASCII ... here are the slides of the "to be" ID enum-faxservice-00.txt ID will follow as soon as published :-) ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Project Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://security.fi.infn.it/cgi-bin/spgpk.pl?KeyId=0C5C2A09 ----Next_Part(Mon_Jul_15_10:43:13_2002_955)-- Content-Type: APPLICATION/VND.MS-POWERPOINT Content-ID: Content-Transfer-Encoding: BASE64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAAAAAA EAAAEAAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////GAAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAD+/////v///xIAAAATAAAAFAAAABUAAAAWAAAAFwAAAP7////+//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAACCAZfyfK8IB EQAAAIANAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAzBoAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACACgAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAAAGACAAAAAAAADwDo A/gLAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPID rgEAAC8AyA8MAAAAMADSDwQAAAABAAAADwDVB+QAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAAhDW4ABTZYgD82GIA7KAHMAgAAAAAAAAAFNliAFdvDTAAAAQAEAC3D0QA AAAt/zP/IAAw/7QwtzDDMK8wAAAgAFIAbwBtAGEAbgAAAIQ1uAAU2WIA/NhiAOygBzAIAAAAAAAA ABTZYgBXbw0wgAAEMiAAtw9EAAAALf8z/yAAMP8OZh1nAACvMAAAIABSAG8AbQBhAG4AAACENbgA FNliAPzYYgDsoAcwCAAAAAAAAAAU2WIAV28NMIAABBIAAKQPCgAAAIAAYACAAAEAAAAAAKUPDAAA AAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIAEQQJBEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAA AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wCAAAAAAQAAAP//GAAAAAABAAAABQAAIAEgAQAAAAAA BQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEnAAAAA8AAPCUAAAAAAAG8EgA AAACIAAACAAAAA8AAAAEAAAAAQAAAAcAAAACAAAABAAAAAQAAAAFAAAAAwAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAgAAAAQAAABjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAEC AgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAACAAAAAAAAAAAAAAAA AACAAAAAAA8A0Ad7AQAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAA8A+gNnAAAAAAD+AwMA AAAAAQAAAP0DNAAAAEAAAABkAAAAQAAAAGQAAADsoAcwCAAAAAAAAAAI2WIAAAAAAAAAAACm//// QP///wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8ACAQ8AAAAAAD9AzQAAABC AAAAZAAAAEIAAABkAAAArn8NMMTcYgAAAAAAcDa4AAAAAAAAAAAAAAAAAAAAAAAAAGIAHwAUBBwA AAAAABUEFAAAALoddewAypo7Mk7NyQDKmjsBAQABHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAA AGQAAAA02WIA0IENMCDZYgAUAAAAAAAAAAAAAAAAAAAAAAAAAAABYgAfABMEPAAAAAAA/QM0AAAA ZAAAAGQAAABkAAAAZAAAADTZYgDQgQ0wINliABQAAAAAAAAAAAAAAAAAAAAAAAAAAAFiAD8A2Q8M AAAAAADaDwQAAAAAACUADwDwD6MHAAAAAPMDFAAAAAMAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQA AAAAAAAAAACoDxQAAABJRkFYIFNlcnZpY2Ugb2YgRU5VTRAAnw8EAAAAAQAAAAAAqA+pAAAAT2Jq ZWN0aXZlDVJlZ2lzdGVyaW5nIElGQVggc2VydmljZSBvZiBFTlVNIHdpdGggSUFOQQ1GdW5jdGlv bmFsIFNwZWNpZmljYXRpb24gb2YgSUZBWCBzZXJ2aWNlIGlzIGRpZmZlcmVudCBmcm9tIGVtYWls IHNlcnZpY2UsIFBTVE4tZmF4IHNlcnZpY2UgYW5kIFQuMzggZmF4IHNlcnZpY2UuDQ0NDQAAoQ82 AAAACgAAAAAAAAAAAJ4AAAABAAAAAAACAAAAAAAAAAAACgAAAAAAAACeAAAAAAAAAAIAAAAAAAAA AADzAxQAAAAFAAAAAAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8YAAAARnVuY3Rpb25h bCBTcGVjaWZpY2F0aW9uAAChDxQAAAAZAAAAAAAAAAAAGQAAAAAAAgAgABAAnw8EAAAAAQAAAAAA oA8QAgAARABTAE4AIABxAHUAZQByAHkAIAANAHcAaQB0AGgAIAB0AGgAZQAgAHQAYQByAGcAZQB0 ACAAIABzAHkAcwB0AGUAbQAZIHMAIAAgAHQAZQBsAGUAcABoAG8AbgBlACAAbgB1AG0AYgBlAHIA DQBSAGUAdAB1AHIAbgBlAGQAIAAgAE4AQQBQAFQAUgAgAHIAZQBjAG8AcgBkACAADQBzAHAAZQBj AGkAZgBpAGUAcwAgAGEAbgAgAGUAbQBhAGkAbAAgAGEAZABkAHIAZQBzAHMAIAB0AGgAYQB0ACAA aQBzACAAdABvACAAYgBlACAAdQBzAGUAZAAgAGYAbwByACAAcgBlAGEAYwBoAGkAbgBnACAAdABo AGUAIAB0AGEAcgBnAGUAdAAgAHMAeQBzAHQAZQBtACAADQBUAGgAZQAgAGUAbQBhAGkAbAAgAGEA ZABkAHIAZQBzAHMAIABpAHMAIAB0AGgAZQBuACAAdQBzAGUAZAAgAA0AaQBuACAAYQBjAGMAbwBy AGQAYQBuAGMAZQAgAHcAaQB0AGgAIAAcIFMAaQBtAHAAbABlACAATQBvAGQAZQAdICAAUgBGAEMA MgAzADAANQAsACAAHCBFAHgAdABlAG4AZABlAGQAIABNAG8AZABlAB0gIABSAEYAQwAyADUAMwAy ACAAbwByACAARgBGAFAASQBNAC4AAAChD3QAAAALAAAAAAAAAAAALAAAAAEAAAAAABgAAAAAAAAA AABOAAAAAQAAAAAAIAAAAAAAAAAAAEwAAAABAAAAAAALAAAAAAAAACwAAAAAAAAAGAAAAAAEAACA BE4AAAAABAAAgAQgAAAAAAgAAIAITAAAAAAMAACADAAA8wMUAAAABAAAAAAAAAACAAAAAQEAAAAA AAAAAJ8PBAAAAAAAAAAAAKgPGgAAAERlZmluaXRpb24gb2YgTkFQVFIgcmVjb3JkEACfDwQAAAAB AAAAAACgD+oBAABTAGUAcgB2AGkAYwBlACAATgBhAG0AZQAgACAAIAAgABwgaQBmAGEAeAAdIA0A UAByAG8AdABvAGMAbwBsACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIABzAG0AdABwAA0AVQBS AEkAIABzAGMAaABlAG0AZQAgACAAIAAgACAAIAAgABwgbQBhAGkAbAB0AG8AHSANAEkAbgB0AGUA bgBkAGUAZAAgAFUAcwBhAGcAZQAgACAAIAAgACAAQwBPAE0ATQBPAE4ADQBFAHgAYQBtAHAAbABl AA0AIAAkAE8AUgBJAEcASQBOACAANAAuADMALgAyAC4AMQAuADYALgA3AC4AOQAuADgALgA2AC4A NAAgAGUAMQA2ADQALgBhAHIAcABhAA0ASQBOACAATgBBAFAAVABSACAAMQAwACAAMQAwACAAHCB1 AB0gIAAcIEUAMgBVACsAaQBmAGEAeAA6AHMAbQB0AHAAHSAgAA0AIAAgACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAcICEAXgAuACoAJAAhAG0AYQBp AGwAdABvADoAdABvAHkAbwBAAGkAZgBhAHgALgBuAGUAdAAhAB0gDQAgACAAAAChD3AAAABuAAAA AAAAAAAAJwAAAAAAAQAAAAAAYQAAAAEAAQAAAAAATAAAAAAAAAATAAAAAAACABwABwAAAAAAAAAI AAAAAAACABwAJwAAAAAEAACABF0AAAAACAAAgAgBAAAAAAgCAIAIGAADAAAAAAgAAIAIAACqD5gA AAARAAAAAAAAAAQAAAABAAAAAQAYAAAAAAAAAAQAAAABAAAAAQANAAAAAAAAAAIAAAABAAAAAABQ AAAAAAAAAAQAAAABAAAAAQAZAAAAAAAAAAQAAAABAAAAAQABAAAAAAAAAAQAAAABAAAAAQAtAAAA AAAAAAQAAAABAAAAAQABAAAAAAAAAAQAAAABAAAAAQAKAAAAAAAAAAAA6gMAAAAADwD4A+AIAAAC AO8DGAAAAAEAAAABAgcJCAAAAAAAAAAAAAAAAAAAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAADM mQAzM8wAzMz/ALKysgBgAPAHIAAAAAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYAYADw ByAAAAD//8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA////AAAAAAAzMzMA AAAAAN3d3QCAgIAATU1NAOrq6gBgAPAHIAAAAP///wAAAAAAgICAAAAAAAD/zGYAAAD/AMwAzADA wMAAYADwByAAAAD///8AAAAAAICAgAAAAAAAwMDAAABm/wD/AAAAAJkAAGAA8AcgAAAA////AAAA AACAgIAAAAAAADOZ/wCZ/8wAzADMALKysgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEAZAAA AAAAAAAAAEACAAAAAAcAAAD//+8AgAAAAAEAAAD//ywAAAAAAwAAEACjD3wAAAAFAP/9PwABACIg AABkAAAAAAAAAGQAFAAAANgAAABAAgAAAAAHAAAA///vAIAAAAABAAAA//8gAAAAAAEAAIAFAAAT INQBIAEAAAIAHACABQAAIiDQAkACAAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAA IACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAAHAAAA///vAIAAAAAC AAAA//8MAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAE AAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBA AgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAA cACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgAS AAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIA EgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwEKgUAAA8AAvAiBQAAEAAI8AgAAAAGAAAABgQA AA8AA/C6BAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAA DwAE8M4AAAASAArwCAAAAAIEAAAACgAAkwAL8DYAAAB/AAEAAQCAAGhquACHAAEAAACBAQQAAAiD AQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMML CAAAAAAAAAABALgADwAN8FAAAAAAAJ8PBAAAAAAAAAAAAKAPHAAAAN4wuTC/MPwwIAC/MKQwyDDr MG4w+GYPXy2KmlsAAKIPBgAAAA8AAAAAAAAAqg8KAAAADwAAAAEAAAAAAA8ABPAgAQAAEgAK8AgA AAADBAAAAAoAAIMAC/AwAAAAfwABAAEAgABgbbgAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEB AAkAAQICAAAIAAAQ8AgAAADgBLAB0BQADw8AEfAQAAAAAADDCwgAAAABAAAAAgC4AA8ADfCoAAAA AACfDwQAAAABAAAAAACgD1wAAADeMLkwvzD8MCAAxjCtMLkwyDBuMPhmD18tippbDQAseyAAMgAg AOww2TDrMA0ALHsgADMAIADsMNkw6zANACx7IAA0ACAA7DDZMOswDQAseyAANQAgAOww2TDrMAAA og8eAAAADwAAAAAACAAAAAEACAAAAAIACAAAAAMACAAAAAQAAACqDwoAAAAvAAAAAQAAAAAADwAE 8NAAAAASAArwCAAAAAQEAAAACgAAgwAL8DAAAAB/AAEAAQCAACxxuACBAQQAAAiDAQAAAAi/AQEA EQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPsAFgBoAQDwAR8BAAAAAAAMMLCAAAAAIAAAAH AbgADwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAA AgAOAAAA+A8EAAAAAAAAAAAAqg8SAAAAAQAAAAEAAAAAAAEAAAAAAAAADwAE8NIAAAASAArwCAAA AAUEAAAACgAAgwAL8DAAAAB/AAEAAQCAAPhyuACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEA CQABAgIAAAgAABDwCAAAAGAPsAfQDoAQDwAR8BAAAAAAAMMLCAAAAAMAAAAJArgADwAN8FoAAAAA AJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAQACAAAAAAACAA4AAAD6DwQA AAAAAAAAAACqDxIAAAABAAAAAQAAAAAAAQAAAAAAAAAPAATw0gAAABIACvAIAAAABgQAAAAKAACD AAvwMAAAAH8AAQABAIAABHq4AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAA EPAIAAAAYA8gENAUgBAPABHwEAAAAAAAwwsIAAAABAAAAAgCuAAPAA3wWgAAAAAAnw8EAAAABAAA AAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADgAAANgPBAAAAAAAAAAAAKoP EgAAAAEAAAABAAAAAAABAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyACAAug8MAAAAGWqWbscwtjCkMPMwDwDuA9gBAAAC AO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAAAA8ADASIAQAADwAC8IABAAAgAAjwCAAAAAMA AAADCAAADwAD8BgBAAAPAATwKAAAAAEACfAQAAAAjwEAAACAAACQAQAAAIAAAAIACvAIAAAAAAgA AAUAAAAPAATwbAAAABIACvAIAAAAAggAACACAABDAAvwGAAAAIAAFMO4AL8BAAABAP8BAAABAAED AgQAAAAAEPAIAAAAgAGwAdAUUAQPABHwEAAAAAAAwwsIAAAAAAAAAA0AuAAPAA3wDAAAAAAAng8E AAAAAAAAAA8ABPBsAAAAEgAK8AgAAAADCAAAIAIAAEMAC/AYAAAAgADQw7gAvwEAAAEA/wEAAAEA AQMDBAAAAAAQ8AgAAADgBLAB0BQADw8AEfAQAAAAAADDCwgAAAABAAAADgC4AA8ADfAMAAAAAACe DwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEIAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6f iwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAA zJkAMzPMAMzM/wCysrIADwDuA9gBAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAAAA8A DASIAQAADwAC8IABAAAwAAjwCAAAAAMAAAADEAAADwAD8BgBAAAPAATwKAAAAAEACfAQAAAAgICA AAAAAAAAzJkAMzPMAAIACvAIAAAAABAAAAUAAAAPAATwbAAAABIACvAIAAAAAhAAACACAABDAAvw GAAAAIAABEX0AL8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAwACwAdAUkAMPABHwEAAAAAAAwwsI AAAAAAAAAA0A9AAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBsAAAAEgAK8AgAAAADEAAAIAIAAEMA C/AYAAAAgADARfQAvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADAA7AB0BTwDw8AEfAQAAAAAADD CwgAAAABAAAADgD0AA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAEQAAAADAAA gwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQ APAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwDuA9gBAAACAO8DGAAAAAEA AAANDgAAAAAAAAAAAIAAAAAABwAAAA8ADASIAQAADwAC8IABAABAAAjwCAAAAAMAAAAEDAAADwAD 8BgBAAAPAATwKAAAAAEACfAQAAAAAAAAAMADAADQAgAAAAAAAAIACvAIAAAAAAwAAAUAAAAPAATw bAAAABIACvAIAAAAAgwAACACAABDAAvwGAAAAIAAnFH0AL8BAAABAP8BAAABAAEDAgQAAAAAEPAI AAAAAACwAdAU0AIPABHwEAAAAAAAwwsIAAAAAAAAAA0A9AAPAA3wDAAAAAAAng8EAAAAAAAAAA8A BPBsAAAAEgAK8AgAAAADDAAAIAIAAEMAC/AYAAAAgABYUvQAvwEAAAEA/wEAAAEAAQMDBAAAAAAQ 8AgAAADAA7AB0BTQDg8AEfAQAAAAAADDCwgAAAABAAAADgD0AA8ADfAMAAAAAACeDwQAAAABAAAA DwAE8EgAAAASAArwCAAAAAEMAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM /wCysrIAAAByFxgAAAABAFAAAAAAAAAMAADoFAAAqBgAAMgWAAAAAPUPHAAAAAEBAADtDgADAAAA AIgaAAABAAAACAAAAAEA978AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAF AAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMA AAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAA ACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA/v///ysAAAAsAAAALQAAAC4AAAAvAAAA MAAAADEAAAAyAAAAMwAAAP7///81AAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////v8AAAQKAgAAAAAAAAAAAAAA AAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAUAoAAAwAAAABAAAAaAAAAAIAAABwAAAABAAA AJgAAAAIAAAAqAAAAAkAAADAAAAAEgAAAMwAAAAKAAAA7AAAAAsAAAD4AAAADAAAAAQBAAANAAAA EAEAAA8AAAAcAQAAEQAAACQBAAACAAAApAMAAB4AAAAfAAAAUmV2aXNlZCBJdGVtcyBvZiBTZXJ2 aWNlLXYyLTAyAAAeAAAABwAAAHRveW9kYQAgHgAAAA8AAABIaXJvc2hpIFRhbXVyYQBmHgAAAAMA AAAxOABvHgAAABUAAABNaWNyb3NvZnQgUG93ZXJQb2ludABpY2VAAAAAAOGZsysAAABAAAAAYAvi 9IPwvwFAAAAAIDunf3HwvwFAAAAAIBZN/J8rwgEDAAAAawAAAEcAAAAkCQAA/////wMAAAAIAIkQ ZwwAAAEACQAAA4oEAAAGAEkAAAAAABEAAAAmBg8AGAD/////AAAQAAAAAAAAAAAAwAMAANACAAAJ AAAAJgYPAAgA/////wIAAAAXAAAAJgYPACMA/////wQAGwBUTlBQFACgALgAMgAAAP//TwAUAAAA TQBpAAAACgAAACYGDwAKAFROUFAAAAIA9AMJAAAAJgYPAAgA/////wMAAAAPAAAAJgYPABQAVE5Q UAQADAABAAAAAQAAAAAAAAAFAAAACwIAAAAABQAAAAwC0ALAAwQAAAAEAQ0ABwAAAPwCAAD///8A AAAEAAAALQEAAAkAAAD6AgUAAAAAAP///wAiAAQAAAAtAQEABAAAAC0BAAAJAAAAHQYhAPAA0ALA AwAAAAAEAAAALQEAAAQAAAAtAQAACQAAAPoCAAAAAAAAAAAAACIABAAAAC0BAgAQAAAAJgYPABYA /////wAARwAAAI8CAAARAQAAwQIAAAgAAAAmBg8ABgD/////AQANAAAA+wIAAAAAAAAAAAAAAAAA AQAAAAAAAAQAAAAtAQMABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAAAgECABAAAAAmBg8AFgD///// AABHAQAAjwIAAHkCAADBAgAACAAAACYGDwAGAP////8BAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAA AAIBAgAHAAAA/AIBAAAAAAAAAAQAAAAtAQQABAAAAC0BAQAHAAAAGwS5AHkDQABIAAQAAAAtAQAA BAAAAC0BAgAFAAAACQIAAAACBQAAABQCAAAAABUAAAD7AsX/AAAAAAAAkAEAAAAAAEAAAFRpbWVz IE5ldyBSb21hbgAAAAQAAAAtAQUABAAAAPABAwAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgA BAAAAAIBAQAlAAAAMgqRAL8AFAAAAElGQVggU2VydmljZSBvZiBFTlVNFAAfACsAKgAPACEAGgAU AB0AEAAaABoADwAdABMADwAkACsAKwA0AAQAAAAuAQEABAAAAAIBAgAEAAAAAgECAAQAAAAtAQQA BAAAAC0BAQAHAAAAGwSBAnkD0ABIAAQAAAAtAQAABAAAAC0BAgAFAAAACQIAAAACBQAAABQCAAAA ABUAAAD7AtX/AAAAAAAAkAEAAAAAAEAAAFRpbWVzIE5ldyBSb21hbgAAAAQAAAAtAQMABAAAAPAB BQAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAJAAAAMgr+AFIAAQAAAJUADwAE AAAALgEBAAQAAAACAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAFQAAADIK /gB2AAkAAABPYmplY3RpdmUAHwAWAAwAEgASAAwADAAWABIABAAAAC4BAQAEAAAAAgECABUAAAD7 Atv/AAAAAAAAkAEAAAAAAEAAAFRpbWVzIE5ldyBSb21hbgAAAAQAAAAtAQUABAAAAPABAwAFAAAA CQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAJAAAAMgo1AYIAAQAAAJYAEwAEAAAALgEB AAQAAAACAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAQAAAADIKNQGgACYA AABSZWdpc3RlcmluZyBJRkFYIHNlcnZpY2Ugb2YgRU5VTSB3aXRoIBkAEAATAAoADgALABAADQAJ ABQAEgAKAAwAFQAaABwACQAPABAADQATAAoAEAARAAkAEwAMAAkAFwAbABsAIQAJABwACgAKABMA CgAEAAAALgEBAAQAAAACAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEADQAA ADIKYgGgAAQAAABJQU5BDAAaABwAGgAEAAAALgEBAAQAAAACAQIABQAAAAkCAAAAAgUAAAAUAgAA AAAEAAAALgEYAAQAAAACAQEACQAAADIKmAGCAAEAAACWABMABAAAAC4BAQAEAAAAAgECAAUAAAAJ AgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAEkAAAAyCpgBoAAsAAAARnVuY3Rpb25hbCBT cGVjaWZpY2F0aW9uIG9mIElGQVggc2VydmljZSBpcyATABMAFAAQAAsACgASABMAEQAKAAoAFAAT ABAAEQAKAA0ACgAQABEACwAKABIAEwAJABMADAAKAA0AFQAaABsACQAPABAADQATAAoAEAARAAoA CgAOAAoABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEB ADoAAAAyCsQBoAAiAAAAZGlmZmVyZW50IGZyb20gZW1haWwgc2VydmljZSwgUFNUThMACQANAAwA EQAMABAAEwALAAkADQAMABIAHgAJABAAHgARAAoACgAJAA8AEAANABMACgAQABEACQAJABYAFAAX ABwABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAAkA AAAyCsQBsAIBAAAALQALAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAu ARgABAAAAAIBAQAZAAAAMgrEAbsCDAAAAGZheCBzZXJ2aWNlIA0AEQASAAkADwAQAA0AEwAKABAA EQAKAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAn AAAAMgrxAaAAFQAAAGFuZCBULjM4IGZheCBzZXJ2aWNlLgAQABMAEgAJABcACQATABMACQANABEA EgAJAA8AEAANABMACgAQABEACQAEAAAALgEBAAQAAAACAQIABAAAAAIBAgAEAAAALQEBAAQAAAAt AQQAEAAAAPsCEgAIAAAAAACQAQAAAIABAgICU3lzdGVtAIAEAAAALQEDAAQAAADwAQUADwAAACYG DwAUAFROUFAEAAwAAAAAAAAAAAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAA/v8AAAQKAgAA AAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAMAIAABAAAAABAAAAiAAAAAMA AACQAAAADwAAAKgAAAAEAAAAuAAAAAYAAADAAAAABwAAAMgAAAAIAAAA0AAAAAkAAADYAAAACgAA AOAAAAAXAAAA6AAAAAsAAADwAAAAEAAAAPgAAAATAAAAAAEAABYAAAAIAQAADQAAABABAAAMAAAA tgEAAAIAAACkAwAAHgAAAA8AAACJ5pbKgsmNh4LtgrmC6QAAHgAAAAUAAABNR0NTAMmNhwMAAADM GgAAAwAAABcAAAADAAAAAwAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAADtDgkACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAABwAAABAAAABUaW1lcyBOZXcgUm9tYW4AEAAA AIJsgnIggm+DU4NWg2KDTgAMAAAAgmyCciCCb5a+kqkADQAAAJVXj4CDZoNVg0ODkwAVAAAASUZB WCBTZXJ2aWNlIG9mIEVOVU0AGQAAAEZ1bmN0aW9uYWwgU3BlY2lmaWNhdGlvbgAbAAAARGVmaW5p dGlvbiBvZiBOQVBUUiByZWNvcmQADBAAAAYAAAAeAAAAFwAAAI5nl3CCs4LqgsSCooLpg3SDSIOT g2cAAwAAAAMAAAAeAAAAFgAAAINmg1WDQ4OTIINlg5ODdoOMgVuDZwADAAAAAQAAAB4AAAASAAAA g1iDiYNDg2ggg16DQ4Nng4sAAwAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA9g8mAAAAFAAAAF/AkeOoGgAADgD0AwMA9ABIaXJvc2hpIFRhbXVyYQgAAABIAGkAcgBv AHMAaABpACAAVABhAG0AdQByAGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAABKAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ----Next_Part(Mon_Jul_15_10:43:13_2002_955)---- _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jul 15 01:46: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 BAA02781 for ; Mon, 15 Jul 2002 01:46:43 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28803 for enum-archive@odin.ietf.org; Mon, 15 Jul 2002 01:47: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 BAA28428; Mon, 15 Jul 2002 01:37: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 BAA28394 for ; Mon, 15 Jul 2002 01:37: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 BAA02237 for ; Mon, 15 Jul 2002 01:36:37 -0400 (EDT) Received: from xbe-lon-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6F5aEJC023890 for ; Mon, 15 Jul 2002 07:36:14 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 15 Jul 2002 06:37:02 +0100 Received: from zx81.paf.se.dyn.ietf54.wide.ad.jp ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 15 Jul 2002 07:37:01 +0200 Date: Mon, 15 Jul 2002 14:17:07 +0900 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: enum@ietf.org Message-ID: <5138404.1026742627@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: 15 Jul 2002 05:37:01.0650 (UTC) FILETIME=[A4FCAB20:01C22BC1] Content-Transfer-Encoding: 7bit Subject: [Enum] Proposed new ABNF 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 At the IETF meeting in Yokohama, the following ABNF is proposed as a strawman proposal which is to be used for further discussions for registration documents. Anyone with objections should on this mailing list say so. service_field = "E2U" 1*("+" enumservice) enumservice = foo *[bar] foo = 1*32(ALPHA / DIGIT) bar = ":" foo paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jul 15 01:56: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 BAA03132 for ; Mon, 15 Jul 2002 01:56:03 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA29053 for enum-archive@odin.ietf.org; Mon, 15 Jul 2002 01:57:00 -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 BAA28739; Mon, 15 Jul 2002 01:46: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 BAA28710 for ; Mon, 15 Jul 2002 01:46:51 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02740 for ; Mon, 15 Jul 2002 01:45:52 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA15586; Mon, 15 Jul 2002 01:46:15 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id BAA02247; Mon, 15 Jul 2002 01:46:18 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <3W984QSB>; Mon, 15 Jul 2002 01:46:17 -0400 Message-ID: <313680C9A886D511A06000204840E1CF030B5676@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , enum@ietf.org Subject: RE: [Enum] Proposed new ABNF Date: Mon, 15 Jul 2002 01:46:11 -0400 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 BAA28711 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 Could we be a little more elegant? service_field = "E2U" 1*("+" enumservice) enumservice = foo *[":" foo] foo = 1*32(ALPHA / DIGIT) Convention would rename "foo" to "token" Brian > -----Original Message----- > From: Patrik Fältström [mailto:paf@cisco.com] > Sent: Monday, July 15, 2002 1:17 AM > To: enum@ietf.org > Subject: [Enum] Proposed new ABNF > > > At the IETF meeting in Yokohama, the following ABNF is proposed as a > strawman proposal which is to be used for further discussions for > registration documents. > > Anyone with objections should on this mailing list say so. > > service_field = "E2U" 1*("+" enumservice) > enumservice = foo *[bar] > foo = 1*32(ALPHA / DIGIT) > bar = ":" foo > > 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 Mon Jul 15 05:46:39 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 FAA20036 for ; Mon, 15 Jul 2002 05:46:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13105 for enum-archive@odin.ietf.org; Mon, 15 Jul 2002 05:47: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 FAA12366; Mon, 15 Jul 2002 05:37: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 FAA12335 for ; Mon, 15 Jul 2002 05:37:01 -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 FAA19322 for ; Mon, 15 Jul 2002 05:36: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 g6F9akc18969; Mon, 15 Jul 2002 09:36:46 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 17U2HT-000FEt-00; Mon, 15 Jul 2002 10:36:35 +0100 Date: Mon, 15 Jul 2002 10:36:35 +0100 From: "Clive D.W. Feather" To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Cc: enum@ietf.org Subject: Re: [Enum] Proposed new ABNF Message-ID: <20020715093635.GB53640@demon.net> References: <5138404.1026742627@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5138404.1026742627@localhost> User-Agent: Mutt/1.4i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA12336 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 Fältström said: > At the IETF meeting in Yokohama, the following ABNF is proposed as a > strawman proposal which is to be used for further discussions for > registration documents. > > Anyone with objections should on this mailing list say so. > > service_field = "E2U" 1*("+" enumservice) > enumservice = foo *[bar] > foo = 1*32(ALPHA / DIGIT) > bar = ":" foo I object. As I pointed out in my long email recently, "+" is a valid character in a URI protocol field. Indeed, none of the issues I raised in that email are addressed in that grammar. -- 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 Jul 15 07:56: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 HAA26688 for ; Mon, 15 Jul 2002 07:56:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA20270 for enum-archive@odin.ietf.org; Mon, 15 Jul 2002 07:57: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 HAA19658; Mon, 15 Jul 2002 07:46: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 HAA19627 for ; Mon, 15 Jul 2002 07:46:03 -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 HAA25647 for ; Mon, 15 Jul 2002 07:45:05 -0400 (EDT) Received: from xbe-ams-303.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6FBho9L019705; Mon, 15 Jul 2002 13:44:08 +0200 (MET DST) Received: from xfe-ams-301.cisco.com ([144.254.75.88]) by xbe-ams-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 15 Jul 2002 13:44:55 +0200 Received: from zx81.paf.se.dyn.ietf54.wide.ad.jp ([144.254.74.55]) by xfe-ams-301.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 15 Jul 2002 13:44:55 +0200 Date: Mon, 15 Jul 2002 20:43:11 +0900 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: "Clive D.W. Feather" cc: enum@ietf.org Subject: Re: [Enum] Proposed new ABNF Message-ID: <5970314.1026765791@localhost> In-Reply-To: <20020715093635.GB53640@demon.net> References: <5138404.1026742627@localhost> <20020715093635.GB53640@demon.net> 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: 15 Jul 2002 11:44:55.0508 (UTC) FILETIME=[0A081940:01C22BF5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA19628 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 2002-07-15 10.36 +0100 "Clive D.W. Feather" wrote: > Patrik Fältström said: >> At the IETF meeting in Yokohama, the following ABNF is proposed as a >> strawman proposal which is to be used for further discussions for >> registration documents. >> >> Anyone with objections should on this mailing list say so. >> >> service_field = "E2U" 1*("+" enumservice) >> enumservice = foo *[bar] >> foo = 1*32(ALPHA / DIGIT) >> bar = ":" foo > > I object. Point taken. Let me explain. > As I pointed out in my long email recently, "+" is a valid character in a > URI protocol field. Indeed, none of the issues I raised in that email are > addressed in that grammar. The reason why I still use '+' even though it is a valid character in a URI protocol field is because I don't see any connection between the URI syntax and the syntax for the enumservice. BUT, the important part are your other issues. At the discussion today, we walked up and down the path of questioning whether the various fields in the namespace we define (because we are defining a new namespace with N levels, and N can be one, two or three) should be well defined or not in the base document. One can say that one camp wanted more constraints, some people wanted less. At the end, we agreed that the _base_ document doesn't and should not be more specific. It is when registering the "foo":s the specifics have to be written. So, what you (and others) want to do is possible to do with the syntax above -- modulo the fact that you wanted the enumservice be divided in multiple fields, and each field have a specific meaning. As I said above, there was another camp (not larger, not smaller) which strongly objected, and said that the base document should NOT be too specific. The example was "sip" which itself can do negotiation of various kind, so it could be interesting to "just" as enumservice say that the actual negotiation is to be done with the SIP protocol. A similar negotiation can be done using LDAP... Anyway. The point of locking the _syntax_ like the above for now, was that we to be able to move forward need explicit examples of documents specifying specific enumservices -- and our guess at the meeting was that both people which want constraints on the enumservice (like you) and the one that doesn't want (like some others) BOTH can be accomodated with the given syntax. Now, this was just an explanation. I am not trying to shut you up. Now, given this explanation, do you still think this is a mistake _for_now_? paf _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Mon Jul 15 13:28:28 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 NAA12111 for ; Mon, 15 Jul 2002 13:28:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28782 for enum-archive@odin.ietf.org; Mon, 15 Jul 2002 13:29:25 -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 NAA11144; Mon, 15 Jul 2002 13:20: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 NAA11068 for ; Mon, 15 Jul 2002 13:20:06 -0400 (EDT) Received: from dorfl.roke.co.uk (dorfl.roke.co.uk [193.118.205.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11795 for ; Mon, 15 Jul 2002 13:19:09 -0400 (EDT) Received: from [193.118.192.41] ([193.118.192.41] verified) by dorfl.roke.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000091008; Mon, 15 Jul 2002 18:19:05 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Mon, 15 Jul 2002 18:18:45 +0100 To: enum@ietf.org From: Lawrence Conroy Cc: clive@demon.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: ABNF - cohabitation 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, hope you're all having a fun time in YOK. Quick comment: Well... this proposal indicates that there is little consensus on content. It does present a way forward for the "base" specification, so my compliments. It does shift the argument onto the service definition documents, so we still have ample chances to argue at one another. We also have a another slight shift in syntax (sigh...). ---- From my perspective, the optional colon-sep list is "for future use only". But... Clive, couldn't you do your multiple component stuff using this syntax? Each enumservice is an alternative, whilst the colon-sep stuff is, I guess, an AND. It's a little more verbose than using your naked "<", ">", and "#", but the effect seems similar to me. ---- I do have two small issues with the ABNF, however. If each enumservice string is registered separately, then I don't think that we have any way add an item that will only occur once per *list of enumservices*. Also, as the enumservice list is shown as 1*, do we need to define a default "none-of-your-business" enumservice [expected client behaviour - use the URI and if that isn't enough, reject the NAPTR; function to indicate that the registrant is unwilling to specify further usage in the NAPTR]? Both minor points that don't affect me now, but have these been considered? ---- all the best, Lawrenece -- 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 Jul 24 11:18: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 LAA21063 for ; Wed, 24 Jul 2002 11:18:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA02830 for enum-archive@odin.ietf.org; Wed, 24 Jul 2002 11:20: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 LAA02133; Wed, 24 Jul 2002 11:04: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 LAA02106 for ; Wed, 24 Jul 2002 11:04:40 -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 LAA20513 for ; Wed, 24 Jul 2002 11:03:37 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g6OF4AD02965 for ; Wed, 24 Jul 2002 11:04:10 -0400 Message-Id: <5.1.0.14.2.20020724110920.022a2dd0@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Jul 2002 11:11:00 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Comments on going to Last Call 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 document has been discussed here rather extensively over time and I like to get a sense of the list whether its time to move this to last call as Informational. ################### Title : Number Portability in the GSTN: An Overview Author(s) : M. Foster, T. McGarry, J. Yu Filename : draft-ietf-enum-e164-gstn-np-05.txt Pages : 27 Date : 27-Jun-02 This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony work-in-progress at IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-05.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Jul 24 11:26:39 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 LAA21293 for ; Wed, 24 Jul 2002 11:26:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03196 for enum-archive@odin.ietf.org; Wed, 24 Jul 2002 11:27: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 LAA02704; Wed, 24 Jul 2002 11:18: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 LAA02673 for ; Wed, 24 Jul 2002 11:18:31 -0400 (EDT) Received: from relay.cwplc.com (relay.cwplc.com [194.6.6.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21009 for ; Wed, 24 Jul 2002 11:17:23 -0400 (EDT) Received: from gbcwcwarmsw3.isops.cwcom.co.uk ([148.185.176.7]) by relay.cwplc.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6OFIQV00071 for ; Wed, 24 Jul 2002 16:18:26 +0100 (BST) Received: from gbcwcbrti002.isops.cwcom.co.uk (unverified) by gbcwcwarmsw3.isops.cwcom.co.uk (Content Technologies SMTPRS 4.2.10) with ESMTP id ; Wed, 24 Jul 2002 16:17:58 +0100 Received: by gbcwcbrti002.isops.cwcom.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 16:15:47 +0100 Message-ID: From: "Rosbotham, Paul" To: "'Richard Shockey'" , enum@ietf.org Subject: RE: [Enum] Comments on going to Last Call Date: Wed, 24 Jul 2002 16:17:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 My feeling would be that all of the comments made by myself and a few others have been satisfactorily incorporated into the doc, so I'd be happy to move to last call. Paul Rosbotham Manager, Interconnect Strategy & Technology Regulation Cable & Wireless plc Tel : +44 1344 713246 Fax : +44 1344 713015 Mob : +44 7957 805573 > -----Original Message----- > From: Richard Shockey [SMTP:rich.shockey@NeuStar.com] > Sent: 24 July 2002 16:11 > To: enum@ietf.org > Subject: [Enum] Comments on going to Last Call > > > This document has been discussed here rather extensively over time and I > like to get a sense of the list whether its time to move this to last call > as Informational. > > > ################### > > Title : Number Portability in the GSTN: An Overview > Author(s) : M. Foster, T. McGarry, J. Yu > Filename : draft-ietf-enum-e164-gstn-np-05.txt > Pages : 27 > Date : 27-Jun-02 > > This document provides an overview of E.164 telephone number > portability (NP) in the Global Switched Telephone Network (GSTN). > NP is a regulatory imperative seeking to liberalize local telephony > service competition, by enabling end-users to retain telephone > numbers while changing service providers. NP changes the > fundamental nature of a dialed E.164 number from a hierarchical > physical routing address to a virtual address, thereby requiring the > transparent translation of the later to the former. In addition, > there are various regulatory constraints that establish relevant > parameters for NP implementation, most of which are not network > technology specific. Consequently, the implementation of NP > behavior consistent with applicable regulatory constraints, as well > as the need for interoperation with the existing GSTN NP > implementations, are relevant topics for numerous areas of IP > telephony work-in-progress at IETF. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-05.txt > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > 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 ********************************************************************** This message may contain information which is confidential or privileged. If you are not the intended recipient, please advise the sender immediately by reply e-mail and delete this message and any attachments without retaining a copy. ********************************************************************** _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Jul 24 16:48:32 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 QAA02276 for ; Wed, 24 Jul 2002 16:48:32 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24529 for enum-archive@odin.ietf.org; Wed, 24 Jul 2002 16:49: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 QAA23835; Wed, 24 Jul 2002 16:38: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 QAA23806 for ; Wed, 24 Jul 2002 16:38:16 -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 QAA01869 for ; Wed, 24 Jul 2002 16:37:11 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g6OKbhD11888; Wed, 24 Jul 2002 16:37:43 -0400 Message-Id: <5.1.0.14.2.20020724161804.022cbe10@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 24 Jul 2002 16:44:48 -0400 To: enum@ietf.org From: Richard Shockey Cc: paf@cisco.com, sob@harvard.edu, mankin@isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Work Group Last Call on draft-ietf-enum-e164-gstn-np-05.txt 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 document has been discussed and revised several times now. The intent of the last call is to solicit comments before submitting the ID to the IESG as an Informational Document. The purpose of a working group Last Call is in the style of "speak now or forever hold your peace" in case there are fundamental objections which have not gotten previous or adequate discussion, or minor errors which need correction. Work Group last call will extend for two weeks from today July 24 th to at least August 2 nd though we can modify that if new issues come up. Title : Number Portability in the GSTN: An Overview Author(s) : M. Foster, T. McGarry, J. Yu Filename : draft-ietf-enum-e164-gstn-np-05.txt Pages : 27 Date : 27-Jun-02 This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony work-in-progress at IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-enum-e164-gstn-np-05.txt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Jul 25 09:45:02 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 JAA03959 for ; Thu, 25 Jul 2002 09:45:02 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA29101 for enum-archive@odin.ietf.org; Thu, 25 Jul 2002 09:46: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 JAA28991; Thu, 25 Jul 2002 09:45: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 JAA28963 for ; Thu, 25 Jul 2002 09:45:14 -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 JAA03865 for ; Thu, 25 Jul 2002 09:44:10 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g6PDigD28332 for ; Thu, 25 Jul 2002 09:44:42 -0400 Message-Id: <5.1.0.14.2.20020725094829.022506a8@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 25 Jul 2002 09:48:35 -0400 To: enum@ietf.org From: Richard Shockey Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Enum] Fwd: I-D ACTION:draft-toyoda-enum-faxservice-00.txt 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@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-toyoda-enum-faxservice-00.txt >Date: Thu, 25 Jul 2002 08:06:43 -0400 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : IFAX service of ENUM > Author(s) : K. Toyoda > Filename : draft-toyoda-enum-faxservice-00.txt > Pages : > Date : 24-Jul-02 > >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. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-toyoda-enum-faxservice-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-toyoda-enum-faxservice-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-toyoda-enum-faxservice-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20020724142846.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-toyoda-enum-faxservice-00.txt > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 Jul 30 11:55: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 LAA25508 for ; Tue, 30 Jul 2002 11:55:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04732 for enum-archive@odin.ietf.org; Tue, 30 Jul 2002 11:56:50 -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 LAA04618; Tue, 30 Jul 2002 11:55: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 LAA04588 for ; Tue, 30 Jul 2002 11:55:00 -0400 (EDT) Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25348 for ; Tue, 30 Jul 2002 11:53:53 -0400 (EDT) Received: from lawrence.srmr.co.uk [193.118.205.20] by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 495u via TCP with SMTP; Tue, 30 Jul 2002 16:54:56 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Tue, 30 Jul 2002 16:54:58 +0100 To: enum@ietf.org From: Lawrence Conroy Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] enum uri considered harmful? 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, hope you have all recovered from the meeting/journeys. I was told that, in answer to the enum: URI proposal, a counter-proposal to change the enum: URI into a tel: parameter was discussed in YOK. Well...Unless someone can give answers to these points, I am not happy with this - IMHO enum: is not the same as tel: ; enum=yes. I'd appreciate your comments. all the best, Lawrence ----------------------------- There are a number of tel: URL clients that exist and do NOT support this 'enum' parameter (it isn't even written yet :). The URL/parameter is intended to be mandatory - if the client cannot or is unwilling to do an ENUM lookup, the URI (or URL containing the parameter) *CANNOT be resolved*. If we are applying this *retrospectively* to all tel: clients, then this implies that all existing tel: clients are non-compliant, as they ignore unknown parameters (as per. RFC2806). With James' tel: URL (RN & CIC) parameters, this is not a problem, as these will only be used within the infrastructure - if I get a tel: URL with a RN parameter on my home PC, then I can ignore it - it is not intended for me. All tel: clients used within the Operator infrastructure will be new or updated ones and so this is fine. However... An enum: URI (or a tel: URL with an enum parameter) *will* be encountered out "in the wild" - not just within the Operator infrastructure. They could well exist on web pages, inside e-mail I receive, or within the "public" ENUM space. There will be tel: clients that have not been updated. If they receive a "standard" tel: URL, then there's no problem - they will work the same as ever. This may or may not include an ENUM lookup (it's likely that there will be no such lookup with existing clients). However, now we introduce the enum parameter. It will be unknown to the tel: client, so that existing clients will just ignore it (according to RFC2806). Result - we have no way to say "do an enum lookup on this number, or reject the URI". If we introduce a new enum: URI specifically to do the ENUM lookup, then we will be clear - either there is an enum: client that works as defined, or the URI is rejected. It will not be passed to a tel: client - that is now focused on making phone calls over the PSTN (or networks that use E.164 numbers natively :). Thus, from a practical perspective, I'm against the change from an enum: URI to a tel: parameter, as it breaks with existing clients. I'm happy to make the es parameter and the svc parameter common. This is a GOOD IDEA, ->as long as<- we can define all of the services together, *and* know what to do when someone puts in or some other enumservice that can't be handled by the PSTN. -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Tue Jul 30 16:49: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 QAA08500 for ; Tue, 30 Jul 2002 16:49:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24976 for enum-archive@odin.ietf.org; Tue, 30 Jul 2002 16:50:24 -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 QAA24944; Tue, 30 Jul 2002 16:49: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 QAA24912 for ; Tue, 30 Jul 2002 16:49:17 -0400 (EDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08455 for ; Tue, 30 Jul 2002 16:48:08 -0400 (EDT) Received: from user-2ivel62.dialup.mindspring.com ([165.247.84.194] helo=dick.ix.netcom.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17ZdvZ-0007ZL-00; Tue, 30 Jul 2002 16:49:10 -0400 Message-Id: <5.1.0.14.2.20020730164400.03f58bb0@popd.ix.netcom.com> X-Sender: rshockey@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 30 Jul 2002 16:50:20 -0400 To: Lawrence Conroy , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] enum uri considered harmful? 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 04:54 PM 7/30/2002 +0100, Lawrence Conroy wrote: >Hi Folks, > hope you have all recovered from the meeting/journeys. > >I was told that, in answer to the enum: URI proposal, a >counter-proposal to change the enum: URI into a tel: >parameter was discussed in YOK. > >Well...Unless someone can give answers to these points, >I am not happy with this - IMHO enum: is not the same as >tel: ; enum=yes. > >I'd appreciate your comments. > >all the best, > Lawrence First you note what clients would the additon of a enum=yes parameter break? As the problem statement is defined .. folks want to pass a URI that explicitly tells the application processing the URI to preform a ENUM query on the TN ... if that is the case the question in Yokohama was ..why go through the bother of developing a new URI when you can just add a new flag to the existing tel URL? >----------------------------- >There are a number of tel: URL clients that exist and do NOT >support this 'enum' parameter (it isn't even written yet :). > >The URL/parameter is intended to be mandatory - if the client >cannot or is unwilling to do an ENUM lookup, the URI (or URL >containing the parameter) *CANNOT be resolved*. why does this need to be MUST >If we are applying this *retrospectively* to all tel: clients, >then this implies that all existing tel: clients are non-compliant, >as they ignore unknown parameters (as per. RFC2806). > >With James' tel: URL (RN & CIC) parameters, this is not a problem, >as these will only be used within the infrastructure - if I get a tel: >URL with a RN parameter on my home PC, then I can ignore it - it is not >intended for me. All tel: clients used within the Operator infrastructure >will be new or updated ones and so this is fine. > >However... >An enum: URI (or a tel: URL with an enum parameter) *will* be encountered >out "in the wild" - not just within the Operator infrastructure. They >could well exist on web pages, inside e-mail I receive, or within the >"public" ENUM space. > >There will be tel: clients that have not been updated. If they receive >a "standard" tel: URL, then there's no problem - they will work the >same as ever. This may or may not include an ENUM lookup (it's likely >that there will be no such lookup with existing clients). i'm having a serious grok problem here ... very little is deployed out there now ..what are you suggesting is broken >However, now we introduce the enum parameter. It will be unknown to >the tel: client, so that existing clients will just ignore it (according >to RFC2806). Result - we have no way to say "do an enum lookup on this >number, or reject the URI". > >If we introduce a new enum: URI specifically to do the ENUM lookup, >then we will be clear - either there is an enum: client that works >as defined, or the URI is rejected. It will not be passed to a tel: >client - that is now focused on making phone calls over the PSTN >(or networks that use E.164 numbers natively :). > >Thus, from a practical perspective, I'm against the change from an >enum: URI to a tel: parameter, as it breaks with existing clients. > >I'm happy to make the es parameter and the svc parameter common. >This is a GOOD IDEA, ->as long as<- we can define all of the services >together, *and* know what to do when someone puts in >or some other enumservice that can't be handled by the PSTN. well the idea of a SRS service is an interesting idea ...I'm still interested to see what the protocol is that delivers the service. >-- >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 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 Jul 30 18:41: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 SAA11755 for ; Tue, 30 Jul 2002 18:41:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA02177 for enum-archive@odin.ietf.org; Tue, 30 Jul 2002 18:42: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 SAA02026; Tue, 30 Jul 2002 18:39: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 SAA01994 for ; Tue, 30 Jul 2002 18:39:34 -0400 (EDT) Received: from joy.songbird.com (IDENT:root@songbird.com [208.184.79.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11709 for ; Tue, 30 Jul 2002 18:38:27 -0400 (EDT) Received: from bbprime.dcrocker.net (208.184.79.252.songbird.com [208.184.79.252] (may be forged)) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id PAA13449; Tue, 30 Jul 2002 15:48:02 -0700 Message-Id: <5.1.1.2.2.20020730152701.03931d08@jay.songbird.com> X-Sender: dhc@jay.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1.3 (Beta) Date: Tue, 30 Jul 2002 15:39:27 -0700 To: enum@ietf.org From: Dave Crocker Subject: Re: [Enum] enum uri considered harmful? Cc: Lawrence Conroy In-Reply-To: <5.1.0.14.2.20020730164400.03f58bb0@popd.ix.netcom.com> 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 >As the problem statement is defined .. folks want to pass a URI that >explicitly tells the application processing the URI to preform a ENUM >query on the TN ... if that is the case the question in Yokohama was ..why >go through the bother of developing a new URI when you can just add a new >flag to the existing tel URL? Folks, Part of what makes this sort of discussion so difficult is the history of URIs. They have very different flavors. http: and ftp: refer to "protocols". mailto: refers to a service and says nothing at all about what protocol to use. why not just have a URI like "domain:foo.bar;proto=http"? It is just as easy, no? If we are not careful, that is what enum: will be like. Enum is neither a service nor a protocol. By design, it is a component to a range of different services. Specifically, it is a lookup mechanism that will be used as part of services that use e.164 numbers. That's the same kind of description as we would give to domain names. We would not give that sort of description to any of the popular URIs around today. Note that tel: is defined along with modem: and fax: URIs. They all have a common syntax, for the e.164 part. So the string: preface really is describing specific user services (or protocols, I'm not sure which). They are definitely specifying far more than just a number format. They are saying something quite semantic about what the number is to be used for. d/ ---------- Dave Crocker TribalWise, Inc. tel +1.408.246.8253; fax +1.408.850.1850 _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Jul 31 03:52: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 DAA17631 for ; Wed, 31 Jul 2002 03:52:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA20476 for enum-archive@odin.ietf.org; Wed, 31 Jul 2002 03:53: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 DAA20389; Wed, 31 Jul 2002 03:51: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 DAA20358 for ; Wed, 31 Jul 2002 03:51:23 -0400 (EDT) Received: from babelfish.srmr.co.uk ([193.118.205.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17575 for ; Wed, 31 Jul 2002 03:50:14 -0400 (EDT) Received: from lawrence.srmr.co.uk ([193.118.205.14] ) by babelfish.srmr.co.uk (AppleMailServer 10.1.4.0) id 543u via TCP with SMTP; Wed, 31 Jul 2002 08:51:04 +0100 Mime-Version: 1.0 X-Sender: lwc@127.0.0.1 (Unverified) Message-Id: Date: Wed, 31 Jul 2002 08:50:59 +0100 To: Richard Shockey From: Lawrence Conroy Cc: enum@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Enum] Re: enum uri considered harmful? 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, At 4:50 pm -0400 30/7/02, Richard Shockey wrote: >As the problem statement is defined .. folks want to pass a URI that >explicitly tells the application processing the URI to preform a >ENUM query on the TN ... if that is the case the question in >Yokohama was ..why go through the bother of developing a new URI >when you can just add a new flag to the existing tel URL? and then asks: - why should this be a "MUST do a lookup or else fail"? - what clients does this break? (and adds that 'tis hard to grok, as there's little deployed :). Well....in reverse order: There -ARE- tel: URL handlers out there. We have one - well, actually, we have two. Look back at the rfc2806bis discussions on IPTel list, and you'll see that Broadsoft have one as well - Brett was pretty insistent on not breaking them (fair enough, IMHO) with the update. I can guarantee that these do not support the proposed enum parameter. I can't talk for others, but I don't believe ours do an ENUM lookup; they focus on delivering a phone call given a tel: URL. Now for "why MUST"? At present, a registrant can't be sure that the client will or will not have a tel: URL handler that does ENUM lookups. Even if we have a mandatory tel: parameter you can't be sure that the client won't follow the current (RFC2806) behaviour, and ignore it. As a potential registrant for "public" ENUM, this is not a good proposition. You can be sure that an enum: URI handler will do the lookup :). Particularly when they appear on web pages, I can imagine the registrant (or the person putting that info onto the page) -might- prefer to know that someone clicking on the link will not call the phone number directly. If they don't mind, there's tel:. Does this make sense? all the best, Lawrence -- ----------------------------------------------------------------------- Roke Manor Research : This information is provided "as is" and is not : intended to create any contractual or legal : relationship. _______________________________________________ enum mailing list enum@ietf.org https://www1.ietf.org/mailman/listinfo/enum From daemon@optimus.ietf.org Wed Jul 31 10:39:33 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 KAA29942 for ; Wed, 31 Jul 2002 10:39:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13325 for enum-archive@odin.ietf.org; Wed, 31 Jul 2002 10:40: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 KAA13214; Wed, 31 Jul 2002 10:39: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 KAA13181 for ; Wed, 31 Jul 2002 10:39:35 -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 KAA29863 for ; Wed, 31 Jul 2002 10:38:27 -0400 (EDT) Received: from dick.neustar.com (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g6VEcRm20105; Wed, 31 Jul 2002 14:38:27 GMT Message-Id: <5.1.0.14.2.20020731104017.022ba488@popd.ix.netcom.com> X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 31 Jul 2002 10:45:31 -0400 To: Dave Crocker , enum@ietf.org From: Richard Shockey Subject: Re: [Enum] enum uri considered harmful? Cc: Lawrence Conroy In-Reply-To: <5.1.1.2.2.20020730152701.03931d08@jay.songbird.com> References: <5.1.0.14.2.20020730164400.03f58bb0@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 > >Folks, > >Part of what makes this sort of discussion so difficult is the history of >URIs. They have very different flavors. http: and ftp: refer to >"protocols". mailto: refers to a service and says nothing at all about >what protocol to use. > >why not just have a URI like "domain:foo.bar;proto=http"? It is just as >easy, no? If we are not careful, that is what enum: will be like. > >Enum is neither a service nor a protocol. By design, it is a component to >a range of different services. Specifically, it is a lookup mechanism >that will be used as part of services that use e.164 numbers. That's the >same kind of description as we would give to domain names. We would not >give that sort of description to any of the popular URIs around today. > >Note that tel: is defined along with modem: and fax: URIs. They all have >a common syntax, for the e.164 part. So the string: preface really is >describing specific user services (or protocols, I'm not sure >which). They are definitely specifying far more than just a number >format. They are saying something quite semantic about what the number is >to be used for. Ok Dave ..but we now have flags for a tel URL ( a draft written by my colleague James Yu) that indicate the number has received a database dip for Number Portability the true LRN and a dip indicator... The concept behind ;ENUM=YES strikes me a similar. The flag tells the application here is a e164 number it can be resolved in e164.arpa, go do that. I'm open minded here ... given the problem statement what would be your solution? >d/ > > >---------- >Dave Crocker >TribalWise, Inc. >tel +1.408.246.8253; fax +1.408.850.1850 > > >_______________________________________________ >enum mailing list >enum@ietf.org >https://www1.ietf.org/mailman/listinfo/enum >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza Bldg 10 Sterling, VA 20166 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