Lisa's Apps Area Activity Report for June 2008

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

draft-jennings-http-srv-00

Hi,
Just saw this posted: 
<http://www.ietf.org/internet-drafts/draft-jennings-http-srv-00.txt>. I am 
in the process of defining SRV record lookups for CalDAV and CardDAV as 
well.

The HTTP SRV draft proposes both an 'http' and an 'https' service type. 
However, comments here: <http://www.dns-sd.org/ServiceTypes.html> for the 
https service suggest that 'https' should not be used.

What do people think? Should there be a separate 'https' SRV service type? 
If so, then should I define both 'caldav'/'caldavs' and 
'carddav'/'carddavs', or instead just rely on the http redirect approach 
with a single service type? Or perhaps, 'caldav' and 'carddav' should be 
specified in terms of the http service, e.g. 'caldav.http' and 
'caldav.https'.

Also, why isn't there an IANA registry of SRV service types? The port 
numbers registry is not sufficient.

--

-- 
Cyrus Daboo

Re: draft-jennings-http-srv-00

On 2008-7-7, at 16:50, ext Cyrus Daboo wrote:
> Also, why isn't there an IANA registry of SRV service types? The  
> port numbers registry is not sufficient.

FYI, some transport folks have started to bring the documented IANA  
ports guidelines in line with reality. (Watch for draft-ietf-tsvwg- 
iana-ports-00 later today.)

Part of that effort is to finally move the SRV registry over to IANA,  
but that hasn't happened yet. But it's on the to-do list.

Lars

Re: draft-jennings-http-srv-00

On Mon, Jul 07, 2008 at 05:24:28PM +0300, Lars Eggert wrote:
> On 2008-7-7, at 16:50, ext Cyrus Daboo wrote:
> >Also, why isn't there an IANA registry of SRV service types? The  
> >port numbers registry is not sufficient.

we've had this topic in DNSOP more than once when it came to review of
documents trying to make use of SRV.  There is no registry and RFC 2782
has the Applicability Statement for a reason.  Ironically, during the
processing of RFC 2782 the use of http as an example was carefully avoided.

> FYI, some transport folks have started to bring the documented IANA  
> ports guidelines in line with reality. (Watch for draft-ietf-tsvwg- 
> iana-ports-00 later today.)
> 
> Part of that effort is to finally move the SRV registry over to IANA,  
> but that hasn't happened yet. But it's on the to-do list.

There are a couple of DNS caveats, including, but not limited to, "backwards
compatibility" issues especially in those cases where SRV is retroactively
introduced for existing services.  I'm looking forward to the draft you
mentioned.

-Peter

RE: draft-jennings-http-srv-00

> > Part of that effort is to finally move the SRV registry 
> > over to IANA, but that hasn't happened yet.  But it's on 
> > the to-do list.
> 
> There are a couple of DNS caveats, including, but not limited 
> to, "backwards compatibility" issues especially in those cases 
> where SRV is retroactively introduced for existing services. 

Like when MX was introduced.  HTTP, at least, would be easier,
as an HTTP redirect can point 'legacy' clients towards the 
correct resource.  Such redirection was not possible with SMTP.

Safari has experience with SRV queries; we should ask Stuart
Cheshire (who is now on the IAB) to share their experiences.

-d

RE: draft-jennings-http-srv-00

Hi Dan,

--On July 7, 2008 8:08:27 AM -0700 Dan Wing <dwing <at> cisco.com> wrote:

> Safari has experience with SRV queries; we should ask Stuart
> Cheshire (who is now on the IAB) to share their experiences.

Take a look at the http and https definitions at 
<http://www.dns-sd.org/ServiceTypes.html> which I think is fairly 
representative of what is going on. But these discussions should definitely 
involve Stuart too.

--

-- 
Cyrus Daboo

draft-jennings-http-srv-00.txt

This draft proposes the age old idea of using SRV records for HTTP. I  
love to get peoples thoughts over the next month or so.

Thanks, Cullen

