Subject: RE: [Enum] Revised #2 IETF 53 Agenda

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 11 Mar 2002 18:18:21 -0600

I imagine that the discussion of the service field issue could easily
encompass this entire hour, and this seems to be the most important thing
for us to sort out. I will make up some very few slides (maybe four or so)
that summarize what I see the major points of contention on this issue.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]]
> Sent: Sunday, March 10, 2002 3:05 PM
> To: [email-masked]
> Subject: [Enum] Revised #2 IETF 53 Agenda
> 
> 
[snip]
> 
> 
> SERVICE FIELD DOCUMENTS  ( 1 Hour ??)
> 
[snip]
> 
> The Use of ENUM by SIP
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-01.txt
> 
> Issues:
> 
> ??? Jon ??
> Processing of 2 SIP service fields in one ENUM registration?
> 
> 

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 14 Mar 2002 11:26:39 -0700

>>* Service Resolution Service, implications like
>>      - new protocol or HTTP(s) with something on top (SOAP)? New WG?
>>      I see ENUM as a basic service, pres: might be an additional 
>> service with additional cost
>
> Could you elaborate here . what are you suggesting .. I'm hoping Andy
> can clarify the direction he wants to take with his draft ... but yes 
> ENUM is the basic service etc.

Let me address the second issue, namely the direction I hope to take with my draft. Right now, the draft merely outlines the reasons why service resolution services add value to ENUM and how their use could help us avoid service field tag hell. Assuming we agree that it would be a good thing to better define how ENUM and service resolution services should behave, my draft could move toward an informational RFC or become absorbed into bis somehow.

Outside the draft, there's the issue of finding a signaling-agnostic presence service, preferably one that can run over HTTP for brainless firewall traversal and simplicity. And one that allows for pre-call media selection based on the current capabilities of available devices for both the potential caller and party to be called. Perhaps SIMPLE could be extended to do this, or a separate working group could tackle this notion of an independent presence service. IMHO, such a service could also go a long way to solving the geopriv problem effectively (but that's not a concern for this group, so I'll leave it at that). In any case, most of this work is outside of ENUM so I haven't focused on this in the draft.

Given that the latter issue is tangential to the group, I intend to mention it only in passing, keeping the WG discussion limited to the specific charter-related issue of how we want to treat service resolution services and how that should affect our guidelines for service field tags.

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

            [email-masked] 
              +1 720 444 4001