Begin forwarded message:

> From: Internet-Drafts <at> ietf.org
> Date: July 6, 2008 7:45:01 PM PDT (CA)
> To: i-d-announce <at> ietf.org
> Subject: I-D Action:draft-jennings-http-srv-00.txt
> Reply-To: internet-drafts <at> ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : DNS SRV Records for HTTP
> 	Author(s)       : C. Jennings
> 	Filename        : draft-jennings-http-srv-00.txt
> 	Pages           : 5
> 	Date            : 2008-07-06
>
> This document specifies a mechanism for an HTTP client to perform a
> DNS SRV lookup to find an HTTP server.
>
> The draft is being discussed on the apps-discuss <at> ietf.org list.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jennings-http-srv-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce <at> ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

draft-jennings-app-dns-update-00

The draft proposes a HTTP based API to update DNS records similar to  
the system at dyndns.org. Be pleased to get peoples thoughts but I'm  
going to be slow responding due until after the Dublin meeting.

Thanks, Cullen

Begin forwarded message:

> From: Internet-Drafts <at> ietf.org
> Date: July 6, 2008 7:45:01 PM PDT (CA)
> To: i-d-announce <at> ietf.org
> Subject: I-D Action:draft-jennings-app-dns-update-00.txt
> Reply-To: internet-drafts <at> ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : HTTP API for Updating DNS Records
> 	Author(s)       : C. Jennings
> 	Filename        : draft-jennings-app-dns-update-00.txt
> 	Pages           : 9
> 	Date            : 2008-07-06
>
> This specification defines a simple HTTP based scheme for clients to
> update DNS records.
>
> The draft is being discussed on the apps-discuss <at> ietf.org list.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jennings-app-dns-update-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce <at> ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Re: draft-jennings-http-srv-00.txt

At 9:10 PM -0700 7/6/08, Cullen Jennings wrote:
>This draft proposes the age old idea of using SRV records for HTTP. I
>love to get peoples thoughts over the next month or so.
>
>Thanks, Cullen
>

Those tiny, white specks you see on the horizon, bobbing up and
down on the waves of change are on a ship.  That ship might, using a
powerful set of lenses, see the ship that has sailed off carrying this idea.
From where we stand, we cannot even see that ship any more.  It
is far, far below our horizon. 

Having standard browsers change behavior on this one falls
into the category of "not very likely", to put it mildly.  You
give as one of your driving use cases:

   For example, a portal such as Facebook often acts a web client and
   calls specific HTTP-based APIs on other web servers.  These APIs may
   require the use of this specification.  In this situation, the end
   user's web browser might not do the SRV lookup when it browsed to the
   portal web pages, but the HTTP calls that the portal made out to
   other sites to generate the content would use this mechanism.

That would create a (possibly temporary, possibly permanent)
situation in which different classes of application did different things
to resolve the same URI scheme.  Given that the same device
could have both applications (e.g. browser and web server on
the same desktop/laptop), that means they would have to call
different libraries or have code specific to the API.  As we've
discovered in the land of Unicode versioning, relying on the
version of the library you access is tricky and not very likely
to work.  So we really need new APIs completely for this
and some way of disambiguating the situations in which
you call them vs. today's HTTP.  Re-using the same scheme
for this makes it very hard to get that right.   (And I suspect
the security considerations of both coexisting for the foreseeable
future are more than your draft suggests). 

If facebook needs this, they can mint a new URI scheme and run
up a U-NAPTR mechanism that allows them to do cool re-writing.
That gets them a lot more than port numbers (which, in internal
APIs aren't klugy enough to matter much). I'd encourage registration
of that scheme, naturally, but since it is in internal APIs, most things
won't have to know or care.  If there turns out to be a groundswell
of need for interoperability among these APIs, we can produce some
new scheme that covers that need.  But re-using the string
HTTP for it doesn't seem like a good idea to me.

I know I fall on the extreme end of the "strings are cheap"
view of URI schemes, but I think I'm squarely in the middle of
"ambiguity is expensive".  At this stage, this proposal creates
ambiguity (is this X old enough to do A/AAAA only or will it
do SRV then A/AAAA?) for something that seems easily handled
in other ways.

	two cents,
				Ted

>Begin forwarded message:
>
>> From: Internet-Drafts <at> ietf.org
>> Date: July 6, 2008 7:45:01 PM PDT (CA)
>> To: i-d-announce <at> ietf.org
>> Subject: I-D Action:draft-jennings-http-srv-00.txt
>> Reply-To: internet-drafts <at> ietf.org
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>       Title           : DNS SRV Records for HTTP
>>       Author(s)       : C. Jennings
>>       Filename        : draft-jennings-http-srv-00.txt
>>       Pages           : 5
>>       Date            : 2008-07-06
>>
>> This document specifies a mechanism for an HTTP client to perform a
>> DNS SRV lookup to find an HTTP server.
>>
>> The draft is being discussed on the apps-discuss <at> ietf.org list.
>>
>> A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-jennings-http-srv-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> 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: message/external-body; name="mime-attachment"
>Content-Description: mime-attachment
>Content-Disposition: attachment; filename="mime-attachment"; size=330;
>	creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>	modification-date="Mon, 07 Jul 2008 13:25:42 GMT"
>
>Content-Disposition: attachment; filename="mime-attachment"
>Content-Type: message/external-body; x-unix-mode=0666;
>	name="mime-attachment"
>Content-Transfer-Encoding: 7bit
>
>Content-Type: text/plain<BR>Content-ID: &lt;2008-07-06193948.I-D <at> ietf.org&gt;<BR><BR>
>
>Content-Type: text/plain; name="ATT00001.txt"
>Content-Description: ATT00001.txt
>Content-Disposition: attachment; filename="ATT00001.txt"; size=336;
>	creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>	modification-date="Mon, 07 Jul 2008 13:25:42 GMT"
>
>Attachment converted: Macintosh HD:ATT00001 2704.txt (TEXT/ttxt) (007EB89D)
>Content-Type: text/plain; name="ATT00002.txt"
>Content-Description: ATT00002.txt
>Content-Disposition: attachment; filename="ATT00002.txt"; size=215;
>	creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>	modification-date="Mon, 07 Jul 2008 13:25:42 GMT"
>
>Attachment converted: Macintosh HD:ATT00002 687.txt (TEXT/ttxt) (007EB89E)

Re: draft-jennings-http-srv-00.txt

I rarely do this, but

+1

emphatically.  One URI scheme, one resolution mechanism.

    john

--On Monday, 07 July, 2008 14:11 -0700 Ted Hardie
<hardie <at> qualcomm.com> wrote:

> At 9:10 PM -0700 7/6/08, Cullen Jennings wrote:
>> This draft proposes the age old idea of using SRV records for
>> HTTP. I love to get peoples thoughts over the next month or
>> so.
>> 
>> Thanks, Cullen
>> 
> 
> Those tiny, white specks you see on the horizon, bobbing up and
> down on the waves of change are on a ship.  That ship might,
> using a powerful set of lenses, see the ship that has sailed
> off carrying this idea. From where we stand, we cannot even
> see that ship any more.  It is far, far below our horizon. 
> 
> Having standard browsers change behavior on this one falls
> into the category of "not very likely", to put it mildly.  You
> give as one of your driving use cases:
> 
>    For example, a portal such as Facebook often acts a web
> client and    calls specific HTTP-based APIs on other web
> servers.  These APIs may    require the use of this
> specification.  In this situation, the end    user's web
> browser might not do the SRV lookup when it browsed to the
> portal web pages, but the HTTP calls that the portal made out
> to    other sites to generate the content would use this
> mechanism.
> 
> That would create a (possibly temporary, possibly permanent)
> situation in which different classes of application did
> different things to resolve the same URI scheme.  Given that
> the same device could have both applications (e.g. browser and
> web server on the same desktop/laptop), that means they would
> have to call different libraries or have code specific to the
> API.  As we've discovered in the land of Unicode versioning,
> relying on the version of the library you access is tricky and
> not very likely to work.  So we really need new APIs
> completely for this and some way of disambiguating the
> situations in which you call them vs. today's HTTP.  Re-using
> the same scheme for this makes it very hard to get that right.
> (And I suspect the security considerations of both coexisting
> for the foreseeable future are more than your draft suggests). 
> 
> If facebook needs this, they can mint a new URI scheme and run
> up a U-NAPTR mechanism that allows them to do cool re-writing.
> That gets them a lot more than port numbers (which, in internal
> APIs aren't klugy enough to matter much). I'd encourage
> registration of that scheme, naturally, but since it is in
> internal APIs, most things won't have to know or care.  If
> there turns out to be a groundswell of need for
> interoperability among these APIs, we can produce some new
> scheme that covers that need.  But re-using the string HTTP
> for it doesn't seem like a good idea to me.
> 
> I know I fall on the extreme end of the "strings are cheap"
> view of URI schemes, but I think I'm squarely in the middle of
> "ambiguity is expensive".  At this stage, this proposal creates
> ambiguity (is this X old enough to do A/AAAA only or will it
> do SRV then A/AAAA?) for something that seems easily handled
> in other ways.
> 
> 	two cents,
> 				Ted
> 
> 
> 
> 
> 
> 
> 
> 
>> Begin forwarded message:
>> 
>>> From: Internet-Drafts <at> ietf.org
>>> Date: July 6, 2008 7:45:01 PM PDT (CA)
>>> To: i-d-announce <at> ietf.org
>>> Subject: I-D Action:draft-jennings-http-srv-00.txt
>>> Reply-To: internet-drafts <at> ietf.org
>>> 
>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories.
>>> 
>>>       Title           : DNS SRV Records for HTTP
>>>       Author(s)       : C. Jennings
>>>       Filename        : draft-jennings-http-srv-00.txt
>>>       Pages           : 5
>>>       Date            : 2008-07-06
>>> 
>>> This document specifies a mechanism for an HTTP client to
>>> perform a DNS SRV lookup to find an HTTP server.
>>> 
>>> The draft is being discussed on the apps-discuss <at> ietf.org
>>> list.
>>> 
>>> A URL for this Internet-Draft is:
>> > http://www.ietf.org/internet-drafts/draft-jennings-http-srv
>> > -00.txt
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> 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: message/external-body; name="mime-attachment"
>> Content-Description: mime-attachment
>> Content-Disposition: attachment; filename="mime-attachment";
>> size=330; creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>>	modification-date="Mon, 07 Jul 2008 13:25:42 GMT"
>> 
>> Content-Disposition: attachment; filename="mime-attachment"
>> Content-Type: message/external-body; x-unix-mode=0666;
>>	name="mime-attachment"
>> Content-Transfer-Encoding: 7bit
>> 
>> Content-Type: text/plain<BR>Content-ID:
>> &lt;2008-07-06193948.I-D <at> ietf.org&gt;<BR><BR>
>> 
>> Content-Type: text/plain; name="ATT00001.txt"
>> Content-Description: ATT00001.txt
>> Content-Disposition: attachment; filename="ATT00001.txt";
>> size=336; creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>>	modification-date="Mon, 07 Jul 2008 13:25:42 GMT"
>> 
>> Attachment converted: Macintosh HD:ATT00001 2704.txt
>> (TEXT/ttxt) (007EB89D) Content-Type: text/plain;
>> name="ATT00002.txt"
>> Content-Description: ATT00002.txt
>> Content-Disposition: attachment; filename="ATT00002.txt";
>> size=215; creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>>	modification-date="Mon, 07 Jul 2008 13:25:42 GMT"
>> 
>> Attachment converted: Macintosh HD:ATT00002 687.txt
>> (TEXT/ttxt) (007EB89E)
> 
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss <at> ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss